Но что дальше-то делать?

понять и простить :)

Я считаю надо впилить в фобос нормальный RC

использовать там, где это не мешает

использовать там, где это не мешает

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

а чего именно не хватает?

RC-контейнеров

И обещаной поддержки RC на уровне компилятора для классов

александреска даже DIP сделал

а потом видим на форуме по сто страниц обсуждения какого-нибудь сранного элвис-оператора

А замыкания тоже RC делать?

Замыкания отдельная попоболь, но ее можно пережить

Как?

Если замыкания GC ловит, то все, весь твой RC перестает нормально работать

Отдельным типом-структурой

А почему RC перестает работать?

В конце концов я могу вместо традиционных делегатов использовать самописный функтор, а-ля лямбды в C++11

Ну то есть половину фобоса к свиньям, вместо удобных замыканий говно из С++

кроме того не все замыкания требуют GC

Ну то есть половину фобоса к свиньям, вместо удобных замыканий говно из С++

Зачем к свиньям?

Пусть остается для любителей правильных инструментов.

Если оставить, начнут смешивать GC и RC.

Будет жопа

Короче, чтоб RC нормально работал, надо весь язык с нуля переделывать

И получишь очердной С++

Кому надо пусть смешивает, кому не надо пусть сидять на GC

И получишь очердной С++

Еще раз, GC - это мягко говоря не самое большое отличие D от С++

Если конструктивно, можно запилить действительно библиотеку RC контейнеров в нынешнем языке. И в сочетании с @nogc ее использовать, кому надо.

Я об этом и говорю

А на уровне языка и классов RC вставлять - херня выйдет

На уровне языка была обещана поддержка RC для классов

там хороший DIP, который и нашим и вашим

Мне кажется, они ее не продумали до конца. Потому и не сделали

Начнут делать - скажут, опа.

Я думаю это просто сложная задача

Уолтер еще за безопасность топит все время

Без поддержки компилятора безопасный RC не сделаешь

А чтобы ее хорошо обеспечить, это надо Раст делать из языка

Ибо у нас же свободно указатели передаются

Ибо у нас же свободно указатели передаются

Поэтому и нужна поддержка компилятора для классов

А для не-классов?

слайсы те же

сейчас слайс это два слова. с RC надо это менять, делать их толще и тормознее

Ну тут ничего уже не сделаешь

сейчас слайс это два слова. с RC надо это менять, делать их толще и тормознее

Тормознутость RC - это такая же байка как и тормознутость GC

ну сейчас передача слайса почти бесплатна

а будет чуть более платна

Аж целая операция инкремента и только при копировании. Офигеть тормоза для современных процов.

а если еще про многопоточность вспомнить

тебе RC нужен однопоточный или безопасный?

И на каком уровне это должно решаться / управляться?

Для тех же классов

ну сейчас передача слайса почти бесплатна

Зато потом сборка мусора не бесплатна. Кроме того компилятор во многих случаях может выпиливать инкремент/декремент там где можно

а если еще про многопоточность вспомнить

Потокобезопасные RC редко нужны. Отдельный тип или при помощи shared. Вместо обычного инкреиента atomicOp!"+="

Передача голых нестатических указателей между потоками - зло

аллокация в одном потоке, деаллокация в другом - это говнокод, которого нужно избегать всеми силами

да. Но с GC таких вопросов даже не возникает. А с RC сразу большой простор для раздумий и ошибок.

Как ты выразилса "правда жизни" показывает, что еще как возникает.

во всяком случае безопасность легко обеспечивается

во всяком случае безопасность легко обеспечивается

текучий GC - это НЕ безопасно

тут Уолтер не согласится

тут Уолтер не согласится

Думаю, даже он согласится

он в отличие от тебя не считает это нормальным

А так D годится только для домашних поделок.

вечный хобби-язык

да просто не все в мире уеб-программисты

не всем нужны долгоиграющие сервисы

ERROR: S client not available

а для многих задач Ди и сейчас ок

он в отличие от тебя не считает это нормальным

Он с этим мирится уже 15 лет или сколько там.

Его понимание безопасности - это SafeD. Лишь бы проездов по памяти и обращений к освобожденной не было

да просто не все в мире уеб-программисты

да какой там в жопу уэб? У меня бакенд навороченный, а веб - маленькое окошко наружу.

А по-твоему теперь и для сервера онлайн игры D - "неправильный инструмент"

Если на вайбе - то да, скорее всего неправильный

Если на вайбе - то да, скорее всего неправильный

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

веб-сервис общается с бэкендом через RPC

Нет, вайб плохой как раз в том числе из-за плохого GC

а есть же RC в std.typecons - они плохие?

Если б не GC, то и вайб может и сгодился бы

Нет, вайб плохой как раз в том числе из-за плохого GC

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

Не D

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

А фреймворки, использующие GC

Пиши на сокетах, следи за памятью, будет щастье

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

а есть же RC в std.typecons - они плохие?

?

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

Соединить их с аллокаторами, и ок

?

Он не работает только с PODами, то бишь структурами и простыми типами

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

Где они есть?

И что мне теперь отказаться от встроенных массивов?

да

аллоцировать их аллокаторами

слайсы можно использовать

Да накой мне эти аллокаторы

чтоб не в общей GC куче жили

слайсы можно, но осторожно

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

ну уж не хуже С++ и итераторов

причем здесь итераторы?