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

М$ или гугл, вы думаете, что совету директоров не плевать на то, какое будет качество кода?

Ты Windows ME видел?

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

А вы хотите показать? Я видел Как минимум 30 тыс. организаций в США были взломаны через дыру в Microsoft Exchange Server.

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

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

Что касается С++. В среднем он будет быстрей любого другого языка кроме, разве что, С. Но быстрей ненамного. И не факт, что это ускорение вообще кому-то нужно. Простой пример - веб-сервер. Он принимает запрос, парсит его из текста в структурированные данные, потом делает запрос в СУБД. Ждёт 100 мс, принимает ответ от СУБД и отсылает его клиенту. Если ты напишешь всё на С++, то запрос будет отрабатывать за 101 мс (100 мс на запрос в СУБД, 1 мс на всё остальное). Если ты напишешь всё на Python, то запрос будет отрабатывать за 103 мс (если считать, что Python в 3 раза медленней). Если ты напишешь всё на Java, то запрос будет отрабатывать за 101.3 мс. Вот примерно такой порядок величин будет в реальном софте.

А тут оказывается Python в большинстве софта используется

Это неправда. Python используется много где, но всё, что действительно должно работать быстро, написано на C/C++ и тд. И производительность обвязки на Python тут вообще ни на что не влияет.

это поэтому всё становится таким тяжёлым и тормозным?

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

Это получается деградация, когда упрощение написания кода приводит к плохому качеству этого кода? И тот же низкий порог входа к написанию кода, приводит к ухудшению самого кода? Замкнутый круг, где прогресс завязан только на производительности процессора а не улучшению кода?

Нет. Упрощение написания кода приводит к удешевлению кода. Это и есть улучшение кода. А если ты улучшаешь производительность, которая никому не нужна, это ухудшение кода. У тебя есть определённое железо, на которое ты ориентируешься. Ты не ориентируешься на 8086 процессор с 512 KB оперативной памяти. На такой процессор можно ориентироваться, но тогда код будет плохой и функционал будет куцый. Куда лучше провести исследование рынка, выяснить, какое реально железо у большинства интересующих тебя людей и ориентироваться на это железо. Именно так и делают большинство компаний.

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

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

И что ты хочешь сказать этой ссылкой?

То, что дыры в хроме не от хороших программистов.

То, что дыры в хроме не от хороших программистов.

Ясен хер. Но есть ли программисты на C++ лучше и в нужных количествах?

это чушь кстате что питон проще чем c++ и что у питона порог входа ниже. всё ровно наоборот

На Хабре как-то промелькивало исследование, сколько процентов инструкций поддерживают современные компиляторы. Оказалось, около 30%.

Т.е. 30% от всего того, что может процессор.

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

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

Я убежден в том, что софт тяжелый и тормозной по причине косяков в архитектуре и разработке, а не из-за неправильного выбора ЯП. Надо очень сильно постараться, чтобы упереться в рамки ЯП. Вероятно, Python не очень для числодробилок, но для десктопа и как клей он весьма неплох. Не надо только 200 модулей на импорте использовать на каждый чих (тем более, что встречается и натуральный говнокод).

Исходя из теории вероятности, да

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

их даже больше чем специалистов по расту (возможно, пока).

Ты исходишь из предпосылки, что один человек может программировать или на C++, или на Rust, что совсем не так. Более того, имея знания C++, перейти на Rust достаточно просто. Ярых же фанатов C++, которые готовы его пердолировать до конца дней как какая-нибудь Iron_Bug, довольно мало. Поэтому Rust вполне может и вырулить.

Количество людей, сумевших нормально выучить C++, уже превысило количество страниц в его стандарте?

Это пять я щитаю, надо записать где-нибудь

Но есть ли программисты на C++ в нужных количествах?

НЕТУ! А жаль=( Я б нашел им занятие во имя ОпенСорца

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

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

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

Гугл набирает студентов. Это давно известно. Роб Пайк об этом высказался:

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software.

http://nomad.uk.net/articles/why-gos-design-is-a-disservice-to-intelligent-programmers.html

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

К сожалению С++ нормально выучить желают немногие.
Ну и выстрелить себе в память по любому проще чем на Rust

А вот покажи мне твои вычисления?

Всё очень просто. Открывание индекс tiobe, смотрите на то, что в этом искусственном индексе популярность плюсов выше на более чем порядок. Вероятность того, что изучение раста в 10 раз легче, чем с++ крайне мала, вы бы это указали где-то тут

Более того, имея знания C++, перейти на Rust достаточно просто.

Вывод я уже описал.

умные указатели

Потеря производительности. Тот-же GC, вид сбоку.

Вы только одну проблему описали изза которой они начали пробовать Rust.

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

На Хабре как-то промелькивало исследование, сколько процентов инструкций поддерживают современные компиляторы. Оказалось, около 30%.

Т.е. 30% от всего того, что может процессор.

Эта цифра ничего не говорит. В процессоре куча бесполезных инструкций, которые использовать просто ненужно ни в каком случае, т.к. они там нужны только для обратной совместимости с кодом 40-летней давности. Правильно писать «сколько процентов инструкций используют современные компиляторы». И сколько из неиспользуемых инструкций стоило бы использовать.

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

Правда, он не уточнил, от чего же зависит

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

От этого будет зависеть построенные процессы (если они есть), сила стандартов качества компании (и вообще их существование), количество ресурсов выделенных на code review, тестирование, обучение и т. п.

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

Да не. Микросервисы – это про другое. DDD и неограниченное масштабирование. А старпёрский подход, типа DDD и хорош – ужа даже школьники микросервисами не назывют. Типа доменная зона – это доменная зоня. А что ты там вручную поднял и рапределил – фигня полная. У тебя есть нагрузка X. Её вывозят N микросервисов. Если нагрузка меняется до Y, система автоматически поднимает или наоброт выключет M микросервисов. При этом она может учитывать и географию, если имеет смысл. И каждый сервис – это не резиновая фигня, а сущнсть с известной заранее верхней границей применимости. Собственно в этом и отличе детсадовского подхода к архитектуре, от професионального.

Парни до того раздули какждый «микросервис», что пришлось уменьшать LRU-кэш (кэш на Go, причём небось на standard map, п-ф). Фишка такого «сервиса» единственная – это LRU-кэш. Написанный на Го. Ну и стандартное наначение сервиса – прослойка между базой. Почему кэш написан на Го, а не вынесен в сторону – не понятно.

Логика ускорения работы GC в Go всё это время шла к увеличению частоты его вызовов, чтобы сократить GC-паузу. С самого Go1.5 это делалось. И давало прирост.

Как пошли ребята из Dsiscord?

We figured we could tune the garbage collector to happen more often in order to prevent large spikes, so we implemented an endpoint on the service to change the garbage collector GC Percent on the fly. Unfortunately, no matter how we configured the GC percent nothing changed. How could that be? It turns out, it was because we were not allocating memory quickly enough for it to force garbage collection to happen more often.

Ок, а как насчёт вручную вызывать runtime.GC() каждые сколько хочешь? Не знали, не пробовали, не написали почему?

Оба решения в своей «гениальности» иного итога, кроме как переписывать готовый и рабочий сервис на Rust, просто не могли дать. Прсто гораздо честнее было бы сказать, что они хотят освоить Rust, но нет предлога.

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

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

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

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

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

время человека стоит дороже времени компьютера

Нанимаешь индусов за миску риса

Получаешь тормозной говнокод

Объясняешь тормоза сказками про дороговизну разработчиков

Profit!

Никто нарочно не пишет говнокод. Он всегда на заказ.

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

А вообще одна из проблем в том, что даже само понятие качества кода очень субъективно. Не существует общепринятых отраслевых стандартов, по которым можно сказать, качественный код или нет. Вот строит тебе дом кто-то. Тут есть СНИПы, по которым можно определить, качественный дом или нет. Если СНИПы нарушаются, значит дом некачественный. Если СНИПы не нарушаются, значит есть большие шансы, что стройка ведётся качественно. А у программистов никаких СНИПов нет.

Отчего Go и Rust противопоставляют друг другу? Это же вообще разные языки, как паскаль и пхп, например.

У питона у самых распространённых библиотек (pandas, numpy, итд) даже нет автокомплита в intellij idea, я когда начал изучать питон слегка прифигел от этого.

И кто-то ещё смеет говорить что питон «лёгкий» для изучения, лол. Нет автокомплита! В 2021-м году

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

Вы только одну проблему описали изза которой они начали пробовать Rust.

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

Там единственная проблема – это LRU-кэш сделанный на Go. Который и является основной сутью сервиса. Вынесли бы его в Redis или Mecmcached и не было бы проблем. Или собственно LRU-кэш переписали бы на Rust или C с уборкой на строне.

А переписывание всего. Вместо того, чтобы увидеть корень проблемы – это и есть закат солнца вручную.

Собстенно я бы предложил так

[Go Read States] -> [Rust LRU cache] -> [Cassandra]

Как три отдельные сущности, разумеется.

И сервис бы остался на месте. И разрабы удовлетворили бы своё желание освоить Rust. И ничего бы не фризило.

разработки производительных интернет-сайтов

Сайт на расте о.О????!?

для разработки системного ПО

К сожалению, я перестал понимать, что сейчас считается системным ПО.

нет автокомплита в intellij idea

выброси это говно

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

Не знаю, как там pandas и numpy, ибо пишу на Python в качестве хобби, но обычный geany более-менее справляется.

питон «лёгкий» для изучения, лол. Нет автокомплита!

Пфф. Когда я начинал, я вообще писал года два-три в nano. Там синтаксис подсвечивается, кстати. Одно дело - реально начинающие в программировании, им автокомплит и не нужен, другое дело - когда с другого ЯП переползаешь.

Сайт на расте о.О????!?

Что ты хочешь? В раст ломанулись хипстерки, которые раньше эти сайтики делали на руби.

Да, я согласен во многом.

Но если есть бизнс-поделка и её бюджет и сроки очень ограничены, то выбор скорее упадёт на Питон, нежели на C++. Быстро стартануть, а потом, в случае если выстрелит, уже заниматсья серьёзно (ну или «серьёзно»). Это как строить новый дом. Есть участок, но сортира там нет. И ты строишь на скорую руку из досок и говздей что-то более менее сносное. Но не финальное. Не чистовое. На время.

А дальше больше. Нужна фича Икс. Но бюджет и сроки ограниченны. И поделка есть только та самая – стартовая. В неё вкорячивается фича Икс. Вместе с ней говнокодистость увеличивается. Через несколько фич проект уже 100% говнокод высочайшей сложности.

И в данном случае программист может только за счёт сбея как-то более менее чисто это делать. Сроки исзвестны. Бюджет тоже. Знаит только за счёт себя. И тут уже моральный вопрос – а должен ли?

вы думаете, что совету директоров не плевать на то, какое будет качество кода?
Ты Windows ME видел?

Какое у вас осталось от него впечатление, кстати?

И пальцы под емакс подкрутите немного, пожалуйста.

К сожалению, я перестал понимать, что сейчас считается системным ПО.

В обещм-то ПО делится на прикладное – для пользователя. Как тот email-клиент. И системное. Как например автоматичские обновления пакетов раз в 100 лет. К чему там относить серверные приложения, я не знаю. Наверное всё-таки системные. Или третий вариант.

С пальцами всё нормально. Нужна только третья рука.

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

В этой цепочке вы забыли JavaScript и язык макросов Access

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

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

Вы бы все же прочитали статью

ROFL. множественный ROFL

https://www.stroustrup.com/

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

в идеале суперкомпиляция

в С++ обычно (насколько помню) всё пытаются как можно раньше «вычислить» - но ровно в этом и есть ловушка неравновероятных ветвлений.

в коде который будет наиболее рано и наиболее с большим числом оптимизаций нацелен - проверка условия которая обязана быть ибо в момент компиляции этого условия результат заведомо n/a

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

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

(в том числе)поэтому и мэнеджет-среды интересны

некоторые думают что зависит обратной зависимостью?

тут есть ещё прелестный эффект -

реально хороший код в терминах «высококлассных программистов» и его поддержка -

оказывается плохим кодом в терминах «дивёрсити программистов» и его поддержки

т.е качества кода есть функция не только самого текста но и тех кто будет его сопровождать/улучшать/евалютить

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

чё далеко ходить уже старая во времена возрождения тема длинных коротких титулов