Открыта регистрация на DConf 2014

Использование D в реальном мире

Из Facebook кто-нибудь будет выступать?

//Кстати, недавно узнал, что на D написан один из лучших горизонтальных скролл-шутеров всех времён и народов — Tumiki Fighters.

gnome-base/dconf
Available versions: 0.12.1 0.16.1 {+X doc test}
Installed versions: 0.16.1(22:30:00 19.12.2013)(-X -test)
Homepage: https://wiki.gnome.org/dconf
Description: Simple low-level configuration system

Они ни с чем названием не конфликтуют?

не web-сервере Vibed
Проверено: Shaman007

Теперь на главной будут новости про всякие конференции каждого нового языка?

нового языка

Какое отношение D имеет к новым языкам?

Теперь на главной будут новости про всякие конференции каждого нового языка?

Нет, теперь на главной будут только про Биткоин и политику писать. Это сейчас более актуально.

D не такой уж новый язык.

Menlo Park, CA

Расходимся, поцоны.

Стабильная версия компилятора 1.0 вышла 2 января 2007

Довольно новый язык.

Walter Bright decided to start working on a new language in 1999. D was first released in December 2001

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

Автор новости вообще в порядке? Регистрация была открыта в начале декабря. Через несколько дней она _закрывается_ и можно ожидать оглашения списка выступающих. Пока что ни список тем, ни формат мероприятия точно не известен.

Для желающих просто посмотреть билеты тоже продаются с декабря.

Официальная ссылка на материалы по DConf 2013: http://dconf.org/2013/schedule/index.html , в новости ссылаются на личный сайт доброго человека.

Из Facebook кто-нибудь будет выступать?

Александреску точно будет выступать, а вот будет ли это связано с Facebook - неизвестно. В прошлом году один был: http://dconf.org/2013/talks/gertzfield.html («Ben Gertzfield is a mobile engineer at Facebook»)

Kстати, недавно узнал, что на D написан один из лучших горизонтальных скролл-шутеров всех времён и народов — Tumiki Fighters.

Не только игра написана на этом языке

Sociomantic Labs is a global leader in real-time bidding for online display advertising. Our codebase is not only written entirely in D, but also makes extensive use of generic programming, even in application-level code.

Круто у них там, я рад за них.

Пока там есть такие баги, ни о какой стабильности и речи быть не может.

Это не вполне баг. Компилятор никогда не освобождает память by design.

An important thing to realize about this bug is that it is *not* the primary
cause of slow performance and high memory consumption in CTFE.
Fixing this bug would make very little difference, except in cases involving
concatenation.

I think it's had a lot of votes because people think it's the key CTFE
performance issue, but actually the bad guy is bug 6498. Which is easier to
fix.

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

Это не вполне баг. Компилятор никогда не освобождает память by design.

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

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

Утечки памяти - это уже «дефект оптимизации»?

Да и прямо уж такие «не имеющей аналогов»?

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

Не освобождать память в короткоживущих программах - распространённая оптимизация. Ибо всё равно скоро умрёт и вся память вернётся в систему. И ускоряет это компилятор очень сильно, тут Walter всё правильно сделал.

Проблема началась в тот момент, когда концепция компилятора как короткоживущей программы начала на соответствовать реальным требованиям. Правильное решение ИМХО - превратить компилятор в демона с вытесняющими пулами памяти, но это довольно трудоёмкая задача (хотя движения в эту сторону есть).

Утечки памяти - это уже «дефект оптимизации»?

Да, т.к. для компиляции как таковой это не создавало проблем. Беда возникла из-за того, что CTFE сделан по принципу copy-on-write, что плохо сочетается с идеей «пиши CTFE как обычные функции». Как верно заметил Don Clugston в комментариях к репорту, изменение реализации CTFE на более «экономную» решит эту проблему.

Да и прямо уж такие «не имеющей аналогов»?

Ну в LISP, конечно, есть и не такое :) Но LISP не спроектирован как нативный C-подобный язык, поэтому сравнение не вполне уместно. Интерпретация произвольных функций на этапе компиляции в D - вполне себе know-how.

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

Дык, я с тем и спорю, что это вполне ожидаемо. У GCC при компиляции (С++) потребление памяти достигает больших значений и без CTFE.

Не совсем про компиляцию - но у фаерфокса тоже проблема была.

Другое дело, что я не утверждаю, что этот баг делает D «неприменимым в реальных проектах».

Ну в LISP, конечно, есть и не такое :) Но LISP не спроектирован как нативный C-подобный язык,

Ну новых нативных языков не особо много... Если же именно «С-подбность» брать, то в Немерле, вроде как, мощные макросы. В Скале, если ничего не путаю, тоже макросы добавили, думаю они тоже многое позволяют.

Так речь же не про макросы. Особенность CTFE в том, что во время компиляции интерпретируется _та же самая_ функция, что окажется в объектном файле, а никак не специальный шаблон/макрос.

Это позволяет, например, при кодогенерации использовать обычные функции стандартной библиотеки для работы со строками. Понятно, что для языков, где нет строгого разделения на время компиляции и время исполнения, это не имеет смысла, поэтом и сравнивать особо не с кем :)

Ближайший аналог это constexpr в новом C++, но возможности не сравнимы.

Особенность CTFE в том, что во время компиляции интерпретируется _та же самая_ функция, что окажется в объектном файле, а никак не специальный шаблон/макрос.

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

Ближайший аналог это constexpr в новом C++, но возможности не сравнимы.

Это да, потому и не приводил в пример.

Да с языком всё давно понятно - круто, практично, си-подобно и т.п. Библиотеки - вот за что бы взяться дижиталмарсу! Пока они слеплены энтузазистами в свободное от семьи время, они не выйдут в продакшн. Даже ГУЙня, представленная в Ди целым десятком библиотек, представляет собой «душераздирающее зрелище» из врапперов, тошнотворных сборников кнопок и маразматических поделий разной степени заброшенности. А библиотеки, в полный рост опирающейся на шикарные возможности Ди - нет. С СУБД тоже тухловато - была одна либа, которую всё грозились переписать, да так грозились, что самим стало страшно и проект заглох. С сетью всё вроде бы более-менее, но увы - на уровне допотопных сокетов и чтений в 10-байтовый буфер - шёл 21 век...
Уолтер не может этого не понимать, но, видимо, невелики ресурсы - и это омрачняет будущее такого великолепного языка.