LINUX.ORG.RU

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

RazrFalcon ★★★★★ ()

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

entefeed ☆☆☆ ()

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!

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

makoven ★★★★★ ()

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

rupert ★★★ ()

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

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

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

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

makoven ★★★★★ ()

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

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

Для Ъ:

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

Q.E.D.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

hateyoufeel ★★★★★ ()

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

hateyoufeel ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мне нужно гарантированно обернуть весь 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 рулят.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К чему этот набор банальностей? В низу абсолютно любой системы лежит 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.

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

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

Haskell, Common Lisp, Prolog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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