Eric Raymond о Rust

Тогда не вижу смысла продолжать разговор

Жаль, что я не узнаю ответов на вопросы.

Про то, как я к чему отношусь писать не буду

_Как_ ты относишься, ты уже написал. А вот _почему_ так относишься, объяснять не стал.

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

Swift и ВНЕЗАПНО Perl. В обоих ARC, если что.

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

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

Да как сказать... я как-то думал, что потребуется для наших драйверов - там было 1) небанально (DMA-мапинг и управление страничной памятью) 2) объем велик (одно за другое цепляется).

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

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

Есть логистическая проблема - компилятор Rust не везде и не для всех архитектур есть. Ну и психология, да.

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

Swift и ВНЕЗАПНО Perl

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

Да как сказать... я как-то думал, что потребуется для наших драйверов - там было 1) небанально (DMA-мапинг и управление страничной памятью) 2) объем велик (одно за другое цепляется).

Частично это можно автоматизировать.

Есть логистическая проблема - компилятор Rust не везде и не для всех архитектур есть. Ну и психология, да.

Это проблемы всех новых языков. Алсо, разве Rust не может через llvm компилиться?

Сборка мусора с отсутствием поддержки циклических ссылок и прочими мерзкими проблемами RC, торчащими наружу. Ок.

Что-то я не вижу засилья прикладного софта с GC

Софт на джаве не в счёт?

Частично это можно автоматизировать.

Автоматизация поможет при повторной генерации оберток. Первый раз всё равно надо будет сделать очень много работы.

Алсо, разве Rust не может через llvm компилиться?

first-tier платформы для Rust - x86, amd64. Для остального ему далеко до C. Ну и для некоторых архитектур ядра LLVM тупо нет.

Сборка мусора с отсутствием поддержки циклических ссылок и прочими мерзкими проблемами RC

Именно так.

Что-то я не вижу засилья прикладного софта с GC.

Skype, Atom, прочий говнософт на electron. На пердоне тоже софта хоть жопой жуй.

Skype, Atom, прочий говнософт на electron

Atom и Electron - это node.js, который на Си++. Остальное - просто веб-приложения.

Atom и Electron - это node.js, который на Си++.

Node.js - это JS, на чём именно написана конкретная реализация - не так важно. А то можно сказать, что пердон - на C, и потому не считается.

Atom и Electron - это node.js, который на Си++.

Node.js - это JS

А emacs - это elisp.

А то можно сказать, что пердон - на C, и потому не считается.

CPython - это и есть Си.

P.S. прикольно у тебя бомбит от Python.

А emacs - это elisp.

Да, так и есть. Ты начинаешь понимать.

CPython - это и есть Си.

Серьёзно? Perl - это тоже C?

P.S. прикольно у тебя бомбит от Python.

Называть Python пердоном - это теперь бомбит? Ты слово «эрратив» когда-нибудь слышал? Я ещё Perl - пердлом, Haskell - хацкеллом, а Linux лялексом или лялехом зову.

А emacs - это elisp.

Да, так и есть

А, тогда окей.

Perl - это тоже C?

Интерпретатор Perl? Да, так и есть.

Называть Python пердоном - это теперь бомбит?

Начинаешь понимать.

твои посты больше похожи на демагогию.

Стараюсь следовать тренду темы.

Ну swift такой же молодой как и rust, и софта на нём столько же. Жаль он не вылазит из своей экосистемы. Я бы спрыгнул на него с rust.

Perl - слишком шутка.

Если вы про тормозные IDE - то нет.

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

А почему? (Не сарказм, реально интересно)

прочий говнософт на electron

Полностью поддерживаю. Зная вебмакак - загнётся через пару лет.

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

Если Rust - это современный C, то Swift - это очеловеченный C++. Имхо.

Увы под винду его нет, и даже под гентой я его собрать не смог. Поэтому пока «ненужно».

PS: килер-фичи swift для меня, в отличии от rust, - это именованные аргументы, перегрузка методов, опциональные аргументы, наследование классов, перегрузка методов... да и вообщем много там вкусностей.

Тут всё ноют, что мол раст весь из себя сложный, а мне на оборот не хватает фич из плюсов...

Спасибо! Звучит разумно.

Ну swift такой же молодой как и rust, и софта на нём столько же.

Ичо? Ты просил язык для прикладного софта без GC, я тебе его привёл.

Зная вебмакак - загнётся через пару лет.

Будет крайне жаль, потому что идея весьма здравая. Отсутствие универсального языка для описания интерфейсов - это очень и очень плохо.

Тут всё ноют, что мол раст весь из себя сложный,

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

Ичо? Ты просил язык для прикладного софта без GC, я тебе его привёл.

Который по сути только под одну платформу - Эппл.

потому что идея весьма здравая

Как только решат проблему тормозов и жора памяти - посмотрим. Пока что sublime за глаза.

Ты просил язык для прикладного софта без GC, я тебе его привёл.

Ок, уточняю: язык для всех популярных платформ. У swift их пока аж две: macOS и iOS.

Собственно основной затык это отсутствие нормального родного гуя.

Это проблема любого языка. Ибо GUI не забота std.

В остальном - это редкое мнение. Все ноют о количестве закорючек и пытаются навязать, всем в треде, Go.

Как только решат проблему тормозов и жора памяти - посмотрим. Пока что sublime за глаза.

Ну у меня не тормозит. Atom меня мало интересует, у меня emacs. Но вот гуйню на Electron писать весьма приятно, хотя до QML не дотягивает слегка.

Проблему тормозов и жора в общем довольно трудно решить, потому что это HTML, CSS и JS. Идеально было бы выкинуть этот ад женского полового органа и сделать что-то чуть более адекватное. Но упс и ах.

язык для всех популярных платформ.

Всех - это каких? macOS - это весьма популярная платформа. Под вендой Swift работает через слой совместимости с лялехом. Если портировать его нативно и приделать Qt, получится вообще офигенно. Хочешь заняться или будешь на ЛОР писать?

Update: Он есть нативный (https://github.com/tinysun212/swift-windows/blob/stable/BUILD-WINDOWS.md). Осталось только Qt заюзать и будет портируемая гуйня на Swift.

Это проблема любого языка.

Ява имеет в std гуй.
Сишарп от мелкомягких тоже, правда он не в std, но под винду есть.

Хипстеры ноют о количестве закорючек и пытаются навязать, всем в треде, Go.

FXD4TGJ

Без гуя либо в эмбедет, либо под вёб. Но в вёбе будет сложно потеснить нынешних фаворитов.

Без гуя либо в эмбедет, либо под вёб

Пока что всё выглядит так, что веб и будет GUI (Electron, Servo).

macOS - это весьма популярная платформа.

5% рынка, если чё.

Хочешь заняться или будешь на ЛОР писать?

Я лучше к расту прикручу Qt.

Он есть нативный

Apple об этом не слухом не духом. Завтра протухнет и всё.

Ява имеет в std гуй.

И не одну реализацию. Правда все унылые.

Сишарп от мелкомягких тоже

Разве он часть языка? Да и GUI под одну платформу - не интересно. Тут Qt вне конкурентов.

Пока что всё выглядит так, что веб и будет GUI
Servo

Если сделают удобный API для встраивания servo в свой проект - это будет пушка. Главное чтоб была возможность выпилить js и вешать rust-овые обработчики событий на элементы. Все-таки до html+css по дизайнерским возможностям ни один гуй не дотягивает

ну, автор всё верно написал. про отсутствие epoll/select - ваще жесть жёсткая.

А в каком виде по вашему они должны быть в стандартной библиотеке? В виде функции select(handlers)?

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

https://doc.rust-lang.org/libc/x86_64-unknown-linux-gnu/libc/fn.select.html

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

Телеграмма-молния: одному из широко известных в узких кругах клоуну не нравится XYZ.

хотя в винде, например, этого select нет.

https://docs.python.org/2/library/select.html
http://perldoc.perl.org/perlport.html#select
https://www.ruby-forum.com/topic/86912#161895

в оффтопике есть WaitForMultipleObjects. что по сути тот же селект, разница минимальна. а вот «одна задача - один сокет» - такого нигде нет. потому что это маразм.

обёртки надо писать, когда архитектура отлажена. а по-хорошему если это ЯП, а не какой-то интерпретатор скриптов, то не обёртки должны быть, а нормальные реализации под разные ОС, со всеми особенностями системных API. никто не делает «обёртки» для стандартных библиотек.

а пока что у них нифига нет, зато пиар на весь интернет.

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

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

И не одну реализацию.

Ну в std всего две, причём swing сверху awt построен.

Правда все унылые.

swing вполне нормальный.
Конечно до qt по скорости не дотягивает, собственно как и java до c++, но та же idea вполне себе нормально работает.

Тут Qt вне конкурентов.

Тут спорить бесполезно. IMHO Qt это лучшее что случилось с GUI в c++ и кроссплатформе в частности.
Но всё-таки некоторые элементы в swing реализованы лучше.

ОЧЕНЬ странный подход, IMHO.

Помои - это то, что вылил на rust автор статьи.

Очень даже логичный подход. HTML+CSS знают все. Electron критикуют в основном, ИМХО, из-за js. Если избавиться от js.. Только представь SPA на Rust, резализация Angular/React на Rust.

Так сказать, вернем аттрибуту language тега script былое величие :)

Идея, кстати, не новая. И очень даже прибыльная

In almost 10 years, Sciter UI engine has become the secret weapon of success for some of the most prominent antivirus products on the market: Norton Antivirus and Internet Security, Comodo Internet Security, ESET Antivirus, BitDefender Antivirus, and others

Только представь SPA на Rust, резализация Angular/React на Rust.

Очень трудно это представить, ведь даже typescript тяжко жожсникам заходит.

А причем тут жожсники. ЦА скорее любители QML, XAML, etc

И у этой вундервафли даже есть Rust-биндинги.

Покажите мне в libc или С++ном stdlib epoll/select.
Это платформоспецифичный API, какое отношение он имеет к языку и стандартной библиотеке?

Я могу ошибаться, но ведь WASM, пусть и не избавит от JS, но хотя бы поможет снизить боль и жор ресурсов