LINUX.ORG.RU

Почему Discord сменил Go на Rust. Блог разработчика.

 , ,


3

5

В статье автор описывает успешный проект Discord, в котором Rust используется для потоковой обработки в Go Live и их Elixir NIFs’ сервере.

Автор пишет
«Хочу отметить, что мы потратили очень мало усилий на оптимизацию реализации на Rust. Но даже только с базовой оптимизацией Rust оказался быстрее супероптимизированной реализации на Go. Это заметный плюс для Rust, показывающий, насколько легко писать эффективные программы, используя Rust, по сравнению с глубоким погружением в Go.»

>>> Why Discord is switching from Go to Rust

★★★☆

Проверено: Shaman007 ()

Ответ на: комментарий от anonymizer

А потом придёт кто-нить из модераторов и снесёт 19.

ya-betmen ★★★★★ ()

Rust оказался быстрее супер оптимизированной реализации на Go

Надо было на руби делать первую реализацию. Так было бы ещё суперее.

bread ()

Никогда не писал на Rust, но сомневаюсь, что он может быть хуже go в плане синтаксиса и удобства.

GblGbl ★★★★★ ()

Мне кажется, баловство это, все эти Rust’ы, Go и прочее. Лучше один раз нормально выучить С++ и писать на нем. А это все уходящее и проходящее.

Вот пример, вышел процессор Эльбрус. Go для него еще нет. Ну и зачем баловаться? Круче С++ еще ничего не придумали. Остальное все чисто чтоб С++ не учить.

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

Лисп - это же интерпретатор? Или я ошибаюсь?

Если да, то как можно сравнивать компилятор с интерпретатором?

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

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

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

Ruby никогда не обещал быструю работу (причём работает на удивление быстро). Go обещает быструю работу.

Границ применимости это не отменяет.

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

Ну надо учесть, что все эта пресловутая защита от багов имеет ценой производительность.

Надо. Но в случае с управлением памятью 90% багов можно убрать без потерь производительности в рантайме, как показал пример Rust.

При том, что баги в любом развивающемся проекте есть, это нормально.

Чувак, в каком-нибудь Google Chrome болье 70% дыр – это кто-то наговнокодил с выделением или освобождением памяти. И не говори мне, что у гугла нет денег на нормальных C++ программистов. Потому что если у гугла их нет, у кого они вообще тогда блин есть?

Кстати, покажи нам свой код на C++ ради интереса.

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

да кому он сдался то твой элбрус. на c++ кроме helloworld что ещё писал?

wtj12 ()
Ответ на: комментарий от hibou

Мне кажется, баловство это, все эти Rust’ы, Go и прочее. Лучше один раз нормально выучить С++ и писать на нем. А это все уходящее и проходящее.

C++ существует даовольно давно, а дискордов на нём так и не сдлали. Видать что-то не то, с этой поделкой. К бабке не ходи.

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

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

hibou ★★★★★ ()

Если кто не читал это год назад. То расскажу в трёх словах. У них там огромный сервак. Просто гигантский. И кол-во объектов такое выделяется, что stop the world GC у Go просто очень долго их обходит во всемя GС-паузы. До секунды вроде. Около того. Как-то так.

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

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

Мне кажется, баловство это, все эти Rust’ы, Go и прочее.

Это называется прогресс.

Лучше один раз нормально выучить С++ и писать на нем.

Постоянно жить в 1983.

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

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

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

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

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

Вообще не понимаю, какая сейчас проблема с управлением памятью.

Сходи и посмотри на пресловутый Google Chrome. Это по сути образцовый проект на С++: использует современные практики; разработчики - крайне высокооплачиваемые специалисты, которых можно считать элитой среди С++; не боятся выкидывать и переписывать код. Открой CVE и разберись вплоть до строчки, откуда ошибка. И так по куче багов. В идеале не только по CVE, но там особо показательно. Мне это не настолько интересно, но выжимку я бы прочитал. Может и ты новое узнаешь, как в хорошем на вид C++ коде скрываются баги. А может свою точку зрения докажешь.

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

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

Либо какой-то самопальный код, где ручками что-то делаешь. Такой код если и пишешь, то надо 10 раз подумать, нужно ли это делать или нет. Нет ли под твою задачу уже написанной безопасной функции?

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

Если кто не читал это год назад.

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

Кажется, если кто и не читал, то это ты, потому что они там примерно в первом абзаце пишут, что речь идёт о микросервисе Read States, горизонтально размасштабированном на очень много тысяч инстансов.

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

Не, ну Эльбрус не показатель, под него никогда ничего не будет, если они тулчейн не откроют…

Идея руста прикольная, я всё хочу хоть немножко попробовать, но от безопасной многопоточности мне лично ни холодно, ни жарко - всё равно оптимальнее всего писать однопоточный код на эвентлупе…

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

Ну вот как раз у руста идея в том, что это защита от багов БЕЗ трейдоффа по производительности :-)

vitalif ★★★★★ ()

Я конечно не программист, но интересно. Я всегда думал что код на С++ написанный прямыми руками всегда быстрее всего кроме асемблера. А тут оказывается Python в большинстве софта используется, это поэтому всё становится таким тяжёлым и тормозным? Это получается деградация, когда упрощение написания кода приводит к плохому качеству этого кода? И тот же низкий порог входа к написанию кода, приводит к ухудшению самого кода? Замкнутый круг, где прогресс завязан только на производительности процессора а не улучшению кода?

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

Не знаю, возможно просто все слишком тупые для божественного C++

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

bread ()
Ответ на: комментарий от unixnik

Я всегда думал что код на С++ написанный прямыми руками всегда быстрее всего кроме асемблера

Так-то между ними ещё Си.

А тут оказывается Python в большинстве софта используется, это поэтому всё становится таким тяжёлым и тормозным?

В каком таком большинстве? И нет, не поэтому, дело в криворукости.

fernandos ()
Ответ на: комментарий от hibou

А это всё не важно. Важен конечный результат. И он при всём вот этом вот выходит не слишком радужным.

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

https://habr.com/ru/post/497114/

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

Пускай не мучаются и пишут сразу на Питоне.

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

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

Так и запишем: C++ создан для гидроцефалов.

hateyoufeel ★★★★★ ()

Уже были подобные кулстори, когда в итоге оказывалось, что всё дело в прямоте рук разработчика, https://habr.com/ru/post/350018/

В итоге даже правильно написанный код на js оказывается быстрее оптимизированного кода написанного на rust

mimico ()

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

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

В каком таком большинстве?

Да, неправильно выразился, используется в большом количестве прикладного софта. Под Python я имею ввиду любой интерпретируемый язык. Он же априори будет медленнее не интерпретируемого языка.

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

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

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

Я не очень хорошо знаю Python, но вроде он не совсем интерпретатор. Кажется, там есть какие-то задатки байткода.

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

Он же априори будет медленнее не интерпретируемого языка.

Ну, джаваскрипт (в8) достаточно быстрый, чтобы не сильно ощутить разницу, но тут уже вступают в игру криворукие программисты.

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

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

И не говори мне, что у гугла нет денег на нормальных C++ программистов.

Вы правда думаете, что от количества денег зависит количество нормальных программистов, ну, и качество кода??

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

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

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

Первый проприетарный язык с аудиочатами на уровне интерпретатора?

fernandos ()
Ответ на: комментарий от unixnik

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

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

Может у вас и так. Вот возьмём крупные корпорации, М$ или гугл, вы думаете, что совету директоров не плевать на то, какое будет качество кода? Они, может, и наняли нормальных, хороших программистов, да вот они в меньшинстве.

fernandos ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)