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

будет ещё забавней если они вот нонешнюю версию_на_Rust перенесут на Golang - с дальнейшим значительным ростом производительности без заката.

это и есть признак исправления архитектуры

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

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

в своё время пытались «Dont be evil» - ибо идеология позволяет энтузиазм запрячь.

Go

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

)))))))))))))

Что же там прогрессивного? Старые идеи, новый язык, просто упрощенный.

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

Я уж не говорю про то чтобы подключить через cgo какую-нибудь уже существующую библиотеку с реализацией LRU кэша.

Но они мало того что наговнокодили, так еще и статью об этом написали. И камунити в восторге. Это же просто тушите свет.

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

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

В статье упомянута scylla, там чистый c++

За несколько лет не смогли.

После такого тратить миллионы на еще одну попытку с Го?

Лол.
Не верю.

Лучше через год переписывать все на новой скриптухе, а то так и работы не останется %)

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

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

C++ существует даовольно давно, а дискордов на нём так и не сдлали.

Skype же. (А первые версии вообще на Delphi были.)

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

иммутабельность

Там нет иммутабельности. Просто const по умолчанию.

утонченная система типов из какой-то адовой функциональщины

Примитивная по сравнению с тем же хаскелем и тем более идрисом.

Боянище же. А ваще как они там поживают? Показ WEBP с APNG впилили уже или все еще пытаются бабки доить, но уже новомодными стикерами?

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

Он с ним как-то очень ревностно трахался, тащил в код новые фичи… Я вот лямбды в C++ впервые увидел при попытке скомпилировать личкрафт не самым свежим на тот момент компилятором. Перенапрягся, видимо.

Было 20 способов инициализации, добавили uniform initialization syntax, стал 21 способ инициализации, но это всё ещё недостаточно uniform, поэтому в C++20 мы сделаем uniform из обычных круглых скобочек.

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

В целом да, я его понимаю, и примеры он приводит вполне разумные. Вот только человека, который 17 лет жизни посвятил Rust и может написать что-то подобное, в мире пока нет по очевидным причинам. А что до, например, Java — то там свои тараканы.

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

Это эталон, я считаю.

Отличный вброс! Поддерживаю! И заодно побольше денег на bug bounty запасти.

этот вовсе не обязательно! (с) Всегда Ваша команда Micro$oft Exchange.

У них там огромный сервак. Просто гигантский.

А как они, пардоньте, кластеризуются? Или у них все крутится на каком-то одиноком DL385 Gen10+ с двумя эпиками и терабайтом рамы? Так это не много, упрутся.

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

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

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

Если ты напишешь всё на С++, то запрос будет отрабатывать за 101 мс (100 мс на запрос в СУБД, 1 мс на всё остальное)

Воу, адекватный регистрант в треде

+1.

При этом если распилить сервер на микросервисы, то проблемы не будет

Разумеется не будет. Будет проблема с задержкой на сеть, и куда более жёсткая

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

Хуже, постоянно ломать совместимость и переписывать то, что работало.

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

Старые версии сервера были на С, клиент на С++/Qt.

1. Если в С++ юзать унсафе то будет такая же безопасная работа с памятью.
2. Если в Раст применять унсафе то скорость его идет в …
3. За Го стоит гугл а это опасно, и в один прекрасный момент …
4. Когда авторы сабжа перепишут клиент с Элeктрона ?

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

Проблема в современной экономике. В какой-то момент экономия стала сильно сказываться на качестве. Python, js, go, rust - это просто экономия на процессе разработки. Нужно делать быстро и очень много продуктов. Технически, это невозможно без потери качества, потому что процесс любой разработки это не только написание кода, а ещё много стадий тестирования, отладки на близких к боевым условиям, потом в боевых условиях в ограниченном тираже и тд и тп. Проходят годы, прежде чем какой-то код попадает в продакшин и не важно на чём он написан. Но современная экономика дооптимизировалась до того, что убрала из цикла разработки почти всё, что идёт после написания кода. А значит нужно писать так, чтобы сразу был результат. Раньше это называлось прототипами, и его делали на коленке с помощью удобных инструментов(а иногда просто рисовали на бумаге), а уже потом делался проект. Теперь же прототип и есть реальный проект и вместо бумаги используется js, go, rust или что угодно. Поэтому нужны жёсткие требования, чтобы этот прототип хоть как-то работал.

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

Вот пример, вышел процессор Эльбрус.

Во-первых, он нужен «почти лишь никому». Во-вторых, LLVM пилили/пилят и для эльбруса.

After investigating, we determined the spikes were due to core Go features: its memory model and garbage collector (GC).

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

а когда добавляют мантру

Rust is blazingly fast and memory-efficient: with no runtime or garbage collector

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

и самая мякотка в первом же комментарии к статье

Any reason you’re using 3-year-old Go 1.9.2 but you’re okay using Rust nightly?

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

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

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

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

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

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

Смотря какие и когда.

unique_ptr не должен стоить ничего. shared_ptr может стоить что-то при копировании, но не при доступе

Неправильно думаешь. Вернее, примитивно. Основных проблем две: жирные фреймворки и неаккуратность разраба.

Первое просто и понятно. Вот ты пишешь очередной блокнот на электроне. Тебе правда нужна поддержка xbox? Может вырубить вебсокет если ты даже не знаешь что это?

Второе сложнее. Например у нас есть чудо-сервис, считающий процент групповух от общего числа сношений в данный момент. Берём цикл по сношениям, считаем число участников, все просто. Тут приходят чекисты и говорят что педобиры плохо и их не надо считать. Ок. В метод подсчёта подсчёта ставим запрос в базу чтоб вычислить возраст участников. Норм? Нет, блин, не норм, этот метод в цикле вызывается. Но это на 5 уровней вниз по стеку и сходу не видно.

Реальный хаидкорный перфоманс нужен в 99% случаев числодробилкам и играм, на все остальное хватит даже перла, главное чтоб написано было грамотно

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

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

fixed во славу науки.

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

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

Ну дык этот топик о чём? Разработчики discord сменили Go на Rust. Discord это сайт такой, на котором общаются компьютерные игроки.

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

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

моральный вопрос – а должен ли?

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

PS несколько не значит в разы. Причём зачастую в итоге выйдет быстрей.

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

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

Мамкины вебельщики из поколения тиктокеров слышать не хотят ни о каком управлении памятью.

А вообще полностью поддерживаю: управление памятью в современном C++ не является какой-то особо сложной проблемой. Да, нужно применять мозг и следовать некоторым правилам/соглашениям, но для этого совершенно не нужно быть Александреску. Основная проблема C++ - чрезмерная перегруженность языка и разное поведение на разных платформах/архитектурах. Слишком много тонких нюансов, о которых постоянно нужно помнить. Написать код на плюсах без стрельбы по ногам в принципе довольно сложно.

Я конечно ламер тот ещё, но со стороны раст кажется концептуально сложнее C++. На последнем всё ещё можно писать дубовейший код в режиме си с классами. А на расте нельзя, там сразу по лбу бьёт иммутабельность и утонченная система типов из какой-то адовой функциональщины.

Это разве что для самого начального входа в язык. Тут соглашусь, планка входа для написания чего-то после хелло-ворлда в Rust выше. Но чуть позже оказывается, что у C++ ты ещё 90% возможностей не знаешь, а Rust вроде уже весь и выучил.

Поэтому как-то восторгов сишников от раста не очень много, самые жесткие хейтеры это как раз они.

Ну естественно, это как дельфи-разрабы плевались на C#. Просто в душе понимают, что они устарели, а признать это не хотят.

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

Тебе кажется. Rust уже давно взлетел. И вообще из последних языков он по-моему прямо таки образец популярности, возьми любой другой язык - он либо взлетал десятки лет, либо его с плёткой в руках пропихивала какая-нибудь корпорация. Rust это реальный феномен в современном IT. Его разве что с Java можно сравнить, она примерно так же взлетала в 90-х.

Не правильно. Из того что в одном языке больше ньюнсов чем в другом это не заслуга языка. Кол-во инструкций процессора конечно. … Жаль, что игнорят вопрос, что будет если гугл прикроет го.

Да примерно то же будет, что произошло, когда mozilla «прикрыла» Rust. Создадут Go Foundation, независимый от гугла и остальных компаний, туда перейдут все разработчики и компании, которые используют Go, будут туда донатить. Пока язык популярен, найдутся желающие его поддерживать.

Из того что в одном языке больше ньюнсов чем в другом это не заслуга языка.

Количество нюансов вытекает из количества возможностей и легаси. Возможностей в С++ куда больше.

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

у C++ ты ещё 90% возможностей не знаешь

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

а потом С++ срёт таким в шаровары и руки искривляет.

Мамкины вебельщики из поколения тиктокеров слышать не хотят ни о каком управлении памятью.

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

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

Ну а какие тонкие нюансы, чтобы выстрелить себе в ногу? То что нельзя оставлять конструктор копирования по умолчанию, если в членах класса есть указатели?

То есть нечто вроде такого:

class NoCopy {
   private: 
      int *s;

   public: 
      NoCopy() { s = new int(1); }
      ~NoCopy() { delete s; }

};

Тут как бы понятно, что если не переопределить конструктор копирования и оператор равно (=), то как бы будет не очень весело. Точнее наоборот, веселье обеспечено, смотря с какой стороны посмотреть :-). Поскольку если объект этого класса скопировать, то s внутри нового объекта будет указывать на тот же адрес, что и у старого объекта. Веселые ночи отладки обеспечены.

Но как вообще программировать не понимая что делаешь?

Не уверен что в случае Го такое прокатит. Они могут заявить на ТМ и прочее это все таки гугл.