да, привет

я уже имею хороший опыт написания nogc кода вперемежку с GC - это жопа

полностью отказаться от GC - тоже жопа

половина фобоса отваливается

Те же самые умные указатели у нас есть же

А где у нас есть умные указатели?

RefCounted? которые умеют только структуры и не умеют классы и массивы?

для начала они, дальше надо дописывать

сложно что-ли смартптр запилить?

конструктор, деструктор, шаблоны - все в наличии

Не D

А какже вот это? - Невозможность писать долгоживущие нагруженные сервисы - это свойство D? - да

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

поэтому я стараюсь и так всё делать через структуры

а сравнивал перфоманс?

конструктор, деструктор, шаблоны - все в наличии

К сожалению например для массивов, да, сложно. И багнутые деструкторы сильно мешают. Помню я там на форуме дланга кирпичи откладывал на эту тему :)

А какже вот это? - Невозможность писать долгоживущие нагруженные сервисы - это свойство D? - да

Это был упрощенный ответ. :)

Это был упрощенный ответ. :)

Точнее, неверный.

std.container.array - RC массив, давно присутствует

а сравнивал перфоманс?

на форуме была ветка большая об этом

со сравнениями

std.container.array - RC массив, давно присутствует

Там даже не пахнет RC, ты о чем?

А чем же еще там пахнет?

чем угодно но там нет никакого RC

http://dpldocs.info/experimental-docs/source/std.container.array.d.html#L414

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

хорошо согласен таки пахнет, но недостаточно. Например слайсы не являются полноценными массивами

они и не должны, их можно считать borrowed view

Ну вообще-то я имел ввиду максимально полноценную замену встроенным массивам

можно ли два слайса склеить в массив?

Я написал свой такой RC массив и для строк в частности

Но там все равно есть свои проблемы связанные с багами и с const/immutable

а где с этим лучше? либо GC, либо такая вот боль и унижение

D тоже не идеален, совсем.

Потому использовать можно, но осторожно и с умом.

Это вот не компилируется: https://glot.io/snippets/ex3qzout64

Даже банальный nogc JSON приходится пилить с уродскими небезопасными кастами

а где с этим лучше? либо GC, либо такая вот боль и унижение

RC

например Nim

В ниме GC

ЕМНИП он сделан как раз на базе RC

ведь RC, внезапно, тоже GC ?

Как и в PHP, Python и других

там везде RC+GC

В ниме не RC + GC, там GC == RC

Также как и в ObjectC

Это просто деталь реализации - во всех этих языках внутри RC + GC

Ты так пишешь, как будто там GC - отдельно, а RC одельно :)

Да, отдельный сборщик для циклов у них везде

Детектор циклов, а в ObjectC его вроде нет, там сам где надо weak ставишь

ага

Так вот, если доделать тот DIP александрески для поддержки RC для классов, то работа с таким RC будет мало отличаться от работы с обычным GC

течь только перестанет и тормозить

слайсы-то как будут?

Для слайсов дипов нет.

Но я же сделал RC-массив - полноценная замена встроенным\

слайсы имеют тот же тип, что и сам массив

тормоза RC - это сказки, которые Уолтер всем рассказывает

Ну и получится Ним. :)

Не получится Ним. Ним - это питонообразный язык

без шаблонов

Я про рантайм

Шаблоны и метапрограмминг там же есть

синтаксис просто другой будет

Метапрограмминг есть, шаблонов нет, скорее дженерики

там макросы есть, да

и что плохого если рантайм D ,будет аналогичен рантайму Nim?

тут что стоит задача обязательно отличаться от других? :)

есть опасность потерять тесную совместимость с Си, и свойство fast-as-C

ERROR: S client not available

когда у тебя везде RC, начинается FFI

есть опасность потерять тесную совместимость с Си, и свойство fast-as-C

Не более чем сейчас.

Не хочешь не используй RC, будет тебе fast-as-C

Совместимость с Си есть и у Nim

Можно подумать что GC - это fast-as-C ?

не, только промежутки :)

в Пони забавно сделали - пока твой метод работает, никакого GC. А как актор закончил на текущее сообщение реагировать, тут-то сбощик и подчищает быстренько.

Так вот, если доделать тот DIP александрески для поддержки RC для классов, то работа с таким RC будет мало отличаться от работы с обычным GC

А с циклами как быть, кстати?

Циклы сами по себе тоже редкий гость. Только слабые ссылки

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

По-хорошему, при поддержке компилятора сделать precise GC, который бы не тек, вполне можно (разве что с union'ами будет нужно что-то поделать). Он будет все еще медленный, но течь не будет. Просто никто для Ди его не сделал, и такими темпами в обозримом будущем не сделает.

Rainer в VisualD уже использует almost-precise GC, и можно пойти еще дальше

Ага, скорость меня не так сильно волнует.

А как же высоконагруженность и все такое?

Масштабируем как надо, реюзаем уже саллоцированное и так далее

ведь пока я не аллоцирую/деаллоцирую GC не работает

Имхо, для подобных сервисов языки со Stop the World вообще плохо подходят. Поэтому тот же эликсир больше подходит.

Да-да, как раз хотел сказать, что надо еще и отдельный GC на каждый поток

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

поломается совместимость

thread-local GC потребует переделки языка, да

Имхо, для подобных сервисов языки со Stop the World вообще плохо подходят. Поэтому тот же эликсир больше подходит.

Да, я тоже так решил, что тут эрланг с его легкими процессами именно то что мне нужно

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

Пони может быть то что надо, но сыротааа

да

Ним, если б не сырость, мог подойти

В ниме пока нет аналога файберов/корутин/горутин

есть Crystal

но там есть какие-то серьезные врожденные проблемы, да и GC такой же как в D

я кстати вайбд использую не столько для веба, сколько как шедулер для файберов и IO

альтернатив-то готовых нет

Я недавно Kotlin Native запускал, он под виндой прямо удивительно легко раз и завелся. Но он пока в зародышевом состоянии.