Eric Raymond о Rust

SPA - это разве не вебня? Да и основная мотивация у электронщиков как я понял: можно писать как взрослые, но на JS. Не очень понимаю зачем нужен еще один Qt. С растом там еще выше входной порог будет.

Вроде как WASM от js не зависит и при большом желании js можно вырезать оставив только WASM и VM. Другой вопрос, можно ли находясь внутри WASM выйти за рамки браузера. Скорее всего для работы с файлами/сокетами/etc все-равно придется писать програму на Rust/etc, а servo подключать в виде dll. В таком случае WASM - лишняя сущность

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

Не очень понимаю зачем нужен еще один Qt

Не все же пишут на c++. (Про качество биндингов qt для других языков спорить не буду. Обсасывали уже тыщу раз). Конечно, если у Servo не будет (если вообще будет хоть какой-нибудь) C API, то, аналогично Qt, он нафиг не нужен

Пользуюсь видеонаблюдением Devline. У них гуй построен на этой вундервафле. Запускается на удивление шустро - доли секунды. Работает очень быстро. Просто небо и земля по сравнению со скоростью работы тормознутого IVMS-4200 (на qt)

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

Ты снова всё поняла неправильно.

да вроде мужик там всё чётко, чёрным по белому написал. что же там непонятного?

Слишком толсто, прочитайте хоть https://doc.rust-lang.org/book/ffi.html, всё есть.
Алсо, как уже заметили, есть mio, который и есть «нормальная реализация под разные ОС, со всеми особенностями системных API»

да, но есть одна простая вещь: использование системных API напрямую всегда гибче и оптимальнее. поэтому, например, буст и Qt намного тормознее прямых вызовов.

Обмазываетесь FFI и вперед, полная свобода.
Опять же и FFI биндинги и safe-обертка есть в том же mio https://github.com/carllerche/mio/tree/master/src/sys

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

А ты, собственно, кто? Еще один generic senior C++ developer?

Rust мертво, смиритесь уже. Радуйтесь, что работодатели повелись на мантры Страуструпа об «эффективном C++» и платят деньги за быдлокодинг на этой погани. Потому как по большому счету и C++, и Rust одинакого убоги и непригодны для прикладухи: слишком много возни с никому не нужными деталями, слишком много всего происходит за кулисами незаметно для программиста.

Каждый раз, когда я вижу очешуительный код очередного крестодятла, наблюдаю один и тот же паттерн: «я тут прочитал про template metaprogramming и нахреновертил вот такую каку». При этом «кака» компилируется по несколько минут, а чтобы ее осознать, нужно потратить полдня минимум. Оно и неудивительно: у крестодятлов и растодебилов одинаково недоразвит мыслительный процесс, поэтому бедолаги вынуждены излагать свои убогие мысли сиспользованием убогого инструмента. В итоге имеем убогость²

просто системные вызовы

Сурово. На одних syscall() писать. Или таки обмазываетесь POSIX-ом? :)

Вкусовщина и демагогия вместо аргументации, но тем не менее Вы почему-то позволяете себе оценочные суждения по поводу «кривости» языка, о котором совершенно ничего не знаете, как и Эрик :)
Высокомерие — это профессиональная черта?

В Perl - сборка мусора. И неважно, что она реализована на reference counting.

Ну и в C++ сборка мусора, и неважно, что она реализована на shared_ptr/uniq_ptr.

Ему не нужен select, ему нужна красивая кросс-платформенная обёртка, но чтобы была точно такая-же как select, хотя в винде, например, этого select нет.

Не позорься, а. Как раз select в винде есть.

И poll есть со времен висты, кажется

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

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

Тенденция и программировании, я вижу, прослеживается

Тенденция и программировании, я вижу, прослеживается

О каких инструментах ты говоришь? Что революционно нового изобрели со времен Visual Basic?

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

А так же вывод типов, AlgDT, RAII, ООП (если применено к месту), и раз уж это тред раста, то еще и статические гарантии type, thread и memory safety

При чем тут VB?

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

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

Как ни странно, но ошметки праведного гнева летят от крестолюбов и прочей растаманской гвардии. Мне-то глубоко фиолетово, кто и на чем пишет до тех пор, пока эти поделки меня не касаются.

Ну хотя бы дженерики, начнем с простого

Диды завещали для этого использовать макросы и многократное включение одного и того же файла. Геморно? Да, зато пять раз подумаешь, обоснован ли твой шаг. Это тебе не std::map<std::vector<bool>,std::vector<std::set<std::string>>>> лепить к месту и нет.

И да, компилтайм метапрограммирование это огромный шаг впедед

Вот именно, что «впедед». Что будешь делать, если «что-то пошло не так» в многоэтажной темплейтной конструкции? А как будешь осознавать такие конструкции в чужом коде?

Ну и раз пошло такое дело, полноценное компайл тайм метапрограммирование есть в lisp, но никак не в C++. Даже несмотря на все потуги с constexpr-ами, писать сложную логику на тесплейтах можно только по фану и любой грамотный тимлид такой фан зарубит на корню, ибо неподдерживаемо.

А так же вывод типов

Какие проблемы он решает? Накидывание компонент на форму мышкой сэкономило миллиарды человекочасов. Крестовые auto и decltype уже успели убить не один миллион человекочасов людей, которым достался чужой лапшекод. Просто чтобы ты представлял, насколько легко обосраться на ровном месте:

auto e = my_container.first(); // e — это итератор, ссылка (как в dequeue.front()) или копия первого элемента?

RAII, ООП

Это старше VB.

Что будешь делать, если «что-то пошло не так» в многоэтажной темплейтной конструкции?
А как будешь осознавать такие конструкции в чужом коде?
сложную логику на тесплейтах можно только по фану

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

Накидывание компонент на форму мышкой

Не взлетело вместе с языками со встроенным визуальным интерфейсо-клепательством.

Какие проблемы он решает?

Можно использовать полноценные имена типов вместо ebdeqghzndh и не страдать от Javaвского

VeryLongProductionCodeContainerTypeName<VeryLongDataTypeName> items = new VeryLongProductionCodeContainerTypeName<>();

e — это итератор, ссылка (как в dequeue.front()) или копия первого элемента?

Особенности STL и синтаксиса C++ не особо много говорят от type inference.

Это старше VB.

И что?

unique_ptr - не сборка мусора, а shared_ptr - вполне.

Мужик ничего не понял, а ты всё поняла неправильно.

И что?

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

Можно использовать полноценные имена типов вместо ebdeqghzndh и не страдать от Javaвского

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

Покажите мне в libc или С++ном stdlib epoll/select.

$ nm -D /lib64/libc.so.6 | grep epoll
00000000000e9e30 T epoll_create
00000000000e9e60 T epoll_create1
00000000000e9e90 T epoll_ctl
00000000000e9aa0 T epoll_pwait
00000000000e9ec0 T epoll_wait

Зачем ты принес сюда свою крестоболь?

Я очень сочувствую, что кресты тебя чем-то обидели в детстве но посмотри теги треда, да и при чем тут вообще C++, когда речь о выводе типов в общем случае?

Если бы я хотел спросить про glibc, я бы спросил про glibc. GNUшные расширения языка и библиотеки — это точно такая же платформозависимость как и сисколлы ядра Linux, только в другой плоскости.

В жабке, кстати, auto хотят сделать сильно ограниченным

В жабке много что сильно ограничено, из новых фич, которые притянули из ФП.

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

Дак комитет с себя сразу снял ответственность в этом плане: хочешь что-то использовать — будь добр ознакомиться в деталях, иначе ССЗБ. А использовать фичу или нет — твое собственное решение.

kawaii_neko ★★ безумный сишник

Очень даже логичный подход. HTML+CSS знают все.

Нахрен мне в моём приложении ещё и браузер держать? Блоатварь жеж в чистом виде.
Кому-то может и нормально, но мне от Rust'а хотелось бы компактности.

Нахрен мне в моём приложении ещё и браузер держать?

А что у тебя за приложение?

мне от Rust'а хотелось бы компактности.

Ну так Servo/Electron/whatever - сторонняя библиотека, не хочешь - не используй.

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

Electron

Я так понимаю, он 2 VM использует - одну для браузера, одну для node.js. Жесть жестянская

ESR обычно херни не напишет.

Не только написал, но и показал себя хамлом.

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

И где такое есть?

У раста, конечно, есть свои проблемы, но аргументов в духе «есть unsafe = нет гарантий» я не понимаю. Ведь много где будет такое же разделение на «небезопасные внутренности» и более-менее безопасный интерфейс. Раст хоть в какой-то степени помогает это разделение поддерживать: и на уровне проверок и на уровне кода (явный unsafe проще обнаружить).

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

Ну-ну.

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

Тем не менее, у С и С++ ниша есть, причём это не только легаси. Даже учитывая неспособность раста заменить эти языке полностью в их нишах, всё равно место остаётся.

Жаль он не вылазит из своей экосистемы.

За ним куда большие деньги стоят. Не знаю насколько активно он на других платформах применяться будет, но в вакансий на нём больше, а будет ещё больше.

Я бы спрыгнул на него с rust.

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

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

Диагноз - это сектантские помои на человека, просто выразившего свои первые впечатления.

«Впечатления» тоже можно по разному выражать.

Скажем, претензия к документации, как по мне, выглядит достаточно странной, аналогично с конкатенацией строк («fussy, obscure ritual»). Да, в языке есть непривычные (может даже «неудачные») вещи, но хотелось бы какой-то конкретики, а не детский сад про строки. Особенно в сравнении с С.

Что будешь делать, если «что-то пошло не так» в многоэтажной темплейтной конструкции?

Разбираться и фиксить, как и с любым другим кодом.

А как будешь осознавать такие конструкции в чужом коде?

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

Разбираться и фиксить, как и с любым другим кодом.

Любой другой код можно дебажить в отладчике, ставить брейкпоинты, отладочную печать и прочее. В темплейтах ничего этого нет.

Кстати, тебя не смущает, что его даже в такие консервативные языки как Java добавляют?

Я уже писал об этом выше.

Любой другой код можно дебажить в отладчике, ставить брейкпоинты

Ну положим не любой.

В темплейтах ничего этого нет.

Да ладно? Есть всякие штуки типа templight.

Я уже писал об этом выше.

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

Ну давай на твой пример ещё раз взглянем: auto e = my_container.first();. Явное указание типа тут тоже не сильно поможет: T e = my_container.first(); И что метод вернул? Ссылку и значение было скопировано? Другой тип или прокси, которые преобразовались к нашему типу? В конце концов, можно написать auto& и решить этим часть проблем. Собственно, как и со всем остальным, имеем компромисс: в чём-то выигрываем, в чём-то проигрываем. И да, можно использовать не к месту и затруднять чтение кода, но к front это в 99% случаев не относится.

что ты ярый «фанат раста».

Я не фанат и не ярый. Я использую то, что мне нравится. Был бы swift под все ОС - использовал бы его.

Мне нравятся идеи rust, особенно беспроблемная статическая сборка под разными ОС. Из альтернатив тут только Go, но от него плакать хочется.

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

по «бытовому удобству» свифт, конечно, сильно впереди.

Гуй писать, судя по примерам, - просто сказка. Увы, пока только под две платформы. Был бы Qt на swift - жизнь бы стала намного лучше. И плазма перестала бы падать.

За ним куда большие деньги стоят.

Это понятно, только вливают их только в свою экосистему.

LOL

А что у тебя за приложение?

Ну из-за отсутствия GUI для Rust'а никакого приложения нету.
Была мысль одну тулзу переписать с Java, но не судьба.