LINUX.ORG.RU

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

 ,


6

8

Вобщем, дошли руки потыкать палочкой.

Я вот что не пойму - зачем и кому он нужен, ну правда?

Это же новый C++. То есть, чрезмерно переусложненный язык, в котором, как говорил Луговский, разобраться может разве что хорошая зубрилка, а не хороший программист, но при этом не дающий никаких бонусов к продуктивности, и никакими киллер-фичами не обладающий.

Close to metal? Нет, извините, мне когда надо будет close to metal - я пойду сишку возьму. Которая реально, и Close To Metal, и со стабильным ABI, так важным для низкоуровневого программирования, и так далее. А если просто производительности не будет хватать, в том числе там из-за GC, так ведь - что в Java, что в Common Lisp, есть огромное количество возможностей затюнить производительность до нужного уровня, при этом не стреляя себе в ногу.

Продуктивность разработчика? Я сильно в этом сомневаюсь. Потому что вот есть языки программирования, предлагающие наибольшую продуктивность, не ограничивающие пользователя практически никак, и, конечно, вместе с тем, довольно сильно нагружающие межушной нервный узел, довольно нетривиальные для изучения. Как пример, лиспы всевозможные. Но Rust в их число не входит. Там на каждом углу костыли, подпорки, железные двери с замками, и чуть что так обухом по голове можно получить.

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

Вобщем, не вижу зачем этот язык нужен, нам и C++ хватает, если надо не ехать, а шашечки(т.е. тупо позадротствовать, да).

★★★
Ответ на: комментарий от tp_for_my_bunghole

А теперь сравни это с 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.

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

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

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

tp_for_my_bunghole
()
Ответ на: комментарий от byko3y

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 если что. Всё очень быстро в написании и тем более быстро в выполнении программы.
Совершенно разные фломастеры.

tp_for_my_bunghole
()
Ответ на: комментарий от tp_for_my_bunghole

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

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

byko3y ★★★★
()
Ответ на: комментарий от tp_for_my_bunghole

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

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

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

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

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

tp_for_my_bunghole
()
Последнее исправление: tp_for_my_bunghole (всего исправлений: 1)
Ответ на: комментарий от eao197

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

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

tp_for_my_bunghole
()
Последнее исправление: tp_for_my_bunghole (всего исправлений: 1)
Ответ на: комментарий от tp_for_my_bunghole

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

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

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

quantum-troll ★★★★★
()
Ответ на: комментарий от quantum-troll

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

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

tp_for_my_bunghole
()
Последнее исправление: tp_for_my_bunghole (всего исправлений: 1)
Ответ на: комментарий от quantum-troll

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

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

10^200

Minona ★★☆
()
Ответ на: комментарий от byko3y

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

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

tp_for_my_bunghole
()
Ответ на: комментарий от tp_for_my_bunghole

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

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

Нет. Это твоя шиза. Разделяемая память без синхронизации.
Если для кого-то ещё актуальны школьные дискуссии о разделяемых данных в памяти без синхронизации, то ладно.
Если бы контр-аргументы были о том как сверхсложно синхронизировать, это ещё можно было бы принять.

tp_for_my_bunghole
()
Ответ на: комментарий от tp_for_my_bunghole

Нет. Это твоя шиза. Разделяемая память без синхронизации

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

byko3y ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.