А что GC тормозной - ну да, это fact of life, надо научиться это осознавать и иметь в виду, когда решаешь, стоит ли в конкретном проекте использовать D. И если решил использовать, то аккуратно подходить к тому, что держать в GC куче, а что выделять вне ее.

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

GC - это мягко говоря не самое главное в D. Особенно если учесть, что он иммитируется ARC.

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

Большинство плюсовиков отпугивает GC

Слабая инфраструктура тоже отпугивает

Мне нравится GC, но в том виде в котором он есть сейчас, все плохо

GC может и не главное, но это то, что делает язык удобным и продуктивным. Об этом еще Спольски писал в 13 веке: главный скачок в продуктивности при переходе со старинных языков на более современные вызван как раз наличием автоматического управления памятью, свободой не думать об этом.

в 13 веке? :)

утрирую :) давно, в общем

Кто такой Спольски, и почему я должен считать его авторитетом?

это известный авторитет :)

Для кого известный? И ты готов принимать на веру слова какого-то хрена, потому что он просто авторитет?

Ну-ну

Нет, конечно. Просто я давно в интернете.

https://www.joelonsoftware.com

Опять же GC удобная штука. Но я от него страдаю. Я устал бороться с течами в своем приложении.

там втыкай ручное управление, сям втыкай, в итоге только строки и остаются. Накой нужен такой GC?

Ну вот у меня есть GUI приложение, работающее с гигабитами видео. Память под видео и картинки легко вручную выделить, а все что касается работы GUI (dlangui) - отлично управляется GC. Щастье, простота и никаких проблем.

Вот переписываю свой сервис на elixir/erlang и с удовольствием не думаю об управлении памятью.

Аналогично есть прога для работы с фотками.

Картинки вручную, все остальное - GC.

Ну вот у меня есть GUI приложение, работающее с гигабитами видео. Память под видео и картинки легко вручную выделить, а все что касается работы GUI (dlangui) - отлично управляется GC. Щастье, простота и никаких проблем.

Это все не long running задачи

Но проблемо

попробуй написать нагруженный вебсервис, да чтобы еще аптайм был хотя бы месяц

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

Сервисы с аптаймом по полгода у меня на vibe.d есть.

нагруженные?

нет

см выше

нагруженные на вайбе я б не стал делать

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

Какая-то корявая отговорка

правда жизни

надо понимать свойства инструментов

Это не правда жизни, это ошибка жизни

надо понимать свойства инструментов

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

да

по крайней мере с текущим GC

текущим в обоих смыслах :)

да

Где это написано? Ты бы и сам не знал об этом, если бы кто-то не попробовал? lol

я с D уже 5 лет, его GC изнутри представляю

И когда же ты вдруг понял, что для долгоживущих сервисов он не годится?

Глупости все это, скажу я тебе. D позиционировался как замена плюсам

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

Я в свое время делал такие хуки для ГЦ https://bitbucket.org/infognition/dstuff/

Я видел исходники вайбда. Даже не просто видел, а пулл-реквесты для него делаю периодически.

и писал такие посты http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html

исходники ГЦ тоже делал

но таки начал писать нагруженный сервис

все ошибаются :)

"мы работаем со строками, строками срем в кучу, наш ГЦ течет и тормозит, что может пойти не так?" "давайте писать нагруженный сервис"

Отличие между мной и тобой в том. Что ты решил что корявый GC - это такое нормальное свойство. Ну типа инструмент такой. А я вот считаю это багом.

без коренного изменения языка это реальность, данная нам в ощущениях

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

вон в свифте запилили ARC. результат? дикие тормоза

без коренного изменения языка это реальность, данная нам в ощущениях

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

вон в свифте запилили ARC. результат? дикие тормоза

в ObkectC тоже запилили ARC и все прекрасно

вот только в команде Ди некому даже как в свифте сделать

можно конечно сидеть и ждать чуда

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

можно конечно сидеть и ждать чуда

Ну я не жду. Переписываю сервис на erlang/elixir, там хоть не течет GC

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

ну вот, взял другой автомобиль :)

собственно может проблема конкретно в вайбе?

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

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

От сложности зависит. У меня достаточно сложный сервис, там дофига взаимодействи со сторонними сервисами. и Множество параллельных процессов. Тысячи файберов.

собственно может проблема конкретно в вайбе?

Возможно и так. Тем более, что там были утечки, некоторые из которых я же сам баг-репортил.

Доподлинно известно, что встроенные ассоциативные массивы тоже текут

ERROR: S client not available

Тут в чате есть человек, который заменил встроенный ассоциативный массив на RedBlackTree из фобосо и оно перестало течь. Вау! Ты ниправильный инструмент выбрал! Надо было в исходники ГЦ сматреть!

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

Я когда-то делал себе хэштаблицы, не опирающиеся на GC. https://bitbucket.org/infognition/robinhood

Да и я сделал, только не хеш-таблицы, а AVL-дерево, полностью nogc, чисто на RC.

Но я не хочу подобным говном заниматься

Делай короткоживущие программы, там все ок.

Просто, удобно, безпроблемно

Хочется делать сервисы на нативном коде и нормальном GC - Nim, Pony, Haskell ждут вас. Каждый со своим набором особенностей/сложностей.

Что интересно, Уолтер с Андреем вроде начинали думать в сторону ARC год-два назад, но я не видел, чтоб из этого что-то в итоге получилось.

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

Хочется делать сервисы на нативном коде и нормальном GC - Nim, Pony, Haskell ждут вас. Каждый со своим набором особенностей/сложностей.

Nim - сырой, Pony - не знаю даже что это такое. Haskell - рафинированное ФП. Мне нравится D, я хочу писать на D.

Я бы написал "в таких сервисах не надейтесь на GC. Пишите, но за памятью следите сами".

Там уже это и написано по сути - что сборщик частично консервативный

имеющий уши да услышит

Я бы написал "в таких сервисах не надейтесь на GC. Пишите, но за памятью следите сами".

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

ну вот experimental.allocators выкатили, надо осваивать

EMSI на них контейнеры понаделали

я правда пока сам не пробовал

EMSI я пробовал. RC там нет

Pony - это как Erlang скрестили с Rust по хардкору

контейнеры все с отключенным this(this)

Там можно тыщи акторов, и никакого stop the world

Там можно тыщи акторов, и никакого stop the world

А ну я и так тыщи акторов с elixir

elixir на ВМ, а пони нативный

но он еще сырее нима

Не, мне тут на D тоже обещали тысячи файберов

а потом - неправильный инструмент, а-ха-ха

мне нативность особо не нужна

мне сам язык нравится

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

а потом - неправильный инструмент, а-ха-ха

Ну просто большая часть библиотек и проектов на D пишется в расчете на идеальный GC. А он внезапно не идеальный.

vibe.d сливает phoenix не смотря на нативность первого