Состоялся (https://dlang.org/blog/2018/09/04/dmd-2-082-0-released/) релиз основного эталонного компилятора DMD 2.082.0 (https://github.com/dlang/dmd/), который поддерживает системы GNU/Linux, Windows, macOS и FreeBSD. Язык D использует статическую типизацию, обладает синтаксисом, схожим с C/C++, и обеспечивает производительность компилируемых языков, при этом заимствуя некоторые полезные возможности динамических языков в области эффективности разработки и обеспечения безопасности. Например, предоставляется поддержка ассоциативных массивов, косвенное определение типов, автоматическое управление памятью, средства параллельного программирования, опциональный сборщик мусора, система шаблонов, компоненты для метапрограммирования, возможность использовать библиотеки на языке C, а также некоторые библиотеки на C++ и Objective-C.В новой версии (https://dlang.org/changelog/2.082.0.html):
- Расширены возможности пакетного менеджера DUB: улучшена обработка зависимостей, добавлена поддержка переменных в настройках сборки и убрана автоматическая ежедневная проверка обновлений (обновления теперь проверяются только при запуске "dub upgrade");
- Добавлены сборки для платформы Windows, заверенные цифровым сертификатом;
- Расширен синтаксис определяемых пользователем атрибутов;
- В подмножество языка "-BetterC", которое позволяет разрабатывать на D полностью совместимые с Си библиотеки, добавлена возможность использования литералов массивов в инициализаторах (например, "Sint[6] a1 = [Sint(1), Sint(2), Sint(3), Sint(1), Sint(2), Sint(3)];");
- Добавлена опция командной строки "--DRT-trapException=0" для отключения генерации исключений;
- В модуль std.array добавлена функция staticArray.Кроме этого следует отметить выпуск компилятора LDC 1.12.0-beta1 (https://github.com/ldc-developers/ldc/releases/tag/v1.12.0-b...), развиваемого на базе наработок проекта LLVM. В новой версии обеспечена поддержка LLVM 6.0, проведена оптимизация математической библиотеки, добавлена поддержка LTO-оптимизаций для платформы Win64.
URL: https://dlang.org/blog/2018/09/04/dmd-2-082-0-released/
Новость: https://www.opennet.ru/opennews/art.shtml?num=49228
Когда этот D в GCC включат уже? Ведь были подвижки!
Первый раз Дуплика плюсанул.
Вы таки не поверите
D так костылями облеплен, что не так уж от C++ ушел, но C++ при этом быстрее и обеспечен гигантским числом библиотек, которые не надо биндить, а просто использовать
Список костылей в студию.
>но C++ при этом быстрееПруфца бы
>которые не надо биндить, а просто использоватьРугая чертов язык и десятистраничные сообщения об ошибках с шаблонным говном?
...а потом ты хочешь написать range for но понимаешь, что тебе нужен и индекс тоже. И вдруг оказывается, что в D это (и массу других "мелочей") учли, а в плюсах - нет.Впрочем, C++14 и дальше стали весьма приличным языком, тут не поспорить.
Ну и насчёт скорости - бабка надвое сказала, сильно от контекста зависит. Например, в D во многих ситуациях вы не потеряете время на освобождение памяти вообще - потому что это не обязательная операция, отделённая от собственно вызова деструкторов, и с шансами процесс завершится вообще без вызова GC. Со строками, опять же, куда шустрее работа именно за счёт использования GC и слайсов.
А либ сейчас довольно много уже набралось. Впрочем, всё это D вряд ли спасёт, против повсеместно используемых плюсов и продвигаемого гуглом Go один хрен не вытянет. А жаль.
>Впрочем, всё это D вряд ли спасётПоходу - так.
>против повсеместно используемых плюсов и продвигаемого гуглом Go один хрен не вытянет.Ну-да, ну-да! Виноват кто угодно, но не Королева?! :)
А ещё желательно ткнуть где же это гуголь продвигает Go? Не 5 лет назад, а вот сейчас? Сюрприз - оно уже давно само ... 8-)
>А жаль.А нас ... орда! :) Всё суета сует, всё сущее уже было и ещё будет (С)
> Ну-да, ну-да! Виноват кто угодно, но не Королева?! :)Так никто не виноват же, просто ресурсы не сопоставимы.
> А ещё желательно ткнуть где же это гуголь продвигает Go? Не 5 лет назад, а вот сейчас?Вот прямо сейчас в Go впиливают дженерики, хотя изначально авторы были против. Им кто-то настойчиво посоветовал запилить, ибо отсутствие оных мешает окучивать новый пипл... И кто же это сделал?
> хотя изначально авторы были противОни не были против, они не знали как сделать дженерики так, чтобы результат их устраивал, потому не делали никак.
>Вот прямо сейчас в Go впиливают дженерики,один пропозал от ХЗ кого для Go v2.0 == прямо сейчас впиливают?!?!? Ню-ню ... :)
> продвигаемого гуглом Go один хрен не вытянет.Почему продвигаемый? Отличный язык.
Людям нравится, он естественно становится популярным.
>Почему продвигаемый?Потому что в его разработку вложены и вкладываются средства компании.
И решение об использовании для корпоративных продуктов - корпоративное решение.Если бы это частная была разработка пары олдскульных чуваков, то мало вероятно мы бы узнали о нем.
>> Если бы это частная была разработка пары олдскульных чуваков, то мало вероятно мы бы узнали о нем.Собственно, изначально оно примерно так и было. Просто оказалось, что это правильные олдскульные чуваки, и их гугл прикупил. Других не прикупил, они оказались менее правильными олдскульными чуваками.
>Просто оказалось, что это правильные олдскульные чувакиПравильные для чего? Для понижения стоимости разработки в ближайшем периоде?
Для того, что бы можно было нанять сотрудников подешевле?
И что-то отменяет факт вмененной политики разработки в крупной компании?
И сопутсвующих инвестиций в разработку?
А ты знаешь хоть один язык для промышленности который делали для повышения стоимости ***blah-blah-blah*** ? ;-)
>> Если бы это частная была разработка пары олдскульных чуваков, то мало вероятно мы бы узнали о нем.
> Собственно, изначально оно примерно так и было. Просто оказалось, что это правильные олдскульные чуваки, и их гугл прикупил.Разработка Go началась в 2007 году. Пайк работает в гугле с 2002го. Томпсон с 2006го. "Примерно так оно и было", ага.
>Пайк работает в гугле с 2002го. Томпсон с 2006го.Ну дык - плюс Гуглу, прибирают талантливых перцев, а не средневонючее ****о
И заметь результат - ЕСТЬ.
Go lang живёт уже сам по себе, сам себя раскручивая. Гугел с его помощью уже выкинул кучу С++ кода (dl.google.com - первый и полностью) и сЪэкономил бабла уже больше, чем когда то вложил ... "так что же тебе ещё надобно, пёс смердячий?!" (С) ИВмп.
> И заметь результат - ЕСТЬ.Суть не в вашеском cраче "хорош го или плох". Суть в том, что гражданин в сообщении #10 утверждает, что голанг начали разрабатывать пара олдскульных чуваков, которых затем гугл прикупил. Тем не менее, гугл именно что прикупил пару олдскульных чуваков, причём легенд, а затем уже заказал им проектирование нового языка под свои нужды. Очень большая разница.
Отличный язык, а библиотеки на шитхабе. NPM-hell вас ничему не научил?
>NPM-hell вас ничему не научил?На экранах TV, скоро, новый сериал "GO-бардак" и "Новые костыли всегда лучше".
> Впрочем, C++14 и дальше стали весьма приличным языком, тут не поспорить.Как это? C++14 перестал включать в себя большинство правил из предыдущих стандартов? Или вы думаете, что с помощью очередных костылей из "неприличного" языка можно сделать "приличный"?
move semantic порешал многие проблемы с выстрелами в ногу, например.
Не знаю, как насчёт костылей, а с помощью новых возможностей - запросто. А дальше - - берёшь C++ guidelines и пишешь, как там рекомендовано. И на ревью то, что им противоречит, не пропускаешь.
> Не знаю, как насчёт костылей, а с помощью новых возможностей - запросто.
> А дальше - - берёшь C++ guidelines и пишешь, как там
> рекомендовано. И на ревью то, что им противоречит, не пропускаешь.я даже больше скажу. компактность бинарного (исполняемого) кода и быстродействие у C++ всегда будет выше.
но "затраты" на написание практически не уменьшается и => скорость написания кода, практически не увеличивается. Облегчается, но не радикально. Ну невозможно одновременно пытаться притягивать язык к железу и в то же время наращивать новые и новые абстракции, да ещё в шаблонном коде, разобраться в котором может только автор и только под мухой.
> я даже больше скажу. компактность бинарного (исполняемого) кода и быстродействие у C++
> всегда будет выше.У джавы же!
Уже энное количество лет слежу за развитием этого языка, так вот с самого первого знакомства наткнулся на такую "МАЛЕНЬКУЮ" фичу: если в деструкторе использовать выделение памяти, то о сборище мусора можно забыть. Т.е. я создаю объекты, и вручную их не удаляю, т. е. полагаюсь на GC. Так, вот если в деструкторе будет выделение памяти, а она выделяется если, например, нужно отформатировать строку, то прога падает... хе.хе. Да, писал в багтрекер, сказали: да, есть такое. И как бы ВСЁ?!
Смотрел на те немногие проекты что на нем написаны. Так, как раз используют ручное освобождение памяти. По моему скромному мнению, такой язык так и останется так где он сейчас.
>но C++ при этом быстрееДа и х. с ним, что бинарный код, произведённый компилятором D, может быть, медленнее. Но когда нужно прожку попой в инет выставить, то D видится более безопасным, чем C++ и уж, тем более, чем C.
Тогда уж C#, у D нет ниши
>> Но когда нужно прожку попой в инет выставить, то D видится более безопасным, чем C++ и уж, тем более, чем C.
> Тогда уж C#, у D нет нишиу C# нет ниши, или вы прожки в инет выставляете с винды?
Каким образом C# привязан к винде? Хотя не отвечай. Уровень твоего понимания темы уже понятен и твое мнение не интересно никому
>Тогда уж C#С# в машинные коды могёт, чтоб без всяких там CLI? А D могёт.
C# ? Тогда представь, у тебя MIPSEL, 16 Мбайт Flah, 32 Мбайт ОЗУ, OpenWRT. И тут ты такой, пытаешься на это Mono вкорячить.
любимый досуг программистов - писать новые языки программирования.
чтобы их потом изучать и спорить о достоинствах и перспективах :)
Вообще да, так приятно посмеяться над программистами. Не так ли?А вы то у нас умный, образованный, небось этот, бизнесмен или еже еси капиталист? Нет? Владелец производства или блогер? Короче, реальный пацан, достигший успеха, ведь так? Или как?
Программисты создают, все остальное - паразиты, которые пользуются плодами их труда. Кто-то даже пользу приносит (UX/UI-специалисты), а кто-то так, паразитирует на чужом труде, продавцы разные, менеджеры эффективные и иже с ними
А у меня инстак приносит в месяц больше (и это за три месяца с нуля на уникальном контенте - тупо тревел-блог), чем приносила основная работа (программистом, кстати). Так что не надо ляля про паразитов. Кто нужнее показывает размер доходов.
А ты торгуй кайфом! Будешь ещё более уважаемым и нужным (судя по доходам) :-)
Досуг это для школоты, для программистов это - крайняя необходимость.
Время тратят на этот D; могли бы помогать улучшать Rust, Swift
в зависимости от вкуса названия языков можно переставлять.
>Время тратят на этот D; могли бы помогать улучшать Rust, SwiftЭто РАЗНЫЕ языки. Воспринимай D как "компилятор Питона": язык, допускающий или точнее, даже *заточенный* на очень *быстрое* написание достаточно надёжного нативного кода. Скорость написания рабочего кода на D лишь совсем незначительно уступает Питону. Скорость выполнения на порядок больше.
У Раста другая парадигма. Для малых коллективов/малобюджетных проектов и одиночек, D просто спасение. Но порог вхождения в D сильно выше, чем в Питон.
и еще, в отличие от питона, D - красивый язык)
Ну я даж не знаю. Это чистая вкусовщина же. Разве нет? Мне вот LISP нравится. Вот он - красивый с моей точки зрения.
> Ну я даж не знаю. Это чистая вкусовщина же. Разве нет? Мне вот LISP нравится. Вот он - красивый с моей точки зрения.Красивый. Но как язык общего назначения неудобный. Языки общего назначения красивы от дядюшки Вирта. Потому-что там под грамматику подведена математическая база, а не система костылей "а давайте мы еще вот такую фичу зопилим". Но их принято гнобить, потому-что на них нельзя без танцев с саблями стрелять себе в ногу в духе "смотрите пацаны как я могу (ц)".
> Потому-что там под грамматику подведена математическая базаПочитай про лямбда исчисление что ли.
>и еще, в отличие от питона, D - красивый язык)ну, это вопрос. явная перегрузка смыслов enum, например. нетривиальная семантика alias.
хотя, вопрос привычки, конечно
Сомнительно, потому что насколько помню, D позиционировали как универсальный язык.
На rust и swift быстрее найти работу, потому что есть вакансии на эти языки.
А на D вакансий нет.
>потому что есть вакансии на эти языки.Ну на swift допустим, а вот про rust врать не надо.
не прошел собеседование в мазилу? Иди к нам, на игого переучим!
>Иди к нам, на игого переучим!iPony, почему не под своим ником?
Там единственное условие чтбы ты в дупу давал ... как и на чём ты программируешь мазилоффцев даааавно не интересует!Кстати - я так понял что тебя взяли? :-))))))
>Сомнительно, потому что насколько помню, D позиционировали как универсальный язык.а в чём противоречие? D даёт возможность *быстро* написать код (не в ущерб современным приёмам), безопасность которого вполне на должном уровне. Это качество считается чрезвычайно важным, настолько, что даже отражено в официальном кличе "write fast, read fast, run fast". Узкой специализации при этом не заметно.
Раст заточен на максимальные гарантии безопасности кода, но в ущерб скорости написания, так как держать в голове придётся заметно больше, чего. И никто и не говорит, что процесс написания кода на Расте должен быть очень быстрым делом.
>А на D вакансий нет.
Ну да, *практически* нет. В СНГ, во всяком случае :)
но меня тут греют ностальгические воспоминания: когда я в 1995 году познакомился и даже немного популяризировал Python в наших краях, питоновских вакансий тоже было ровно ноль. Есть ли шансы на распространение, вопрос интересный. Имхо, шансы есть, смысл рекламироваь язык есть. Дело упирается в 1) уже написанную кодовую базу, которая пока бедновата 2) слишком уж разработчики любят словечко deprecated 3) нет хорошего учебника. Тем более, нет (для наших реалий), русскоязычного учебника. Книга Александреску хороша и даёт отличное введение в философию D, но не пригодна для начального обучения. Книга Çehreli охватывает базовый язык, но не даёт системного введения для начинающих.
как-то так.
кстати, заканчиваю свою попытку сделать учебник по D, вопрос, стоит ли пытаться издать в бумаге...
В бумаге - не уверен, а вот краудфандинг какой-то не помешал бы
>Это качество считается чрезвычайно важным, настолько, что даже отражено в официальном кличе "write fast, read fast, run fast".Ага, а внизу мааалюсенькими буквами - "But you can take only __two__ of them." :-))))
Впервые на него вглянул. Довольно тяжело воспринимается - не в пример Пайтону!
> Впервые на него вглянул. Довольно тяжело воспринимается - не в пример Пайтону!Да, конечно. Порог вхождения не сильно, но заметно, выше.
А когда дойдёшь до навороченных шаблонов --- даже не в собственном коде, в стандартной библиотеке, то вааааааще ух.Но и возможности заметно шире, кроме специфичных для интерпретируемой системы с динамической типизацией, фишек.
А может наоборот - тратят время на этот rust/swift - могли бы на D писать?
>Время тратят на этот D; могли бы помогать улучшать Rust, SwiftИдите вы своей Ржавчиной кобыле под хвост. D хотя бы гвоздями не приколочен к LLVM и Шлангу.
Писал на D и на Python. После D Python просто ужасен. В здравом уме проекты больше 100 срок на нем делать бы не стал.
Ну с динамикой всегда так - после перехода (и освоения) современных статически типизируемых языков обратно возвращаться не интересно ни для чего, кроме мелочи
Всегда так для кого? Зачем по себе людей судите? Нет, не все такие как вы.
Нет, мы все такие.
У меня наоборот. После знакомства с языками с динамической типизацией, я теперь знать не хочу, какой ширины у меня там int и int ли это вообще.
А дишечка она не как сишка/кресты, с типами-хрен-пойми-какого-размера-в-зависимости-от-платформы-компилятора-фазы-луны, у нее как раз размер точно определен.
А нафига мне вообще о нём знать? В Си[++] я, по крайней мере, его учитываю как аппаратную особенность платформы. А в этих языках "высокого уровня", которые от платформы якобы не зависят, - нафига он мне? Мы работаем с алгоритмами и абстракциями, но при этом должны помнить, какого размера у нас int, чтобы не получилось переполнения, и сколько места выделять под стэк, чтобы пережить рекурсию...С другой стороны, Ди - это очередная вариация на тему "Каким на самом деле должен был бы быть Си", поэтому я не удивлён.
> А нафига мне вообще о нём знать? В Си[++] я, по крайней
> мере, его учитываю как аппаратную особенность платформы. А в этих языках
> "высокого уровня", которые от платформы якобы не зависят, - нафига он
> мне? Мы работаем с алгоритмами и абстракциями, но при этом должны
> помнить, какого размера у нас int, чтобы не получилось переполнения, и
> сколько места выделять под стэк, чтобы пережить рекурсию...
> С другой стороны, Ди - это очередная вариация на тему "Каким на
> самом деле должен был бы быть Си", поэтому я не удивлён.вы похоже путаете что такое динамическая типизация
это вот такое
a = 5 + "5"
внимание вопрос! какого типа a ? и что за ёжоуж будет внутри?> помнить, какого размера у нас int, чтобы не получилось переполнения, и
> сколько места выделять под стэк, чтобы пережить рекурсию...а это как с динамической типизацией вообще связано???
>a = 5 + "5"Ну, формально, это камень в сторону слабой, а не динамической. В питоне она таки сильная, и такой фокус не прокатит.
> вы похоже путаете что такое динамическая типизацияМожет, и путаю, гуглить лень. Динамическая - это, вроде, когда тип задаётся в момент присваивания, а не в момент описания, нет?
> это вот такое
> a = 5 + "5"
> внимание вопрос! какого типа a ? и что за ёжоуж будет внутри?Да мне какбе пофигу. Будет число или строка - в зависимости от правил, принятых в данном конкретном языке. Я на это смотрю сугубо с практической точки зрения. Мне ведь нужно работать, допустим, арифметику считать, а не ставить эксперименты, что будет, если сложить число со строкой. И вот для того, чтобы считать арифметику, мне тип редко когда нужен. В нём может возникнуть необходимость только во время ввода/вывода.
>> помнить, какого размера у нас int, чтобы не получилось переполнения, и
>> сколько места выделять под стэк, чтобы пережить рекурсию...
> а это как с динамической типизацией вообще связано???Напрямую не связано, согласен. Но у кого чего болит :) Я это к тому, что в языках высокого уровня о таких вещах вообще знать не принято.
> И вот для того, чтобы считать арифметику, мне тип редко когда
> нужен.Чтобы использовать целые вам тип редко когда нужен, вероятно :-)
А то вот уже с дробными начинаются проблемы...(Ну тут на самом деле Lisp наилучший. С неограниченными целыми, рациональными...)
>> И вот для того, чтобы считать арифметику, мне тип редко когда
>> нужен.
> Чтобы использовать целые вам тип редко когда нужен, вероятно :-)
> А то вот уже с дробными начинаются проблемы...
> (Ну тут на самом деле Lisp наилучший. С неограниченными целыми, рациональными...)неограниченные числа много где есть, всякие BigDecimal и тд, если маленькие - живут как простые типы (ну, объекты), если длинные - то уже как массивы и тд
> вы похоже путаете что такое динамическая типизация
> это вот такое
> a = 5 + "5"
> внимание вопрос! какого типа a ? и что за ёжоуж будет внутри?integer, 55 (разьве тут что-то не так?)
только для полного вдохновения надо a=b+c, а b и с определить как 5 и "5" где-нибудь пятью уровнями выше и через пятьдесят килобайт сложноотлаживаемого кода.
> integer, 55у меня задергался глаз
> какой ширины табуляция в пробелах и пробелы ли это вообщеfixed
>У меня наоборот. После знакомства с языками с динамической типизацией, я теперь знать не хочу, какой ширины у меня там int и int ли это вообще.это существенно для языка, который может использоваться в качестве системного.
Да. И я на таком языке, в основном, пишу :) Но когда ты пишешь не драйвер для конкретной железяки, а приложение, там важнее иметь удобные инструменты для работы с абстракциями, а не с отдельными байтами.
> Да. И я на таком языке, в основном, пишу :) Но когда
> ты пишешь не драйвер для конкретной железяки, а приложение, там важнее
> иметь удобные инструменты для работы с абстракциями, а не с отдельными
> байтами.а в чём проблема? в чём неудобство абстракции real или int? нет автоматического "расширения" типа при необходимости? А в *компилируемых* языках такой механизм вообще, имеет смысл?
Ветка началась с утверждения о том, "какие хорошие типизированные языки и какие плохие нетипизированные". Я с этим не согласен. Когда ты делаешь арифметические вычисления в уме, ты не думаешь о типе. Тип - это костыль, который важен для низкоуровневого представления твоих данных. Но, когда ты работаешь с абстракциями, какой смысл ещё тратить время на выбор типа для арифметической переменной?
Так тип - это и есть хорошо именованная и определённая абстракция, именно для того он и нужен. И когда ты делаешь вычисления ты подразумеваешь, что операнды - это вполне себе объекты некоторго типа, у которых определены операция (то же сложение) с семантикой, которыую ты ожидаешь. А вот когда этого нет и начинается какая-нибудь утиная типизация там, где ты совсем не ждал - это больно.Причём в питоне вы типы всё равно определяете в виде классов, только преимуществами их в плане документирования кода и отлова ошибок потом почти не пользуетесь.
Где не важен тип - в D можно писать auto, оно там работает куда круче, чем в тех же плюсах. Но где нужно - типы к вашим услугам.
> плохие нетипизированные". Я с этим не согласен. Когда ты делаешь арифметические
> вычисления в уме, ты не думаешь о типе. Тип - это
> костыль, который важен для низкоуровневого представления твоих данных. Но, когдаздрасьте, пожалуйста. Когда я делаю прикидки в уме, то по крайней мере, деление на целые и реальные числа делаю. А в реальной жизни приходится ещё и конечную разрядную сетку учитывать. Интерпретатору хорошо, всегда можно неявно перещёлкнуть внутреннее представление, компилятору так нельзя.
а попытка не учитывать грубые материальные реалии... помнится, в книжках ещё по первому-распервому Алголу писали что-то типа "числа могут быть целыми и реальными... но целые числа не являются частным случаем реальных и наоборот и транслятор может не принять числа с более, чем 10-ю разрядами". Отличная абстракция!
> Когда ты делаешь арифметические
> вычисления в уме, ты не думаешь о типе.Внезапно только потому что тип предопределён, один единственный и подразумевается. Но это далеко не всегда.
> Да. И я на таком языке, в основном, пишу :) Но когда
> ты пишешь не драйвер для конкретной железяки, а приложение, там важнее
> иметь удобные инструменты для работы с абстракциями, а не с отдельными
> байтами.и мы валимся в core при попытке прочитать собственную базу, записанную на той же самой железке, с тем же bit order, но в 32битной системе, а читаем в 64.
Или просто все делаем максимальной разрядности, а когда нас запускают не на единственноверной платформе, тормозим не вдвое, а в двадцать раз, поскольку даже пресловутые 5+5 складываем в две итерации с ручным переносом переполнения между половинками (мы ж не знаем заранее, 5 там или MAXINT+1 для этой платформы). Или в четыре ;-)
что мешает выдумщикам новых-модных язычков предусмотреть тип byte, а все остальное делать через sizeof() - то ли авторитет Ритчи, то ли свое скудоумине - неведомо.
Значит, большое/сложное не пишете. Иначе быстро захотите такие вещи контролировать, когда нарвётесь на неожиданные падения быстродействия из-за преобразований, не влезание в кэши или тупо неизвестно откуда взявшиеся слабо повторяемые падения, так как где-то кто-то асинхронно передал совсем не ту структуру, что вы ждали.
Если большое/сложное писать без хорошо продуманной идеологии и интерфейсов между компонентами, то оно так и будет. Оно так и будет даже если использовать типизированные языки, просто с нетипизированными хаос наступает быстрее :)
Уже энное количество лет слежу за развитием этого языка, так вот с самого первого знакомства наткнулся на такую "МАЛЕНЬКУЮ" фичу: если в деструкторе использовать выделение памяти, то о сборище мусора можно забыть. Т.е. я создаю объекты, и вручную их не удаляю, т. е. полагаюсь на GC. Так, вот если в деструкторе будет выделение памяти, а она выделяется если, например, нужно отформатировать строку, то прога падает... хе.хе. Да, писал в багтрекер, сказали: да, есть такое. И как бы ВСЁ?!
Смотрел на те немногие проекты что на нем написаны. Так, как раз используют ручное освобождение памяти. По моему скромному мнению, такой язык так и останется так где он сейчас.
> самого первого знакомства наткнулся на такую "МАЛЕНЬКУЮ" фичу: если в деструкторе
> использовать выделение памяти, то о сборище мусора можно забыть. Т.е. яну. не любое выделение памяти, а выделение в куче, которое в свою очередь, должно управляться сборщиком.
выделение вручную и/или std.container... или @nogc --- работает.> выделяется если, например, нужно отформатировать строку,
ну. выражения типа writefln("%s %d", s... работают, так как см выше
> то прога падает... хе.хе.
не, не падает. а получает core.exception.InvalidMemoryOperationError@core
хотя, что сову о пень...> писал в багтрекер, сказали: да, есть такое. И как бы ВСЁ?!
а деструктор не предназначен для выполнения в нём сложных действий :)
> Смотрел на те немногие проекты что на нем написаны. Так, как раз
> используют ручное освобождение памяти. По моему скромному мнению, такой язык так
> и останется так где он сейчас.насколько понимаю, GC никому не нравится и подвергается существенному пересмотру
"косвенное определение типов" -- это что? alias this или что-то другое?
> В новой версии:
>
> Расширены возможности пакетного менеджера DUB: улучшена обработка зависимостей, добавлена поддержка переменных в настройках сборки и убрана автоматическая ежедневная проверка обновлений (обновления теперь проверяются только при запуске "dub upgrade");Замечательная часть _компилятора_.
Это не часть компилятора. Побуквоедствовать захотелось?
А вот так обстоят дела с вакансиями под этот ЯП.On Sunday, 8 January 2017 at 22:34:33 UTC, eugene wrote:
> Hello, everyone,
> could you share, please, your knowledge, where can i search D lang remote junior developer jobs?Currently there are barely any employers who require D programmers.
If you really want to work with D outside of hobby, then your best bet is probably freelancing and/or starting your own company.
There's just far too little companies using D, more even allowing you to work remotely.
You could take a look at this list and perhaps send in your job application, resume etc. and perhaps they might hire you for remote work, but honestly it's a shot in the sky.
Есть сомнения, что D это тупиковый язык, по сути бесполезный.
Потому что на тот же Rust уже давно есть вакансии.
А количество вакансий на Rust продолжает увеличиваться.
Тем более, что Rust - это более продуманный язык изначально в своей основе
В таком случае, все языки по сути бесполезны, кроме js.
>Потому что на тот же Rust уже давно есть вакансии.Вот лично вы пишете на rust на постоянке за деньги? Или может быть кто то другой в этом треде?
>Rust - это более продуманный язык изначально в своей основеЭта мерзкая мешанина? Это даже не смешно.
Кстати, следуя этой логике, нужно выбросить на помойку 99% опенсорца, а сидеть на винде и прочем.
>>Вот лично вы пишете на rust на постоянке за деньги?ещё нет, но планирую
>>Кстати, следуя этой логике, нужно выбросить на помойку 99% опенсорца, а сидеть на винде и прочем.
Насколько я знаю, компилятор DMD не является свободным.
>ещё нет, но планируюА я планирую стать первым человеком, высадившимся на марсе
>Насколько я знаю, компилятор DMD не является свободным.
А насколько я знаю, компилятор dmd распространяется по лицензии BSL-1.0
несвободная часть была "отпущена" владельцем (Symantec?) в прошлом году (или даже ранее, точно не помню)
Rust это язык с другими целями, причём поддерживаемый крупной компанией и находящийся на волне хайпа. Хотя последнее уже начинает спадать.Ещё раз, если Раст оправдает надежды на не сильно гемрройное средство написания в высшей степени надёжного кода, отлично. Всяческих успехов.
D ставит другую задачу: дать инструмент *быстрого* написания достаточно надёжного и шустрого кода.
Есть обоснованные надежды, что общая стоимость(*) кода общего назначения на D должна быть существенно ниже, чем аналогичного кода на C++ или Rust.
(*) включая "стоимость" (во всех смыслах) времени разработчика, времени отладки и затрат на ревью и рефакторинг
> поддерживаемый крупной компанией...которая в данный момент активно подыхает, но продолжает вкидывать деньги во всякие безумные затеи.
вообще весьма интересно
https://wiki.dlang.org/Build_D_for_Android
"Build D for Android"
"Build a sample OpenGL ES 1.0 GUI app ported to D"
Нехватка UFCS для методов класса/структуры немного напрягает. Замечальный язык, беда лишь с написанием binding-ов, особенно если одна внешняя библиотека в аргументах функций/методов хочет типы из другой библиотеки.
Ну, круче UFCS, чем в D, кажется, нигде нет. А что за кейс такой у вас?
Да просто на хватает. Есть структура, которая имеет индекс внутри что ссылается на элемент массива с другими структурами... И так несколько раз, естественно это просто данные из файла которые неким образом сходные с реляционной базой данных. Из этого следует что один тип не имеет смысла без массива с другими типами. При помощи UFCS, с методами класса который хранит все эти массивы, можно было бы организовать виртуальное свойство которое возвращает данные на которые ссылается структура. Не хочется разделять DiskType и MemoryType где это возможно сделать простыми указателями, а так индекс есть - вперед. Наверное я немного запутал... Для явного примера можно посмотреть типы данных в файлах BSP от серии игр Quake/Half-Life. Не то чтобы это сильно горит, но в D столько удобных вещей, что отсутствие данной просто удивляет.
> то чтобы это сильно горит, но в D столько удобных вещей,
> что отсутствие данной просто удивляет.DIP оформлен? что ответили? :)
Где-то я читал что это было сделано специально, ибо UFCS для методов может внести "неясность" ТМ. Но добрые люди показали как-то трюк (уже забыл как он выглядит, нужно будет Discord пнуть еще раз) который через хитрую схему позволяет UFCS для них, но это было весьма не так удобно. Может действительно DIP всунуть, или попробовать компилятор помучить...