Презентация «Rust - лучше, чем C++» на русском языке от разработчика из Яндекса

Фичи и костыли это разные вещи.

Когда будут биндинги к Qt?

Почему в примере из туториала, где мы выводим hello, скомпилированный бинарь весит почти 800кб? ЧТО ЭТО??

Да я как раз то осилил (в той мере, в которой С++ можно осилить, конечно же, ибо в стандарте С++ столько неоднозначностей и каждый компилятор при этом ещё имеет свойство подливать своего говнеца, что слово «осилить» становится практически бессмысленным). Просто когда после цати лет я вместо С++ познакомился с языками программирования, стало очень жалко потраченного впустую времени.

а язык богат фичами как ни один другой

Это какими такими фичами богат С++? Пародией на макросы? Убогой системой типизации? Прикрученным наспех подобием на introspection? Недоделанной стандартной библиотекой? Отсутствием нормальных средств для многопоточного программирования? Ходящими на костылях конструкциями для ФП?

ты же не любил мл-семейку, что они с тобой сделали?!

Какая разница, сколько весит бинарь? Это rts.

Standard ML, если его допилят по последним советам Харпера

Где опубликованы его последние советы?

А что такого ценного в зеленых потоках? Быстрее «родных» они работать на современном железе не могут, для И/О требуют костылей.. Какой в них смысл?

Как правило, требуют на порядки меньше памяти. Это позволяет, соответственно, запускать на порядки больше потоков на той же машине.

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

Где опубликованы его последние советы?

Может «future of sml» имеется ввиду: http://www.cs.cmu.edu/afs/cs/user/rwh/public/www/home/

// А этот аргумент от буддиста уже проскакивал, не исключены элементы идеи-фикс.

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

https://www.cs.cmu.edu/~rwh/talks/mlw13.pdf

Презентация «Ненужно - лучше, чем C++» на русском языке от разработчика из Ненужно

очевидный фикс

что так всем неосиляторам чешется чем-нибудь С++ заменить

Там, конечно, всё круто (хотя я понял не больше трети), но всё это не сделает SML языком системного программирования.

Какая разница, сколько весит бинарь? Это rts.

Что значит, какая разница? А как же юникс вей? Вот, предположим, сидит у меня 10к утилит средним размером 50кб, то есть общий объем около 500мб. Тут все разработчики вдохновились и переписали свои утилиты на Rust, средний объем вырос до мегабайта, общий объем стал 10 гигов вместо 500 мегабайт. За такое надо в голову бить. Раз уж разработчики Rust позиционируют свой язык как более качественная замена С++, то нужно соответствовать. Более удобный синтаксис никому не интересен. Везде, где в итоге выбрали С++ как основной язык проекта, вопрос о синтаксисе не поднимался вообще.

Эта «проблема» в той или иной степени относится ко всем промышленным языкам программирования. Различное написание кода регламентируется внутренними правилами конкретного проекта.

требуют на порядки меньше памяти

Вот прямо на порядки? То есть если зеленый поток нормально так укладывается в 10кб, то родной такой же будет отжирать сразу 100кб или даже мегабайт? С чего бы это? Или ты говоришь только про размер контекста, который и там и там - проценты (или доли процента) от размера задачи? И даже при этом, чего такого хранит ОС, что у нее контекст потока оказывается прямо таки на порядки больше, чем у зеленых потоков?

Возможно, планировщик зелёных потоков будет работать оптимальней, чем ОС планировщик

и почему?

Зеленые потоки можно размазать по потокам ОС

Тогда зачем городить огород? Можно просто использовать потоки ОС и не придумывать лишних сущностей.

А можно не размазывать

Тогда будет использоваться одно ядро, и соответственно производительность будет проседать.

Посмотрел, код на go читается таки существенно проще, и в целом проект как то попродуманнее. Но победит конечно rust, потому что рынок любит уродцев, как выразился Kron73. А впрочем, всё равно, жить будут параллельно.

Тогда зачем городить огород? Можно просто использовать потоки ОС и не придумывать лишних сущностей.

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

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

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

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

Вот прямо на порядки?

На порядок.

То есть если зеленый поток нормально так укладывается в 10кб, то родной такой же будет отжирать сразу 100кб

То есть если зеленая нить укладывается в 300-400 байт (видел такие цифры для Erlang и раннего Rust), то нить ОС берет минимум 12КБайт (4К юзерспейс и 8К ядро).

300-400 байт ... Rust

Это вместе со стеком и контекстом исполнения на x86_64? Не верю. Пруфлинк, пожалуйста.

Повезло вам, робятки, що я этот "раст" в душе не видел!

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

300-400 байт ... Rust

Это вместе со стеком

Да. Почему ты убрал Erlang из цитаты?

Не верю.

Твое право.

вот я понимаю, почему отказываются от php, руби реально лучше намного, и проекты на нём, более легковесный и просты в обслуживании, но чем замена с++ на go и раст облегчит обслуживание софта и потребление ?

чем замена с++ на go и раст облегчит обслуживание софта

Я не предлагаю менять Си++ на Rust. Преимущество Rust перед Си - более богатая и выразительная система типов, перед Си++ - то же + относительная простота.

и потребление ?

Щито?

Мантис написанный на php ест больше чем redmine написанный на руби, при тех же функциях и кол-ве опций. Хотя возможно я что-то лишнее не отключил в мантисе.

erzent очевидно большой любитель употребить.

erzent ★★ (06.07.2014 21:13:08) из vhdl весом 1 терабайт

Rust не победит Go потому что за Rust - Mozilla, а за Go - Google

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

> Зеленые потоки можно размазать по потокам ОС
Тогда зачем городить огород? Можно просто использовать потоки ОС и не придумывать лишних сущностей.
> А можно не размазывать
Тогда будет использоваться одно ядро, и соответственно производительность будет проседать.

Это если выбирать одно из двух.

Если использовать оба подхода:

- что не зависит друг от друга (или совсем-совсем требует блокировки) - разбрасывать по OS threads

- всё остальное - ставить в очереди на исполнение.

Получим лучшее из двух.

ставить в очереди на исполнение.

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

лору же прямо говорить нельзя, тема мертва будет.

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

Почему ты убрал Erlang из цитаты?

1) Мы обсуждаем Rust 2) Erlang мне не интересен 3) можешь привести пруфлинки и про Erlang, если хочешь, они никому не помешают.

Твое право.

Я это рассматриваю как признание, что про 300-400 байт на поток в rust - это никак не связанная с реальностью выдумка.

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

Обычно зеленый поток это:

• указатель на (байт)код текущей инструкции треда
• указатель на стек
• состояние (один из «заблокирован-по-причине», «готов к работе»)

Рантайм создает очередь из таких структур. Создаются элементарно, уничтожаются элементарно.

OS треды обрабатывают такую очередь (или такие очереди).

Против очередей я ничего не имею.

Но это самая простая реализация зеленых потоков :]

UPD: поправил скобку

1) Мы обсуждаем Rust

Не знаю насчет «нас», но я говорил о зеленых нитях.

Я это рассматриваю как признание

Рассматривай.

Хотя в данный момент Rust ещё не подходит для использования в продакшне, его всё равно стоит изучать.

Еще один паскаль?

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

еще один хаскель

Обычно очередью исполнения называют очередь, в которую один потом (или несколько) помещает задачи для последующего исполнения, а другой поток (или несколько) - забирают задачи и исполняют их. В этом случае родные потоки прекрасно справляются с задачей.

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

было уже в freebsd 6.0 потоки в режиме пользователя. KSE называлось

непонятно зачем городить для этого еще один язык

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

Кто-то должен исполнять зеленый поток. Весь смысл в них в том, что планировщик реализован рантаймом языка (или либы), не OS.

Если мы имеем M OS treads (исполнители) и N green threads (задания) - какие логические структуры данных можно выбрать для реализации планировщика green threads?

Да че вы вообще их сравниваете? Go это язык со сборщиком мусора. Rust в общем нет (да, я знаю про опциональный gc). На Rust по идее можно эффективно писать ОС и игры.

Давай еще раз: термин «очередь исполнения» (execution queue) имеет определенное более-менее устоявшееся значение. Ты его применил в другом значении, что вызвало некоторое недопонимание, которое уже разрешилось. Дальше-то ты мне что пытаешься доказать? Зеленые потоки можно внутри рантайма кучей способов реализовать, в том числе используя очередь. От этого они не превратятся из зеленых потоков в execution queue или даже в просто queue (если не понимаешь почему, гугли термины «инкапсуляция» и «сокрытие реализации»).

А по теме: ненужное баловство эти зеленые потоки.

Кхм, rustc -C prefer-dynamic ###.rs.

Очередная веб параша ...

При чем тут веб? Увидел Яндекс и Мозиллу? :)

Оно тогда не запускается, если rust удалить

Оно тогда не запускается, если rust удалить

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

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

Вот прямо на порядки? То есть если зеленый поток нормально так укладывается в 10кб, то родной такой же будет отжирать сразу 100кб или даже мегабайт? С чего бы это? Или ты говоришь только про размер контекста, который и там и там - проценты (или доли процента) от размера задачи? И даже при этом, чего такого хранит ОС, что у нее контекст потока оказывается прямо таки на порядки больше, чем у зеленых потоков?

Когда последний раз я проверял, стек по умолчанию отжирал 2 мегабайта. Можно его ограничить, но что будет, если вдруг потоку понадобится что-нибудь рекурсивно повызывать? Возможности динамически расширить стек, когда он кончился, я не видел в C. В зелёных потоках это реализуемо.

и почему?

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