Eric Raymond о Rust

Удалено по причине 4.8

а как же «о»?

Лул. И сюда притащили этот бред...

прочитай обе, бреда там нет на самом деле

Как ты посмел на швятой раст наехать, ну все, сейчас хвостострел тебе лицо банхаммером сломает.

Not only that, but it seems the CSP implementation in Rust – the most tractable concurrency primitive – has limits that make it unusable for NTPsec’s purposes (only selection over a static set of channels is possible) and there is some danger that it might be removed entirely!

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

То-то я думал, что все вдруг кинулись обсуждать мнение этого чудика? А это оказывается сам ESR! В таком случае, надо пойти перечитать его пост ещё раз. ESR обычно херни не напишет.

Первый его пост — эталонное «раст плох, потому что я не осилил». Просто удивительно.
Второй поднимает реальную проблему, которая, однако, не специфична для раста.

Второй поднимает реальную проблему

Тоже мне проблема. Релевантный поиск гугла и звездочки на гитхабе - вот тебе и BDFL, даже получше углеводородного )

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

Удачные концепции перетекут в другие языки, а сам Rust так и останется уделом маргиналов.

Для Ъ:

Rust is at present a poor fit for NTPsec’s requirements

Q.E.D.

Rust так и останется уделом маргиналов

Только маргиналов становится всё больше и больше.

Rust is at present a poor fit for NTPsec’s requirements

И аргумертировал это «Строки склеивать сложна. select в язык не встроили. А вот Го я за 4 дня выучил». Всех, кто пытался объяснить ему про MIO/tokio-rs, во второй статье обозвал фанатиками

Только маргиналов становится всё больше и больше.

Знать бы только откуда они берутся. Для ядра он не подходит на данный момент (где-то даже лежат попытки переписать некоторые модули ядра на rust ― от него оказалось больше проблем, а пользы от его безопасности, когда все вокруг unsafe, никакой), а в пространстве пользователя есть множество других языков, и rust по сравнению с ними тут тоже смотрится блекло. Для Ъ-безопасного кода лучше уж на Haskell с Coq.

Если станет вдруг вменяемым, либо будет хороший форк, то к этим вашим rust-маргиналам с радостью присоединюсь, а пока просто попкорн и наблюдение за тем, куда же это выведет.

прочитай обе, бреда там нет на самом деле

Я читал оба - там бред. И забавные комментарии.

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

Удачные концепции перетекут в другие языки, а сам Rust так и останется уделом маргиналов.

Пророки в треде.

Для Ъ-безопасного кода лучше уж на Haskell с Coq.

Упоролся что ли? Покажи мне адекватную реализацию какого-нибудь AES на Haskell, не страдающую от timing attack?

Скажите мне, ESR в последние лет 20 что-то кроме нытья вообще произвёл на свет?

Да ну его в жопу, я ему как-то написал, что его поделие отжирает 16 гигов оперативы после суток работы и падает, а он мне в ответ предложил купить больше памяти.

Пророки в треде.

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

В 3-ring я ему не могу найти применения.

я не вижу, чтобы он развивался на качественном, а не количественном, уровне, в рамках задач в нулевом кольце.

А хотя бы определить, что такое «развиваться на качественном уровне», можешь?

В 3-ring я ему не могу найти применения.

По крайней мере честно. Похоже, Rust потерял одного программиста, но я уверен, что он это переживет. Хотя... нет, не потерял. Просто не приобрел.

Из Стенфорда читал буквально только что статьи о том, как они решают проблемы с таймингами, применимо к Haskell. Нагугли — проблемы решаемы. Тем более, что никто не заставляет писать все на Haskell — кусок можно на Си или том же Rust.

А хотя бы определить, что такое «развиваться на качественном уровне», можешь?

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

Мне нужно гарантированно обернуть весь unsafe так, чтобы далее его не трогать

Это называется «проектирование программ» и является твоей личной ответственностью.

а для всей unsafe прослойки иметь возможность верификации.

Автоматической верификации?

Иначе по сравнению с Си преимуществ нет, а производительность ведь падает.

дабл_фейспалм.жпг

Т.е. ADT, дженерики, трейты, memory safety - не преимущество? Ты когда на Си последний раз писал?

Это называется «проектирование программ» и является твоей личной ответственностью.

Я не считаю себя идеальным программистом, который никогда не совершает ошибок. Тем более, что проект из одного человека это редкость.

Ты когда на Си последний раз писал?

Сегодня. Сейчас. Я для ядра Linux модули пишу, поэтому почти все рабочие задачи это Си.

Автоматической верификации?

Не совсем верный термин использовал. Имею ввиду, что должна быть возможность навертеть safe над unsafe с уверенностью.

Т.е. ADT, дженерики, трейты, memory safety - не преимущество?

Memory safety там нет, потому что unsafe. А остальное там, в больше случаев, не к месту совсем. Код ядра ведь видел? Простота наше все.

Мне нужно гарантированно обернуть весь unsafe так, чтобы далее его не трогать

Это называется «проектирование программ» и является твоей личной ответственностью.

Я не считаю себя идеальным программистом, который никогда не совершает ошибок.

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

Ты когда на Си последний раз писал?

Сегодня. Сейчас

А на чем-то повыше уровнем?

Имею ввиду, что должна быть возможность навертеть safe над unsafe с уверенностью.

Прекрасно. И что тебе мешает? Контрольный вопрос: что, по-твоему, означает «unsafe» в Rust?

Memory safety там нет

Где «там»?

Код ядра ведь видел?

Да. Я тоже пишу модули ядра.

А остальное там, в больше случаев, не к месту совсем

Везет тебе - дженерики не нужны. Наверное, и list.h не используешь, и rbtree.h?

[xx@yy drivers]$ grep -E -r "/(list|rbtree).h" kernel drivers fs | wc -l
822

Простота наше все.

Правда? А я думал, Coq и Haskell рулят.

Ага, человек пишет, что: Go больше похож на Си, чем rust и конкатенация строк в Си проще чем rust.

Не знаю как вам, но как по мне - это диагноз.

Да, я понимаю. Я к тому, что хацкелл - не универсальное лекарство и не везде применим.

Сегодня. Сейчас. Я для ядра Linux модули пишу, поэтому почти все рабочие задачи это Си.

Еще один с синдромом утёнка на уровне kawaii_neko?

Еще один с синдромом утёнка на уровне kawaii_neko?

И много кода ты видишь в ядре не на Си, товарищ не утенок?

То есть кроме ядра писать больше нечего?

И много кода ты видишь в ядре не на Си, товарищ не утенок?

В ядро netbsd вроде lua запихивали. Тотальный C в лялехе связан не столько с какими-то выдающимися особенностями языка, сколько с легаси и ЧСВ Линуса. На том же Rust можно модули даже сейчас писать, если придумать что делать с адом сишного препроцессора.

На том же Rust можно модули даже сейчас писать, если придумать что делать с адом сишного препроцессора.

Обернуть API ядра в Rust, даже без препроцессора - это огромная работа, которую никто не будет делать. Потому что Линус тупо не примет ядро модули на Rust.

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

Тут дело совсем не в том, чтобы строить слои абстракции. Дело в безопасности (as in safe) полученного слоя. Те, кто уверен в том, что такие вещи легко решаются просто наличием скиллованного чувака, часто в конце получают тоже самое. Программисты, не совершающие ошибок — миф. Поэтому нужна помощь многократно проверенного компилятора, который будет выводить тип функции исходя из побочного эффекта и сравнивать его с декларацией. Либо внешних проверок.

А на чем-то повыше уровнем?

Haskell, Common Lisp, C#, Java, Go, Prolog и еще очень всего. Rust в их числе. И да, это все гораздо дальше Hello world.

Правда? А я думал, Coq и Haskell рулят.

Толсто. Haskell гораздо проще, чем Rust.

Везет тебе - дженерики не нужны.

Не передергивай. Я не говорил о том, что что-то не нужно.

Да. Я тоже пишу модули ядра.

И как с применением rust? Расскажи, как применяете в работе, и все такое.

То есть кроме ядра писать больше нечего?

Вне ядра есть тысячи языков, которые привлекательнее rust.

Да ну? Перечислите языки без GC для прикладного софта.

Упс, их аж два: C++ и Rust.

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

К чему этот набор банальностей? В низу абсолютно любой системы лежит unsafe-код. Ты можешь изложить претензии, специфичные для Rust?

Везет тебе - дженерики не нужны.

Не передергивай. Я не говорил о том, что что-то не нужно.

А, ну да. Ты сказал по-другому:

jollheef> в больше случаев, не к месту совсем

При том, как минимум 800+ модулей кода в ядре используют типичные дженерики, насколько Си их позволяет.

Haskell, Common Lisp, C#, Java, Go, Prolog и еще очень всего. Rust в их числе. И да, это все гораздо дальше Hello world.

На всё это «гораздо дальше Hello world» не хватит жизни, но допустим. С этим огромным опытом, ты всё еще считаешь, что в случае ошибки «int foo()» должна возвращать -1? А «struct xxx *foo()» - NULL? Что лапша «goto err» для чистки ресурсов - лучше, чем RAII?

Haskell гораздо проще, чем Rust.

Ты не знаешь либо Haskell, либо Rust. Или ни одного из них.

Да. Я тоже пишу модули ядра.

И как с применением rust?

Ровно никак. И, я думаю, Rust в ядре Linux не будет еще много лет (или даже никогда).

Расскажи, как применяете в работе, и все такое.

На целевых платформах нет компилятора Rust, так что не применяем.

Вне ядра есть тысячи языков, которые привлекательнее rust.

Ахаха, да что ж ты делаешь, прекрати.

Haskell, Common Lisp, Prolog

Лул, и много на них софта написано? Особенно за последние лет 5. Если Haskell еще шевелится в определённых кругах, то вторые два вообще мертвы.

Не так много софта, где GC платформы будет злом. Поэтому ввел бессмысленные ограничения — получил на выходе бессмысленный ответ.

Речь не шла о том, что из перечисленного популярно. Речь о том, что не Си единым жив человек (в данном случае этот человек — я).

А, ну да. Ты сказал по-другому:
jollheef> в больше случаев, не к месту совсем
При том, как минимум 800+ модулей кода в ядре используют типичные дженерики, насколько Си их позволяет.

1. В большинстве случаев относилось ко всему в среднем, а не только к дженерикам. 2. Ты почему-то решил, что я сказал «дженерики не нужны», и с упорством это опровергаешь. Ты просто понял совершенно другое, отличное от того, что я имел ввиду.

С этим огромным опытом

Мой опыт — хрень, а не опыт.

На всё это «гораздо дальше Hello world» не хватит жизни,

Ээ… что? Либо ты имеешь ввиду «дальше hello world» это огромные проекты, либо ты упоролся. Набор языков детский.

Ахаха, да что ж ты делаешь, прекрати.

Ахаха, да что ж ты делаешь, прекрати.

Но это все хрень. Бессмысленный флейм, потому что holy war. Спорить о goto я не буду.

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

Ты почему-то решил, что я сказал «дженерики не нужны», и с упорством это опровергаешь.

Ты сказал «остальное» (т.е. всё, кроме memory safety) - это очевидно включает в себя дженерики.

Ты просто понял совершенно другое, отличное от того, что я имел ввиду.

Так расскажи, что ты имел в виду.

Набор языков детский.

Языки _очень_ разные и набор языков _открытый_ («еще очень всего» - наверное, «еще очень много всего»). Но неважно, ты можешь быть гением... на вопрос о возвращаемых значениях ответишь? Про определение unsafe, про специфические претензии к Rust?

Спорить о goto я не буду.

Речь не о споре. Речь о том, что ты, лично ты, считаешь лучшим для очистки ресурсов - RAII или goto.

Ты лучше про ваш опыт rust в расскажи, не игнорируй мой вопрос

Про «наш» опыт я ответил, см. выше. Мой личный сводится к хелловорлдам.

Не так много софта, где GC платформы будет злом.

Что-то я не вижу засилья прикладного софта с GC. Разве что проги на C#, но они только под мастдай.

Речь не шла о том, что из перечисленного популярно.

То есть маргинальные языки - это ок, а раст не очень популярный - значит в утиль. Логика /0.

раст не очень популярный - значит в утиль.

Я такого не говорил.

Ты один питоно-софт посчитай.

Просто экстраполировал текущее развитие rust вперед во времени.

А что его считать? Там прикладного нет. Все поделия на PyQt унылы и тормозят. Для скриптов/демонов, где не важна производительность - сойдёт.

Да ну? Перечислите языки без GC для прикладного софта.
Лул, и много на них софта написано?
Что-то я не вижу засилья прикладного софта с GC

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

Мой личный сводится к хелловорлдам.

Тогда не вижу смысла продолжать разговор. Не пиши мне только в ответ что-нибудь троллоло в стиле «сомнений в твоих компетенциях» — я этого не говорил. Про то, как я к чему отношусь писать не буду, так как в последующем мне участвовать не хочется — лучше еще раз потыкаюсь в модули ядра на rust — может и что придумали, чтобы это можно было применять в реальных проектах.

Может кто-нибудь ворвется в тред и продолжит. Мне лень в тысячный раз одни и те же holy war вести.

Обернуть API ядра в Rust, даже без препроцессора - это огромная работа, которую никто не будет делать.

Обернуть нужные для одного конкретного модуля api - не самая большая проблема.

Потому что Линус тупо не примет ядро модули на Rust.

Как я и сказал. Технических проблем особо нет.