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

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

Адресного пространства.

Возможности динамически расширить стек, когда он кончился, я не видел в C.

О вау.

отжирал 8 мегабайтов

Разницу между «8 МБ памяти» и «8 МБ адресного пространства» сам нагуглить сможешь?

миллионах потоков

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

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

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

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

там слишком много своей специфики.

Ну и чего там за специфика? Ты про нуму что-ли? Тоже мне - специфика.

что-нибудь рекурсивно повызывать

гцц уже давно хвостовую рекурсию поддерживает. Правда не портабельно, да. Но если не шашечки, а ехать, то и стека большого не надо.

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

Дальше-то ты мне что пытаешься доказать?

Одно единственное. Привожу пример реализации для опровержения:

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

Быстрее родных работать могут, для I/O костылей требовать не обязательно (хватит только на I/O апгрейдить green thread до OS thread).

Разницу между «8 МБ памяти» и «8 МБ адресного пространства» сам нагуглить сможешь?

Тут я написал фигню, признаю. Видимо будет 4 килобайта для неглубокого стека + всё остальное. В общем tailgunner там всё расписал, мне добавить нечего.

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

А с чего ты взял, что миллионы потоков должны выполняться одновременно? Типичная ситуация - все эти потоки ждут ответа от базы или от другого сервиса по сети и при получении данных просыпаются, что-то делают и засыпают. Скажем у нас 8 ядер. Поток делает несложное действие раз в 20 минут. Как раз на миллион выйдет, если каждое ядро будет обрабатыавть по 100 потоков в секунду.

Такое можно и на C сделать. Или select-ом (epoll-ом или какой аналог сейчас принят) со state-машиной, или, наверное, callback-ами, как принято в node.js. Но с зелёными потоками это выглядит лучше, а работает не хуже.

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

гцц уже давно хвостовую рекурсию поддерживает. Правда не портабельно, да. Но если не шашечки, а ехать, то и стека большого не надо.

При чём тут хвостовая рекурсия? Только наркоман будет писать на C то, что можно оптимизировать хвостовой рекурсией. Это записывается циклом всегда и очевидным способом. Хвостовая рекурсия нужна в функциональных языках без изменяемых переменных. В императивных языках это тупо оптимизация «чтобы было». Попробуй написать реализацию функции Аккермана, чтобы она не жрала стек, для примера. Только если его имитировать своей структурой данных.

Думаю их там порядка миллиона и работает. Ну и в дурку вроде ниодного разработчика не сдали

Омг. Процессы эрланга это не потоки ос.

Как у него дела с интеграцией с другими языками и подключением сторонних библиотек?

Много фич там еще/уже добавили из эрланга: (атомы, паттерн-маттчинг, списки, кортежи, хвостовая, hot code loading)?

ASM можно в коде?

10+ млн. процессов можно создать?

Для какого рынка эти rust и go предназначены? Воевать с C/C++/object C/C# они хоть и хотят, но ИМХО не в состоянии. Им уже 4 и 5 лет соответственно, а что на них написали?

Им уже 4 и 5 лет соответственно

всего в 3 раза меньше чем тебе.

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

Не в 3, а в 5.

На примере scala видно, что современному языку нужно минимум 10 лет, что бы раскрутится, и это оптимистичный сценарий. Так что ждем еще лет 5, а там видно будет.

Дык Rust в основном во время компиляции и проверяет все. У них там заявлено «zero cost abstractions»

Ну тогда ок. Сколько твоему до диезу, со всей проталкивательной мощью MS, понадобилось чтобы на нем хоть кто-то что-то написал.

http://www.tiobe.com/index.php/content/paperinfo/tpci/C_.html

И сейчас он не на высоте, так скажем. А вот еще с русской вики:

Проект C# был начат в декабре 1998 и получил кодовое название COOL (C-style Object Oriented Language). Версия 1.0 была анонсирована вместе с платформой .NET в июне 2000 года, тогда же появилась и первая общедоступная бета-версия; C# 1.0 окончательно вышел вместе с Microsoft Visual Studio .NET в феврале 2002 года.

смотри ка, те самые 4 года до стабилизации.

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

А scala раскрутился? По рейтингу он уступает go...

10+ млн. процессов можно создать?

Толстый зеленый фанбой Эрланга детектед.

Типичная ситуация - все эти потоки ждут ответа от базы или от другого сервиса

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

Кстати,

Возможности динамически расширить стек, когда он кончился, я не видел в C

man 2 setrlimit | grep RLIMIT_STACK

А вот это уже хорошо. Кстати, насколько низкоуровневый код он позволяет писать? Драйвер на нём написать можно?

Омг. Процессы эрланга это не потоки ос.

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

А много алгоритмов позволят тебе создать 10+ млн процессов не превратившись в сущий ад, а главное, сколько железа может тянуть 10+млн процессов на CPU?

Быстрее родных работать могут, для I/O костылей требовать не обязательно (хватит только на I/O апгрейдить green thread до OS thread).

Если зеленые потоки не блокируются (например, ожидая i/o), то работать быстрее нативных они не могут, потому что, в отличие от нативных, часть своего слайса тратят на переключение между зелеными потоками, при этом дополнительного процессорного времени не получают. Т.е. нинужно.

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

Единственное вменяемое применение, которое тут предложили, это обертка для сокрытия асинхронного i/o от говнокодера. Но и это выглядит как сомнительный профит.

Если зеленые потоки не блокируются (например, ожидая i/o), то работать быстрее нативных они не могут, потому что, в отличие от нативных, часть своего слайса тратят на переключение между зелеными потоками, при этом дополнительного процессорного времени не получают. Т.е. нинужно.

Экспертность сего заявления зашкаливает.

Я сужу чисто по вакансиям, конференциям и так далее. По scala уже и консалтинг есть, и платформы с саппортом.

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

Блять, свифт уже влез в топ. Что не так с этой планеткой? Наверное, если бы Кук пропиарил лисп, через неделю эти бородатые в очках и клетчатых рубашках с макбуками носили бы футболки со скобочками.

Посмотрел на яндексе вакансии по Москве по C++ и scala. По C++ 220 вакансий, по scala - 3...

Экспертность сего заявления зашкаливает.

Ну так оспорь.

Ну на раст пытаются написать новый браузер https://github.com/mozilla/servo , насчет го не знаю.

а в эрланге уже можно строку записать так, чтобы не вырвало или кровь из глаз не потекла?

Сначала получу работу Rust евангелиста

Неужели ты веришь подобным данным? Они формируются на основе запросов в поисковых системах, не более. Глупо считать, что свифт ВНЕЗАПНО стал популярен, вот через годик-другой, когда (и если) на нем будет написано что-то стоящее можно будет посмотреть на его настоящу популярность.

это потому что вакансии со скалой разлетаются, как пирожки. а на крестовакансии, как правило, все еще собеседуют с вопросами по пункту стандарта 7.1.5.6.1.10.1000.а), подпункт iii (как правильно разыменовать указатель).

ilol'd

Экспертность сего заявления зашкаливает.

Ну так оспорь.

Смысла нет. Зеленые потоки делаются не ради скорости.

На hh.ru 556 и 39 соответственно. Не много, но и не мало, особенно учитывая, что большинство scala вакансий - клевые

Кто такие эти ваши «разработчики из Яндекса», чем знамениты?

> Быстрее родных работать могут, для I/O костылей требовать не обязательно (хватит только на I/O апгрейдить green thread до OS thread).

Если зеленые потоки не блокируются (например, ожидая i/o), то работать быстрее нативных они не могут, потому что, в отличие от нативных, часть своего слайса тратят на переключение между зелеными потоками, при этом дополнительного процессорного времени не получают. Т.е. нинужно.

Если состояния блокирования нет (100% CPU load), то идеальный случай производительности - это когда на каждом ядре процессора крутится ровно 1 OS thread, а в нем ровно 1 green thread. Идеальная загрузка CPU с минимальным временем переключения контекстов зеленых потоков.

В модели с OS-only threads караулить число активных OS threads надо делать вручную.

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

Апгрейдятся до IO thread только те green threads, что неизбежно блокируются/виснут на долгое время (а избежать сравнительно легко). Остальные продолжают наиболее эффективно жрать CPU/IO.

Единственное вменяемое применение, которое тут предложили, это обертка для сокрытия асинхронного i/o от говнокодера. Но и это выглядит как сомнительный профит.

Каноничным примером проблемы с мультиплексированием IO является пример из 'man select_tut' (второй пример, с сокетами): http://linux.die.net/man/2/select_tut.

Если переписать его на потоки (OS threads) ни красивее, ни быстрее не станет.

До сих пор сомнительный? :]

UPD: уточнил на какие потоки

И снова мы встречаемся в теме про Rust.

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

Про зеленые потоки: это дико удобно, программировать используя зеленые потоки. Даже в том же хаскеле. А теперь еще и в Го почти такие же потоки, горутины. Если они дают и 20% оверхеда, облегчая многопоточное программирование, в разы, это несомненно победа и очень нужная технология в современных реалиях.

сразу макбук виден на заставке к видео - можно и не смотреть.

почитал, о чем мы тут разговариваем.

Почитал. Говорить о ненужности гринов может только полный профан. cs никто не отменял.

Толстый зеленый фанбой Эрланга детектед.

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

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

А ты не знал, да?

Нет потребностей - Нет задач - Нет решений.

Сейчас пока эрланг вроде умеет 3 млн процессов. А насчет железа это дело наживное, ну может быть какой свитч, да и это легковесные процессы - внутри VM.

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

для разработки требовательных к ресурсам программ будет необходим именно Rust

А для нетребовательных - Си?

Стоит только попробовать и уже сложно забыть и отказаться

Звучит то ли как реклама, то ли как история болезни.

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

Он будет быстр, но не будет обладать возможностями Erlang VM по массовому запуску процессов.