За последние месяцы я несколько подзадолбался как с разработкой на C++, так и с общением с придерживающимися разных взглядов C++никами, так и c продвижением наших C++ных разработок в сильно сегментированном C++ сообществе. Настолько, что стал уже мечтать о том, чтобы закрыть ближайшие "долги" по работам вокруг SObjectizer-а и устроить себе отдых от C++. Пропрограммировать что-то для души на чем-то более современном и удобном, чем C++.
На D.
А вот сегодня на HackerNews увидел ссылку на статью Вальтера Брайта (это автор D и его основной разработчик) про возможность добавления в D механизмов Ownership и Borrowing из Rust-а. Смысл статьи в том, что изначально Брайт думал, что borrow checker из Rust в D не запихнуть, но потом у него появились идеи, которые Брайту кажутся вполне себе реализуемыми. Поэтому Брайт начинает активно копать в этом направлении.
Ну что тут сказать. Один раз Брайт и Ко уже основательно поднасрали своему детищу. Это кода в 2008-го году, всего через полгода после официального релиза D 1.000 было заявлено, что начинаются работы над D2, который будет несовместим с D1. Сказано это было в тот момент, когда вокруг D не было никакой существенной экосистемы и количество нормальных библиотек для D измерялось, в лучшем случае, несколькими десятками.
Да, D2 получился гораздо более интересным и мощным языком, чем D1. Но лет через шесть после D 1.000. И, по факту, он появился уже тогда, когда окно возможностей для D захлопнулось благодаря C++11/14, Go, хайпу вокруг Rust-а. Так что D отличный язык для небольших проектов маленьких команд и энтузиастов. Но широкого применения ему, увы, уже не светит.
А тут в D хотят впихнуть еще одну мегафичу. И мне непонятно нахрена это нужно делать :(
Ну вот основная фишка в том, что это продвинутый язык с GC для нейтива. И как раз GC дает D те преимущества, о которых C++никам остается только мечтать, если на C++ пытаться разрабатывать что-то более-менее высокоуровневое.
Казалось бы: ну и развивайте D как язык с GC. У вас и в этой области работы будет выше крыши. Зачем вы еще куда-то лезете? Делаете GC отключаемым, придумываете какой-то betterC... Теперь вот еще и borrow checker в язык затаскиваете...
Ну вот явно "чувство меры" -- это не то, что свойственно разработчикам D.
Пичалька, что еще скажешь. Вот так и разрушаются мечты :(
Думаю Go 2 более реальный чем D с borrow checker :)
ОтветитьУдалитьНу как бы история показывает, что Вальтер Брайт в конце-концов свои идеи доводит до работоспособного состояния. Так что если не вскроется каких-либо подводных камней, принципиально препятствующих реализации borrow checker-а в D, то обновленный D рано или поздно появится.
ОтветитьУдалитьА вот на Go мне вообще никогда не хотелось код писать. Есть такие языки, вроде Go, Java, Lisp, SmallTalk или JavaScript-а, которые в принципе вызывают желание держаться от них на расстоянии.
Ну, я понимаю: Go, Java, SmallTalk. Тем более JavaScript. Но отчего Lisp в этом "погребальном" списке?
УдалитьАвторы D как дети малые, все в рот тянут. Т.е. в язык.
ОтветитьУдалитьТам же в комьюнити лебедь, рак и щука. Одним с GC хорошо, другие хотят без него, кто-то привык к идиомам С++, кто-то заглядывается на Раст. Уолтер уже затащил N недодуманных плохо совместимых фич, отчего ж не добавить N+1-ую?
Локализовать нишу как "нативный язык с GC" плохо, потому что сам GC медленный по дизайну, тут языки вроде Go с инкрементальными и конкурентными сборщиками будут над ним насмехаться. Ну и вообще, сужать нишу - не выбор Брайта сотоварищи, они стараются ее расширять, чтобы все-все могли найти что-то, за что язык любить, и за все остальное ненавидеть. :)
Хорошие новости в том, что нам как пользователям необязательно использовать все эти штуки. Меню большое, выбираешь себе что по душе. И оно даже работает. Это как квантовая механика с общей теорией относительности: выглядят несовместимыми, подружить их не получается, но по отдельности отлично обе работают.
У нас на работе есть как код на D c @nogc (плагин для Excel'я), так и обычный с GC (все остальное, что на D). Полет нормальный.
> Меню большое, выбираешь себе что по душе. И оно даже работает.
ОтветитьУдалитьНу вот в C++ это вроде как тоже работает. Но лично я как-то подустал уже от такого богатства выбора...
@Alex:
ОтветитьУдалить> Но отчего Lisp в этом "погребальном" списке?
Как-то не зашла в меня идея программировать польской записи с таким количеством скобочек :)
Forth, надо полагать, тоже не втыкает? Там скобок куда как поменьше, но все операции постфиксные
ОтветитьУдалить@Alex:
ОтветитьУдалитьForth полностью прошел мимо меня.
Один знакомый когда-то изучал его для себя. Другой рассказывал, что ему довелось на нем какую-то низкоуровщину попрограммировать. Вот и все, что было максимально близко ко мне из связанного с Forth.
Уолтер Брайт, 90-е, первая любовь - первый честно купленный компилятор Zortech C++ 3.1...
ОтветитьУдалитьПересобрал библиотеку с отладочной информацией и натолкнулся на баг в ассеблере (сравнение сегментированных указателей): инициализируется только CL, в CH - мусор и цикл уходит в никуда... А релизная сборка работает без проблем. Написал Уолтеру, он ответил, что типа "Вот черт! В релизе я в машинных кодах поправил, а сорцы исправить забыл...". Думаете, из D выйдет толк?
@ssko:
ОтветитьУдалить> Думаете, из D выйдет толк?
Нет. На сегодня не думаю. Хотя до недавнего времени была надежда, что D устаканивается и через какое-то время сообщество вокруг него начнет расти. Но вот эта новость лишний раз подсказывает, что авторы не могут остановиться.
C++ может себе позволить пухнуть от стандарта к стандарту -- слишком много на C++ написано и слишком многие им пользуются. А вот от D люди будут просто держаться подальше.
Но язык хорош. Я понимаю энтузиастов, которые берут его в работу не смотря ни на что.
@eao197
ОтветитьУдалить> Я понимаю энтузиастов, которые берут его в работу не смотря ни на что.
А вот я не понимал и не понимаю. Улучшенный C, улучшенный C++: too little too late...(
@ssko:
ОтветитьУдалитьНу вот у меня лет 12 назад было два основных языка на работе: С++ и Ruby.
На C++ делался основной код, который работал под нагрузкой и в режиме 24/7. А на Ruby делалось все остальное: начиная от DSL-ей для кодогенерации, заканчивая одноразовыми скриптами для анализа логов или содержимого БД на предмет поиска каких-то симптомов или последствий проблем.
Все было хорошо до тех пор, пока объемы данных для разовой обработки не выросли настолько, что Ruby-овый код мог лопатить их, буквально, часами.
И тогда я для подобных программок "на выброс" стал использовать D. Код пишется, наверное, чуть помедленнее, чем на Ruby, но значительно быстрее, чем на тогдашнем C++. Сборка мусора, приличная библиотека (я использовал в основном Java-подобную Tango), при возникновении какой-то ошибки сразу видно где она, не нужно в дебаггере сидеть, как в C++. А скорость работы кода потом на порядки выше, чем у Ruby.
Т.е. для продакшена D не годился по моему мнению. А вот для таких вот вспомогательных задач -- вполне себе.
Ну и если бы не внезапный разворот в сторону D2, я вполне мог бы прийти к тому, чтобы использовать D и как замену C++ для продакшена. Собственно, были такие планы.
И если у кого-то сейчас нет задачи сделать код, который будет в эксплуатации 10-15 лет, а задачи из категории "вот у нас туева хуча данных, которые мы должны обработать за пару недель и выкатить клиенту несколько красивых презентаций", то почему бы не делать их на том же D?
@eao197
ОтветитьУдалить> И если у кого-то сейчас нет задачи сделать код, который будет в эксплуатации 10-15 лет, а задачи из категории "вот у нас туева хуча данных, которые мы должны обработать за пару недель и выкатить клиенту несколько красивых презентаций", то почему бы не делать их на том же D?
Сегодня, боюсь, потому что Go...
@ssko:
ОтветитьУдалитьНе уверен, что Go хорош при работе со сложными структурами данных. Как по мне, так Go -- это клеевой язык, для проброса информации из одного источника в другой. Но сами данные лопатить на Go... Мне не кажется это хорошей идеей.
В Go отсутствие генериков приводит к отсутствию удобных и привычных по всем современным языкам комбинаторов для лопачения данных: map, filter, fold и т.п. То, что на других языках делается в одну строчку, на Go требует десятка строк с вложенными императивными циклами, где вероятность ошибок сильно выше. Добровольно в таком стиле писать не каждый согласится.
ОтветитьУдалить