Посмотрел я этот ваш Rust

Нет, не нужны. Это одна из главнейших ошибок современного IT - создание языков для дебилов.

Надо создавать максимально безопасные от ошибок человека языки, которые не будут давать стрелять в ногу при сохранении возможности писать быстрый код, т.е. во-первых, не поощрять практику стрелять в ногу с точки зрения синтаксиса (простая магия на указателях) и стандартной библиотеки языка (scanf и sscanf в винде), во-вторых - делать крутые IDE, которые не дают стрелять в ногу (PyCharm в этом направлении немного себя проявил), в-третьих, мазаться статистическими анализаторами и изучать статистику багов и ошибок, чтобы может даже с ML что-то мутить для проверки кода (пивас студия не нужна, нужен опенсорс проект который станет дефакто стандартом), в-четвёртых, стандартизация во все поля, вплоть до того, как писать комментарии в коде, чтобы весь код был одинаково читаемым, а не то как в C++ - тут C с классами, тут портянка на макросах, тут какое-то извращение из одних шаблонов, а вот здесь функциональщина и Code Style у каждой библиотеки свой.

Я-то отвечал на комментарий, что «это не работает». Судя по всему, очень даже работает?

Ответ был плана «да, но...». Это не работает на ответственных задачах, потому что получается говно. Типичный пример - Chromium, большой проект, который создавался самой разношерстной публикой, из-за чего у разных модулей качество реализации варьируется от божественного до почти неюзабельного. Я, например, постоянно плююсь от их инструментов разработчика — их определенно делали не разработчики.

Похоже что область применения Rust - в тех случаях когда вам на самом деле нужен Haskell, но вы не можете осилить ФП. Характеристики по сложности разработки и сопровождения у них схожие.

Но лично у меня все задачи которые приходилось решать хорошо ложились на один из C, Common Lisp, Erlang, или Tcl.

Экспертненько. Но я не заметил здесь

Но лично у меня все задачи которые приходилось решать хорошо ложились на один из C, Common Lisp, Erlang, или Tcl.

ни раста, ни хаскеля. На чем тогда строятся выводы? В расте ФП не сказать, что много. А трушного так и вовсе нет.

ни раста, ни хаскеля. На чем тогда строятся выводы?

Приходилось пол года работать и на Haskell за деньги.

В расте ФП не сказать, что много. А трушного так и вовсе нет.

Я о том и говорю.

Не уверен, что хаскель и раст прям так сильно пересекаются. Если можно позволить GC, но не осилили ФП, то проще будет что-то другое взять.

В Go абстрактный портируемый ассемблер. Можно определять новые мнемоники. Ассемблерные файлы подхватываются компилятором автоматически. Сам формат файла немного неудобный. Но обычно в терминале выводят ассемблер реализованной в Go функции и копируют в *.s файл для оптимизации. Все параметры передаются в стеке.

Но в SBCL это как-то гибче выглядит, если это абстрактный ассемблер. Или для каждой платформы нужно переписывать… В любом случае, получается можно реализовать аналог goroutines или coroutines как в Lua, вместо всей туфты как futures, promises, async/await.

В любом случае, получается можно реализовать аналог goroutines или coroutines как в Lua, вместо всей туфты как futures, promises, async/await

Давай все-таки не забывать, что кооперативная многозадачность дает больше возможностей, чем их предоставляет Go. Все-таки зеленые потоки в Go не для галочки — они позволяют делать «вызовы функции» через каналы с околонулевой стоимостью. В остальном это простые потоки, со всеми проблемами, которые имеют простые потоки, а именно — сложность работы с общими данными. Позиция разрабов Go — разделяемых данных у приложения быть не должно. А теперь сравни это с JS/CPython, где данные вполне себе разделяются меж потоками. Мудила-блогер, которые писал сатирический рассказ про цвета функций, почему-то не хотел этого видеть — надеюсь, он смог добиться карьерного успеха, хлебает смузи на рабочем месте, и медленно умирает от рака мозга.

А теперь сравни это с JS/CPython

Там нет параллелизма. В Python только вспомогательные неявные треды используются. Вообще Go по идее универсальный, но Rob Pike(или кто другой) должен был найти лазейку популяризовать язык(идеи ещё со времён ОС Plan9), потому одним рассказывали что это именно для серверов.

Позиция разрабов Go — разделяемых данных у приложения быть не должно.

Не такая позиция у разрабов Go. Они советуют разделять данные с помощью сообщений через каналы. Можно передавать сами данные через каналы, или можно передавать сигнальные данные что какой-то массив(или его часть slice) теперь доступен горутине получившей сигнал через канал.
Есть статьи типа «а почему не использовать сырой Mutex? Channels are bad!». Но проблема Mutex в том что если надо запросить их несколько штук то обязательна последовательность их запроса во всех местах программы, иначе «deadly embrace»(обе горутины захватили по одному локу, а каждой нужно два сразу, и обе вечно ждут когда одна из них отпустит необходимый). Простота языка нужна для аудита кода. Ни один другой язык не предоставляет такие удобства.

Но если надо разделение данных, то пожалуйста. Есть опция -race которая покажет все data race в коде который вызывается. Стандартный инструмент. Для этого нужен полный test coverage(что удобно в Go).
В использовании для обнаружении «data races» инструментария runtime может для кого-то отсутствует теоретическая академическая чистота реализации в языке, но если бы такая и была то для работы оно мало пригодно - слишком большой impedance mismatch между программистом и реализуемой идеей.

В остальном это простые потоки, со всеми проблемами, которые имеют простые потоки

Нет. В горутинах автоматическое распределение по тредам ОС. Простые потоки это те 3D игры когда появились первые multicore CPUs, да и сейчас так. Игру делали на потоках под конкретное число ядер доминирующих на рынке. И то, большую часть времени потоки могли простаивать(и сейчас так). Даже в простых тестах на https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html бывает не все 4 ядра заняты по максимуму.

С горутинами, если активная на потоке блокируется на какой-то канал, то её сразу заменяет на потоке ждущая со своим стеком, просто записываются несколько регистров CPU. С точки зрения ОС треды всегда активны(на них всегда активные горутины).
А с точки зрения программиста логика программы «cooperative».

OOP же модель в Go такая: https://en.wikipedia.org/wiki/Composition_over_inheritance

Просто многие часто уверены что там нет OOP, если нужно.
Преимущество композиции вместо прямого наследования - в большей гибкости.
Композиция функциональности вместо представления того каким большим типом данных что-где является со всеми ограничениями и минами.
Композиция интерфейсов вместо создания иерархии «вертикали власти».
Композиция доступна программной логике вo время исполнения.

Carl Finlow - «Entron» https://www.youtube.com/watch?v=dyO1XW8eK_M

CGO удобен для интероперабельности с «C», во многом соответствие типов языков. Но нужно организовывать передачу указателей(GC), и вызов функции C занимает 70-90 наносекунд. Вызов из C в Go уже 200-240 наносекунд. Но это не сильно отличается от libffi, наверное. Stack switching.

А теперь сравни это с JS/CPython

Там нет параллелизма. В Python только вспомогательные неявные треды используются

Асинхронщина на других языках и вовсе с явными функциями обратного вызова применяется, так что не питоном одним.

Вообще Go по идее универсальный, но Rob Pike(или кто другой) должен был найти лазейку популяризовать язык(идеи ещё со времён ОС Plan9), потому одним рассказывали что это именно для серверов

У меня весьма странное смешанное впечатление производит этот Роб Пайк. С одной стороны, чел вроде двигает новые технологии, с другой стороны, эти технологии такие упоротые, что я даже не знаю, как к ним относиться. Предком Go является Limbo, а предком Limbo является Alef. Однако, Alef написан ни разу не Пайком.

В итоге получается, что Пайк как бы «донашивает» новые технологии. Можно аппелировать к тому, что только так получится (и таки получилось) ввести в индустрию новую технологию. Например, у тебя не получится сделать ОС для многопоточного кода, пока в твоей ОС есть сигналы, форк, сплошные синхронные функции в API, и некооперирующийся планировщик. А это и есть краткая характеристика POSIX. На линуксе новый API нарастает отдельно, но необходимость поддерживать совместимость с POSIX очень тяготит разработку софта, причем, как самого ядра, так и юзерспейса, дергающего системные вызовы.

Не такая позиция у разрабов Go. Они советуют разделять данные с помощью сообщений через каналы

Данные могут существовать в каждый момент врекмени только с одной стороны канала. Потому они никогда не разделяются. Да, можно передавать ссылку, но, опять же, позиция разрабов: обращаться по этой ссылке в каждый момент времени можно только с одной стороны.

Простота языка нужна для аудита кода. Ни один другой язык не предоставляет такие удобства

Java. Которую он, по сути, и заменяет. По крайней мере последних версий, с лямбдами и локальным выводом типов.

Но если надо разделение данных, то пожалуйста. Есть опция -race которая покажет все data race в коде который вызывается. Стандартный инструмент. Для этого нужен полный test coverage(что удобно в Go)

Если бы решение проблем гонок было бы таким простым, то я бы первым побежал пользоваться Go. Но, к сожалению, опция "-race" — это простой ThreadSanitizer, который имеет какой-то шанс словить параллельный доступ во время выполнения, но только если этот шанс будет достаточно большим и если сами дополнительные инструкции не изменят выполнение так, что гонки перестанут случаться. То есть, оно помогает хотя бы увидеть, что ошибка произошла, потому что гонка сама по себе не выдает никакой ошибки, в отличие от какого-нибудь segmentation fault.

В остальном это простые потоки, со всеми проблемами, которые имеют простые потоки

Нет. В горутинах автоматическое распределение по тредам ОС

Как твой тезис противоречит моему? Особенно если вспомнить, что ты его обрезал до фразы про разделяемые данные.

OOP же модель в Go такая: https://en.wikipedia.org/wiki/Composition_over_inheritance

Это тут при чем? Ты можешь писать композиции вместо наследования и в питоне и в JS, но упоротые программисты продолжают натягивать сову на глобус.

CGO удобен для интероперабельности с «C», во многом соответствие типов языков. Но нужно организовывать передачу указателей(GC), и вызов функции C занимает 70-90 наносекунд. Вызов из C в Go уже 200-240 наносекунд

Это всё дохерища времени, если вспомнить, что вызов сишной функции из Си занимает единицы наносекунд, не говоря уже про инлайн.

Наконец, ну безопасность чтоли, хваленая? Ну, опять нет. Взять тот же unsafe. Если вам нужна прямо таки безопасность-безопасность - берите что-нибудь вроде хаскеля(или какого-нибудь Coq, или что-нибудь подобное, с зависимыми типами, если совсем упоролись), ну или на худой конец, что-нибудь вроде Java, где все безопасно прямо как в дурдоме с мягкими стенами.

Вот это аргумент, сильный как крыло мотылька.

Наличие слова unsafe => язык небезопасный? Ну офигеть теперь. Нужна безопасность — пишите на Haskell или формально верифицируйте? Ну на тебе упражнение: разгромно ответь на этот коммент, используя реализацию TLS, написанную на хаскелле или формально верифицированную. Такие даже есть. Жду!

Если бы решение проблем гонок было бы таким простым

Сам доступ к общим данным это элементарно, особенно если заранее знать что будешь с ними осознанно работать изначально а не добавлять мимоходом по необходимости. С точки зрения программиста.

С точки зрения менеджера задача которого дать запрос к HR нанять команду, то все эти страхи про разделение данных должны постоянно преследовать. Это открывается новый «огромный и удивительный мир», часто не связанный с самим программированием.

Это всё дохерища времени, если вспомнить, что вызов сишной функции из Си занимает единицы наносекунд, не говоря уже про инлайн.

Другая гранулярность вызовов в C. Подходит для описания бизнес логики/ИИ с параллелизмом, а вызовы в C служебные. Как вариант.

Ты можешь писать композиции вместо наследования и в питоне и в JS

В Go для этого синтаксис удобнee.
В структуру названием например «myStruct» можно вставить тип sync.Mutex без названия, так методы .Lock() и .Unlock() становятся доступными как собственный интерфейс «myStruct». Promoted Fields.

Java. Которую он, по сути, и заменяет. По крайней мере последних версий, с лямбдами и локальным выводом типов.

Go можно дебажить. GDB или Delve, на выбор.

Пару лет назад предложили поработать на Java. Используй Java8 или Java11. Так там оказалось debug не очень работает(из интереса). Ни в Eclipse, ни в коммерческой IDE. Ощущение недоделанности, неполноценности. Может это побочка JIT, других оптимизаций. Но язык с историей из 90-х… Понял что работа с Java была бы психологическим страданием.
И Emacs плохо знает Java. Для Go, Emacs полноценная IDE, с LSP.
Компиляция в бинарник без необходимости разогрева сильно-оптимизирующего JIT. GC с задержкой в микросекунды, потребление памяти раза в 3-4 меньше. Запуск как скрипт с go run. Через какое-то время осознаёшь что не нужен ни bash ни python если что. Всё очень быстро в написании и тем более быстро в выполнении программы.
Совершенно разные фломастеры.

пивас студия не нужна, нужен опенсорс проект который станет дефакто стандартом

Опенсорс-де-факто-стандарт есть, cppcheck, правда, до пиваса ему далеко. Есть куда развиваться.

Посмотрел этот ваш Раст. Норм. Мне зашло. Смотрю дальше. Изучаю. Типажи круче классов и интерфейсов, и гибче. Но я ещё только в первом погружении.

Сам доступ к общим данным это элементарно, особенно если заранее знать что будешь с ними осознанно работать изначально а не добавлять мимоходом по необходимости. С точки зрения программиста

Разве что, с точки зрения программиста, которому решительно безразлично, как будет развиваться и поддерживаться продукт. Даже если это опенсорц. Я не спорю, что таких много, и таких много прямо здесь, но я уже написал по сути: многопоток с разделяемыми данными = ад. Точка.

Это всё дохерища времени, если вспомнить, что вызов сишной функции из Си занимает единицы наносекунд, не говоря уже про инлайн.

Другая гранулярность вызовов в C. Подходит для описания бизнес логики/ИИ с параллелизмом, а вызовы в C служебные. Как вариант

Ну и зачем ты мне писал об этом. Почти все языки имеют те или иные способы работы с Си, и Go тут далеко не самый яркий представитель.

Ты можешь писать композиции вместо наследования и в питоне и в JS

В Go для этого синтаксис удобнee.
В структуру названием например «myStruct» можно вставить тип sync.Mutex без названия, так методы .Lock() и .Unlock() становятся доступными как собственный интерфейс «myStruct». Promoted Fields

Сорта говна, то есть, плюс-минус никакая разница. Есть намного более важные вещи, такие, как отсутствие развитого полиморфизма, которые намного, намного больнее бьют по читаемости и поддерживаемости, чем необходимость дописывать Mutex.Lock вместо Lock, которую можно даже назвать преимуществом, и некоторые наставники советуют применять полностью квалифицированные идентификаторы вместо того, чтобы экономить буквы.

Пару лет назад предложили поработать на Java. Используй Java8 или Java11. Так там оказалось debug не очень работает(из интереса). Ни в Eclipse, ни в коммерческой IDE. Ощущение недоделанности, неполноценности. Может это побочка JIT, других оптимизаций. Но язык с историей из 90-х… Понял что работа с Java была бы психологическим страданием

Это настолько печально, что всем пофик.

многопоток с разделяемыми данными = ад

Думаю что это миф. Для запугивания. Одни сказали, другие повторяют.
Да, это может быть сложно. Но когда-то каждому и HTML казался сложным - «о, здесь inline js, как необычно, что-то там происходит загадочное, наверное очень сложное если разбираться». Через несколько лет - «мы всё упростили, написали Ember.js».

Многие до сих пор постят мемы по сети про то как понять рекурсию.
И с разделением памяти примерно та же ситуация скорее всего.

Это настолько печально что всем пофик. Нада падерживать, но как…

Есть намного более важные вещи, такие, как отсутствие развитого полиморфизма, которые намного, намного больнее бьют по читаемости и поддерживаемости

Может быть в голове отсутствие полиморфизма. В Go он есть.

Думаю что это миф.

Это не миф.

Сделал программист который понимает что делает, потом другой пришёл и не знает, всё ломается у него неожиданно.
Ужас, менеджеры бегают, все плачут. Ад наступил.

Потом scrum, HR lady всех успокаивает и настраивает, все хлопают в ладошки и повторяют - «мы писали, мы писали, наши пальчики устали».

Вобщем, не вижу зачем этот язык нужен

Держи нас в курсе, продолжай наблюдения. Мир замер в ожидании новых аналитических материалов.

Тред не читал. А подскажите, пожалуйста, хуями уже стали кидаться или зайти попозже?

Думаю что это миф. Для запугивания. Одни сказали, другие повторяют.

https://semantic-domain.blogspot.com/2018/04/are-functional-programs-easier-t...

Доказательства для разделяемого изменяемого состояния требуют весьма продвинутой логики разделения. Так что нет, не миф.

Держите в курсе

Доказательства для разделяемого изменяемого состояния требуют весьма продвинутой логики разделения

А, тогда да, если требует какой-то логики, то это не для всех.

UTF-8

Rust

let hello = "здравствуйте";

let s1 = &hello[0..4]; // "зд", один нелатинский символ 2 байта

let s2 = &hello[0..1]; // Rust panics at runtime

// ... byte index 1 is not a char boundary ...

You should use ranges to create string slices with caution, because doing so can crash your program.

Go

s := "здравствуйте"
fmt.Println(s[:4]) // "зд"
fmt.Println(s[:1]) // \320

В коде Rust часто надо прибегать к использованию reference count типов Rc, RefCell. Значит возможно возникновение reference count cycles. Утечки памяти.
Но это считается safe, допустимым. И это действительно редко создаёт проблемы, наверное.

В Rust можно использовать memory arenas(Bumpalo например) для быстрого выделения последовательной памяти объектам. Но все эти объекты можно освободить только вместе сразу, и «деструктор» Drop для всех этих объектов не вызывается.

Такие случаи когда GC лучше, кроме того что GC делают язык легче.
Пока GC могут быть заметны потому что частота переборки памяти как-то отстала от процессоров. Но в Go задержка(GC latency) максимум сотни микросекунд.

Есть намного более важные вещи, такие, как отсутствие развитого полиморфизма, которые намного, намного больнее бьют по читаемости и поддерживаемости

Может быть в голове отсутствие полиморфизма. В Go он есть

Ты прочитал, на что ответил? Я пишу «отсутствие развитого полиморфизма». Ты мне что отвечаешь? Полиморфизм есть. А развитого по прежнему нет.

Даже в жаве, старой унылой жаве без обобщений, есть перегрузка функций и операторов, есть ненавистное наследование (но оно есть), и есть те же самые интерфейсы, которые являются единственным способом полиморфизма в Go, с той лишь разницей, что в Go они присыпаны сахарком и реализацию интерфейса не нужно объявлять явно. Ну еще с натягом в Go можно вспомнить RTTI в виде «interface{}» в сочетании с reflect, которые нас переносят далеко в рантайм.

Доказательства для разделяемого изменяемого состояния требуют весьма продвинутой логики разделения. Так что нет, не миф

Две машины тьюринга, которые разделяют хотя бы одну ячейку, но при этом не имеют ограничений по количеству инструкций, которые могут выполнять по отношению к этой ячейке, имеют бесконечную сложность доказательства. Грубо говоря, если у тебя в одной машине есть сто инструкций, которые выполняются линейнов в бесконечном цикле, и те же инструкции в другом цикле, то одному шагу в одной машине может соответствовать сто разных вариантов выполнения второй машины. Для второго шага тоже сто вариантов — итого для двух шагов 10 тысяч вариантов выполнения. Для сотни шагов — 100 в сотой степени вариантов, или 10^20. Тебе тупо никакого компьютера не хватит.

Пока GC могут быть заметны потому что частота переборки памяти как-то отстала от процессоров. Но в Go задержка(GC latency) максимум сотни микросекунд

Ты там брошюрок начинался рекламных, что ли? «Да, говно, да, на голове, но не сильно ведь воняет и не стекает на лицо». Параллельный GC был разработан Дейкстрой еще в 70-х годах, но не применялся в индустрии, потому что он значительно тормозит работу приложения, поскольку для его работы нужно добавлять дополнительный код для каждого присвоения указателя, чтобы уведомлять сборщик мусора об этом изменении структуры связей объектов — из-за этого программа с параллельным сборщиком мусора работает медленнее, чем со сборкой stop-the-world.

Это сейчас появились дешевые ядра, потому их можно просто загрузить сборщиком, который ранее бы тратил впустую немногочисленные ядра. Однако, такой подход имеет проблемы — доступ к разделяемой памяти небесплатен. Если один поток пишет в память, а другой читает из нее — получается кэш-мис, который весьма дорогой. И в итоге мало того, что сборщик мусора попусту прожигает энергию на другом ядре — он еще и нагружает память-кэш, что уже весьма больно и игнорировать это не получится.

а если бы переписал на кресты, насколько бы код увеличился? На Аде бы точно вырос.

Ну, на C++ код явно короче получается, чем на Go. Go вообще один из примитивнейших языков.

Go вообще один из примитивнейших языков.

И в этом его преимущество. «Everything should be made as simple as possible, but no simpler.» (c) А.Эйнштейн. В Rust явно перемудрили.

поскольку для его работы нужно добавлять дополнительный код для каждого присвоения указателя, чтобы уведомлять сборщик мусора об этом изменении структуры связей объектов

Можно вместо кода использовать виртуальную память и обработку page fault. Тогда накладных расходов не будет когда сборщик не активен.

Для сотни шагов — 100 в сотой степени вариантов, или 10^20.

10^200

Сложно сказать, у меня с крестами опыта мало. Но, подозреваю, что существенно бы не изменилось.

За счет чего короче? Если представим, что это простой сервис: прочитать пару файлов, распарсить, запустить по таймеру что-то при каком-то условии.

Даже в жаве, старой унылой жаве без обобщений, есть перегрузка функций и операторов, есть ненавистное наследование (но оно есть)

Композиция вместо наследования. «has-a» relationship(Go) instead of «is-a» relationship(Java).
И во многих случаях всё решается передачей функций в параметры(в языках где привыкли к lambda).

Перегрузка операторов не нужна.

Ну еще с натягом в Go можно вспомнить RTTI в виде «interface{}» в сочетании с reflect, которые нас переносят далеко в рантайм.

Полное отсутствие стандартного рантайма(для програмера) наверное и сделало Java недоступной для дебага. Ещё JIT, другие факторы которые в сумме делают задачу дебага неподъёмной для реализации даже в условиях корпорации и группой разработчиков.
Там была интересная идея, подключение к Java на удалённом сервере и дебаг сессия на нём. Но так как сам дебаг в Java бесполезен, то осталось только нерабочей идеей.
Исполняемый binary blob.

Delve в Go дебажит по удалёнке.

Две машины тьюринга, которые разделяют хотя бы одну ячейку, но при этом не имеют ограничений по количеству инструкций, которые могут выполнять по отношению к этой ячейке, имеют бесконечную сложность доказательства. Грубо говоря, если у тебя в одной машине есть сто инструкций, которые выполняются линейнов в бесконечном цикле, и те же инструкции в другом цикле, то одному шагу в одной машине может соответствовать сто разных вариантов выполнения второй машины.

А это какая патология когда на слове «параллелизм» начинают рассказывать про несинхронизированное выполнение кода в одном пространстве памяти?

«Everything should be made as simple as possible, but no simpler.» (c) А.Эйнштейн. В Rust явно перемудрили.

«Перемудрили» всё-таки не на ровном месте, а ради определённых свойств. Ну а Go - это как раз пример когда вторая часть цитаты нарушается.

Перегрузка операторов не нужна.

Ага, дженерики тоже не нужны. Но риторика резко поменяется когда/если их наконец завезут в язык.

Полное отсутствие стандартного рантайма(для програмера) наверное и сделало Java недоступной для дебага.

Кстати, тут есть джависты? Неужели про «невозможность дебага» в джаве это правда? Что-то не верится.

В коде Rust часто надо прибегать к использованию reference count типов Rc, RefCell.

Нет, не часто.

UTF-8

Что должен иллюстрировать этот пример? Что в Go строки могут содержать мусор? Это правда преимущество?

Если в расте тебе нужно получить из строки байты или символы, то это возможно.