Discord переходит с Go на Rust

We tried several go versions.

Но так только Erlang делает.

Ну и в Erlang не «классические» треды, поэтому там оно неплохо работает.

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

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

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

Ну, и локальность данных, конечно. В эрланге она by-design, как понимаю.

В голанге потоки тоже зеленее некуда. Как и в жабе. Локальность данных играет бОльшую роль кмк.

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

Сборка мусора там запускается на гринтредах (процессах), на не на «вполне себе обычных».

и глобальных шаренных данных между телами просто нет

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

Хотя наверно нельзя называть их глобальными.

Сборка мусора там запускается на гринтредах (процессах), на не на «вполне себе обычных».

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

Нет, просто share nothing архитектура. Нету объектов, на которые ссылаются напрямую две ссылки в двух потоках

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

лол, какая разница, если у них вместо UI браузер?

Нету объектов, на которые ссылаются напрямую две ссылки в двух потоках

В Erlang на самом деле есть, я уже писал выше про refc binaries. И они могут потенциально привести к утечке:

Having large binaries reference counted and not copied by send or garbage collection is a big win, but there is one problem with having a mixed environment of garbage collection and reference counting. In a pure reference counted implementation the reference count would be reduced as soon as a reference to the object dies, and when the reference count reaches zero the object is freed. In the ERTS mixed environment a reference to a reference counted object does not die until a garbage collection detects that the reference is dead.

This means that binaries, which has a tendency to be large or even huge, can hang around for a long time after all references to the binary are dead. Note that since binaries are allocated globally, all references from all processes need to be dead, that is all processes that has seen a binary need to do a GC.

Вот тут более подробно с примером.

лол, какая разница, если у них вместо UI браузер?

Склонным к теоретизированию просто стало интересно немного потеоретизировать) Как тест на сенсорика или интуита.

Сначала все хорошо, а потом через пару месяцев оказалось что теперь это происходит раз в секунду.

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

Штука в том, что там у каждого треда своя куча,

Чем тогда такой «тред» от форка отличается?

Ну вот, лучше не стало.

Предлагаешь всё писать на Си?

На gay++, как доктор DELIRIUM прописал.

всё писать на Си?

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

Чем тогда такой «тред» от форка отличается?

И вот поэтому в эрланге треды называются процессами. Разве что всё это происходит внутри виртуальной машины, и, с точки зрения ОС, куча у них всё таки одна, но объекты в «куче» одного процесса никак не ссылаются на «кучу» другого.

Сегодня у нас так, завтра эдак

В растишке с этим ещё хуже.

Полностью одобряю.

Вопрос в том, что надо не нестись как идиот переписывая все и вся. Я вообще понял, что сейчас везде зерг раш… Ааааа бегут конторы переписывая все то на рельсы, то на Го, то на Раст. Лепят вместо Постгреса noSQL и потом хранят все данные в АВС и вдруг раз роскомнадзор и компания сдохла. А другие продолжают бегать как идиоты который кусают красные муравьи.

Дебилам, похоже, просто нечем больше заняться.

Конченые.

Лорчую.

Но свой никому не нужный шакализатор, из-за которого не работает WebP они выкидывать не собираются, я так понял, да?

Так WebP не взлетел, проще его выкинуть.

Так WebP не взлетел

Почему же? Даже мозилловцы сдались и вкорячили его в лису. А набор популярности это лишь вопрос времени. Альтернатив-то нет.

У них вполне нативный UI. Под ios.

Да эту тормозную херню ничто не спасет.

а можно мне нативный UI под комплюхтер а не под мобилу?

Правильное решение. Только надо было на Haskell переходить.

глобальных шаренных данных между телами просто нет

Не совсем так, но я понял что вы имели ввиду. GC там своеобразный.
https://hamidreza-s.github.io/erlang garbage collection memory layout soft re...

Все до банальщины просто, у них были в команде люди которые до этого отлично форсили rust. Те кто писали на go воевать с gc видимо не захотели. Ребята решили не заворачиваться и не нырять в кишки, а все переписать.

Все правильно сделали. Вообще, Rust все еще сильно недооценен ИМХО.

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

А ты не думай - у тебя это хреново получается. Ты сходи по ссылке и почитай.

В жабе нет никаких гринтредов (по крайней мере пока)

Я всегда знал что жаба сосёт.

Судя по всему ты просто про неё вообще ничего не знал

Go2Rustы, блин!