Опубликован (https://dlang.org/blog/2018/11/02/1748/) релиз основного эталонного компилятора DMD 2.083.0 (https://github.com/dlang/dmd/), который поддерживает системы GNU/Linux, Windows, macOS и FreeBSD. Язык D использует статическую типизацию, обладает синтаксисом, схожим с C/C++, и обеспечивает производительность компилируемых языков, при этом заимствуя некоторые полезные возможности динамических языков в области эффективности разработки и обеспечения безопасности. Например, предоставляется поддержка ассоциативных массивов, косвенное определение типов, автоматическое управление памятью, средства параллельного программирования, опциональный сборщик мусора, система шаблонов, компоненты для метапрограммирования, возможность использовать библиотеки на языке C, а также некоторые библиотеки на C++ и Objective-C.В новой версии (https://dlang.org/changelog/2.083.0.html):
- Расширены возможности по связыванию с бинарными файлами, скомпилированными из кода на языке C++, улучшена поддержка разработки проектов, сочетающих код на языках C++ и D;
- Представлен дополнительный набор предопределённых идентификаторов для определения C++ runtime на этапе сборки: CppRuntime_Clang,
CppRuntime_DigitalMars,
CppRuntime_Gcc,
CppRuntime_Microsoft и CppRuntime_Sun. Для определения C runtime используются идентификаторы CRuntime_Bionic, CRuntime_DigitalMars,
CRuntime_Glibc,
CRuntime_Microsoft,
CRuntime_Musl и CRuntime_UClibc;- Предложен альтернативный синтаксис для связывания кодом на С++: 'extern(C++, "foo") void cppFunc();
- Добавлено два новых встроенных типажа (traits (https://dlang.org/spec/traits.html)): __traits(isZeroInit, T) для проверки инициализации типа нулевым значением и __traits(getTargetInfo, "key") для получения детальной информации о целевой платформе при компиляции;
- Добавлена новая pragma linkerDirective, позволяющая указать библиотеку, которую следует передать компоновщику в исходных текстах.
Дополнительно можно отметить выпуск LDC 1.12.0 (https://github.com/ldc-developers/ldc/releases), компилятора для языка D развиваемого на базе наработок проекта LLVM. В новой версии обеспечена поддержка LLVM 7.0, расширена поддержка JIT-компиляции, проведена оптимизация математической библиотеки, добавлена поддержка LTO-оптимизаций для платформы Win64.
URL: https://dlang.org/blog/2018/11/02/1748/
Новость: https://www.opennet.ru/opennews/art.shtml?num=49546
Интересно, а на нём кто-нибудь пишет?
Всё никак не допишу проект, который объединяет tui и gui, потому что после того, как я расковырял исходники Qt, поддерживать существующие биндинги мне сразу же расхотелось. Поглядывал ещё на WPF, JavaFX в поисках идеальной модели. На данный момент был вариант текстовый, но пока только столкнулся с адом поддержки виндовой консоли https://github.com/ttldtor/plut затем я его стал переносить в https://gitlab.com/ttldtor/plut Надо бы продолжить, но меня всякие другие языки отвлекают, scala, например =)
WPF прекрасен, но не кроссплатформенен, к сожалению. А вот на Скале (лучший язык, по-моему) с JavaFX можно создать что-то офигенное, мне кажется. Я пытался сделать так, чтобы JavaFX-интерфейс крутился в отдельном Akka-актёре, но что-то оно не заработало, видимо подкапотные проблемы синхронизации какие-то, в результате забил.
> после того, как я расковырял исходники Qt, поддерживать существующие биндинги мне сразу же расхотелосьМожно поподробнее. Заинтриговали! :)
Далась вам всем эта Скала… Только время даром теряете. А время, как известно, деньги!
Именно, что время—деньги. И инвестировать его надо не в закатно-вручной php и не в букеты скоротечных js-фреймворков, а в инструменты, которые позволят эффективно решать задачи и через год, и через десять.
> Именно, что время—деньги. И инвестировать его надо не в закатно-вручной php иPhp будет жить вечно
Зачем вообще поддерживать виндовую консоль?
> Всё никак не допишу проект, который объединяет tui и guiКогда допишете -- подёргайте, у нас очень неслабые люди на это лет десять-пятнадцать назад наваливались и пришли к выводу, что не надо так делать. Может, я ещё не слишком старый буду.
Проблем слишком много в общем случае что по выводу (начиная с типовых разрешений), что по вводу (начиная с клика правой мышкой -- ну или без него, да и есть ли та мышка или в эквиваленте вообще).
Отчасти их отголоски видны и в том, что в alterator этого самого клика правой мышкой нет и теперь.
См. тж. http://ndk-xx.sf.net в качестве одного из артефактов тех лет.
https://ru.wikipedia.org/wiki/D_(язык_программирования)#Использование,_распространение
Tilix на GTKD написан, больше ничего не знаю.
Пишут конечно, но серьёзные мужики, а не восторженные школьники с растом, от которых шума гораздо больше чем реального выхлопа.
Серьезные мужики настолько серьёзны, что пишут на скучном C++.
C++ никак не мешает кодить на D. Я проверял.
И ещё более скучном Ассемблере :)
>Интересно, а на нём кто-нибудь пишет?Такое ощущение, что язык вообще мертвый. Хайпа нет, явлений типа докера нет, смысла от него тоже нет - им не пользуются, да и не модный он.
да и вакансий на нём нет
Из старичков нет, а из моложежи есть Swift, Golang и т.д. Какой смысл? Я так понимаю тольок ради Александрески и завели язык.
Неправильно понимаешь.
Дженерики есть?
там вроде шаблоны есть
Это разве не синонимы?
Обынчо под "шаблонами" имеется в виду плюсовая система генерации кода (котораяЮ блин, тьюринг-полная сама по себе), а под "дженериками" - джваовская, дотнетовская и подобные - не столь мозголомные, но существенно более ограниченные.В D шаблоны круче плюсовы по мощи, при этом понятнее на порядок. Благо, их там Александреску делал в основном, который точно знал, что ему надо.
О! А я все боялся, что там не шаблоны, а дженерики. Теперь точно надо посмотреть. Все руки не доходили.
Нет бы спросить есть ли там рефлексия и enum string, они тролят своими дженериками ЛицоРука.жпег
Лучше про алгебраические типы.
Не поможет - в D они есть, в стандартной библиотеке, сделанные именно через шаблоны :-)
Как будто это кому-то нужно.
Это много кому нужно, это одна из причин почему выбирают с#, жабу.
Мне не нравится, что уподобляются С/С++ и вводят какие-то немыслимые "магические" идентификаторы и ключевые слова с двумя подчеркиваниями в начале, какой-то extern(C++) и прочее. Вместо того чтобы сделать универсальный синтаксис для этого.
"для этого" - это для чего? Потому что я общего между extern(C++, "foo") и __traits вообще не вижу.Если что - extern(x, y) - это вполне общий синтаксис - пара "язык, имя на этом языке". По факту кроме как плюсовый вариант никому ничего не нужно. Что до __traits - это тоже общий синтаксисс метаданных, это просто к существующей туче ещё разновидностей добавили.
Но вообще - дишники всегда между общностью/строгостью и удобством применения в частных, но распространённых случаях выбирали удобство, если это было хоть как-то возможно. Язык от практиков и для практиков, не "академический" совершенно.
Ну в частности extern(C++, "foo") нарушает стройность синтаксического анализа, потому что ++ это операция, а тут она выступает как часть какого-то магического идентификатора. ИМХО должно быть все в кавычках: extern ("C++", "foo").
__traits - вот зачем там подчеркивания? В С/С++ понятно, все боятся тронуть священную корову обратной совместимости, но тут-то зачем? Это мелочь, но именно из таких мелочей складывается и общее впечатление, и будущее языка.
Если вы делали на D что-то серьезнее хелловорлда или алгебраических операций, допустим, пытались завести Vibe, подтянуть все зависимости и реализовать не самую хитрую логику, то должны понимать почему он в разряде фанбойских ЯП.Стэктрейсы в стиле С++, только если за С++ и разбор полотенец с ошибками на 5к строк готовы платить, то по принципу бритвы Оккама, D - новая сущность.
Кому интересно, покопайте на Ютубе спич про D в ААА играх, по мимике и докладу станет понятно что для работающего программиста D проблема, а не решение.
Делаю намного более серьезное чем хелловорд уже несколько лет. Отличный язык для моих задач, только гуя не хватает мне. Метапрограммирование позволяет автоматизировать многие задачи, которые на С++ нужно писать руками. При этом код приятно выглядит и просто поддерживается. D как раз для меня оказался решением и сэкономил кучу времени и нервов. Более продуктивный язык чем С++.
Какую IDE посоветуете?
Смотрю там есть несколько с виду похожих по функционалу.>> только гуя не хватает мне
Что, за столько лет нет биндингов к Гую?
На Windows - если нужно будет много отладчиком пользоваться, то Visual D поверх Visual Studio 2015/2017 (хотя даже 2010 тоже поддерживается). Для остальных - Visual Studio Code & Code D. Есть ещё DLang IDE, но на любителя как с IDE для GNOME.
На Windows - если нужно будет много отладчиком пользоваться, то Visual D поверх Visual Studio 2015/2017 (хотя даже 2010 тоже поддерживается). Для остальных - Visual Studio Code & Code D. Есть ещё DLang IDE, но на любителя как с IDE для GNOME.
Не, не для винды. )
Спасибо за инфу.
А Code::Blocks не пробовал? Для си и плюсов он вполне себе годный кроссплатформенный вариант.
А в нем есть что-то для D? Кстати, Visual Studio Code & Code D поддерживают интеграцию с DUB, DScanner, DFormat (DFMT) что есть неслабый аргумент в его пользу, но есть некоторые проблемы с отладкой (над чем сейчас работают). Visual D не умеет и половину, но есть отличнейший отладчик Mago для D (но только для Windows).
Но есть неслабый аргумент против, оно на Electron.
А вот здесь спросить не буду. Code D единственная причина ему быть на машине.
А какой блокчейн-проект использует D? Все готовые для продакшена ЯП используются в блокчейн-проектах, а про D не встречал такого.
вакансии появились на D?
по-моему быстрее денег можно программированием на rust, swift заработать))))
И на nodejs, ещё.
да даже на pascal программировать, можно денег быстрее заработать))))
На swift - да. А rust то тут каким местом?
Ну на Swift понятно. А Rust кто платить будет, Mozilla?
вроде уже помаленьку появляются вакансии на rust
"кормить Растишкой" - это вакансия в детский сад, нянькой, а не то что вы подумали :-)
DMD ещё бы расширить поддержку аппаратный платформ в кодогенерации.
DMD хорош как есть, для этой задачи вполне годится LDC. DMD для плюшек, LDC для релиза.
>для этой задачи вполне годится LDCLLVM? Не, спасибо, не надо.
Clang успел стать плохим компилятором?
Хороший - g++, виртуальных машин не требует.
> Хороший - g++, виртуальных машин не требует.Т.е. познания на уровне "Рабинович напел"?
Название - просто небольшая хохмочка (попутно отлично фильтрующая "Ыкспертов"), намекающая на работу оптимизаторов, верификаторов и проч, с "промежудочной репрезентацией кода" (IR). Т.е. независимо от конкретного ЯП фронтенда.
Более конкретно - для многих проверок и оптимизаций используются разновидности abstract interpretation.И (вы только держитесь покрепче! Или зажмурьте глаза и не читайте дальше, повторяя громко "вы все врети". И никогда не делайте g++ -fdump-ipa-all, ни в коем случае не заходите на https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html и не читайте строки "The C and C++ front ends currently convert directly from front end trees to GIMPLE"!)
если вы считаете, что в gcc или g++ нет ни промежуточной репрезентации, ни вариации абстрактной интерпретации, то у меня для вас довольно плохие новости … но вы не расстраивайтесь - ведь есть отличный и провереный временем Борланд C++ первых версий, без всех этих новомондных обвесов и свистелок!
Clang, LDC, Rust генерируют нативный код. Который не имеет никакого отношения к виртуальным машинам. LLVM используется как backend, как библиотека в которую можно напихать инструкции а потом сказать - сделай базовую оптимизацию, сгенерируй код конкретно для x86/x86_64/arm/... и сделай оптимизацию ещё раз но уже конкретно для целевой архитектуры. Точно также как и GCC/G++ с GIMPLE. Можно взять любой онлайн набор компиляторов C++, выбрать G++ & Clang и посмотреть что выходит в ASM. Довольно часто Clang впечатляет - меньше инструкций, жесткая оптимизация, тот же результат.
Он перепутал LLVM и JVM, наверное
Нет, не перепутал. Оба - не нужно.
Таки да, смотрите выше.