Разработчики языка программирования D объявили (https://forum.dlang.org/post/oc8acc$1ei9$1@digitalmars.com) о переводе официального эталонного компилятора DMD (https://dlang.org/) (Digital Mars D) в разряд свободного ПО. Бэкенд DMD, который ранее поставлялся в исходных текстах, но под проприетарной лицензией, отныне будет распространяться (https://github.com/dlang/dmd/pull/6680) под свободной лицензией Boost (https://ru.wikipedia.org/wiki/Boost_Software_License), которая уже используется для кода фронтэнда.
Поставка бэкенда DMD под проприетарной лицензии была связано с тем, что значительная часть кода была разработана компанией Symantec, сохранившей свои имущественные права. Возможность перехода на свободную лицензию открылась после того, как компания Symantec официально предоставила проекту D право по перелицензированию кодовой базы.
Язык D использует статическую типизацию, обладает синтаксисом, схожим с C/C++, и обеспечивает производительность компилируемых языков, при этом заимствуя некоторые полезные возможности динамических языков в области эффективности разработки и обеспечения безопасности. Например, предоставляется поддержка ассоциативных массивов, косвенное определение типов, автоматическое управление памятью, средства параллельного программирования и т.п.
Кроме DMD сообществом параллельно развиваются два свободных компилятора LDC и GDC, которые являются фронтэндами к LLVM и GCC. По сравнению с LDC и GDC, официальный компилятор DMD отличается (https://forum.dlang.org/post/igulpsokqxunwoijeukp@forum... значительным превосходством в скорости компиляции, что позволят применять его реализации функциональности, похожей на скрипты (код на лету очень быстро компилируется и выполняется).URL: https://www.reddit.com/r/programming/comments/6419py/the_off.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=46354
Отличная новость. Джва года не ждал, но все равно приятно ошарашен.
Поздно, нишу уже почти заняли Go и Rust. Лет бы пять назад поменяли лицензию и всё было бы по другому, а если сразу бы под свободной лицензией выпустили мир мог бы поменяться.
Лол, какую там нишу раст занял?
Ну а у них с го ниши разные, и против рекламы гугла и его ресурсов трудно переть.
Гугл мог взять D и сделать конфетку, убийцу Java и C#.Вместо этого они предпочли изобрести Го...., продвигая его админресурсом.
D и без гугла - чудо язык. Разве что без пиара.
И го до него далеко, у го вообще ниша узкая, а ди - "язык для всего".
Чего ему действительно не хватает (и что, если появится - может переломить ситуацию) - "родного" графического тулкита уровня Qt (именно родного - биндингов то там завались), и желательно с сорт оф "qml" за шаблонизаторе от Vibe.D.
> D и без гугла - чудо язык. Разве что без пиара.
> И го до него далеко, у го вообще ниша узкая, а ди
> - "язык для всего".
> Чего ему действительно не хватает (и что, если появится - может переломить
> ситуацию) - "родного" графического тулкита уровня Qt (именно родного - биндингов
> то там завались), и желательно с сорт оф "qml" за шаблонизаторе
> от Vibe.D.ЕЩЁ ОДИН ТУЛКИТ ???? да вы издеваетесь ?? это то что нужно для популярности ???
хорошие биндинги к Qt вполне достаточны (и необходимы)
Чушь. Qt - это не графический тулкит, а фреймворк. И он дает кучу костылей и всякой сущности, которой нет в крестах, но в ди она нафиг не уперлась - строки, потоки, qvariant, контейнеры, xml с жсоном, сеть - практически все это нафиг не нужно ибо в ди есть по умолчанию. Потому и нужен родной тулкит (и сделать надо только графический тулкит - все остальное то есть из коробки), а не тащить стопицот корявых оберток над крестовыми костылями.
> Чушь. Qt - это не графический тулкит, а фреймворк. И он дает
> кучу костылей и всякой сущности, которой нет в крестах, но в
> ди она нафиг не уперлась - строки, потоки, qvariant, контейнеры, xml
> с жсоном, сеть - практически все это нафиг не нужно ибо
> в ди есть по умолчанию. Потому и нужен родной тулкит (и
> сделать надо только графический тулкит - все остальное то есть из
> коробки), а не тащить стопицот корявых оберток над крестовыми костылями.окей, стринги не нужны, что там с сетью - не знаю, но думаю сеть в Qt повыше уровнем чем сокеты всякие в чистом D
но к графике и высокоуровневым вещам Qt биндинги однозначно нужны целиком и полностью
> стринги не нужны"продвинутые" маководы с тобой не согласятся.
>но думаю сеть в Qt повыше уровнем чем сокеты всякиеЭээ, нет. Тут есть Vibe.d, это как раз то в чем дишечка вне конкуренции.
Ага, вебня - это, конечно, не костыли.
> костылей и всякой сущности, которой нет в крестахА так-же сущностей которые есть в крестах и несовместимы с тем что там есть.
Например QString не получиться заюзать с unordered_map.
Не суть. Главное - что Qt целиком и полностью завязан на свои велосипеды, которые в нем рождены от бедности крестов. В ди все это нафиг не нужно, нужен только графический тулкит, родной на родных средствах, без богомерзкой фигни уровня "конвертировать одни строки в другие" и прочей дряни. Ммм, а ведь qstring еще и cow и все такое прочее.
Большая часть того, что он предоставляет - есть искаропки, в стандартной библиотеке. И нужен только гуй.
> Не суть. Главное - что Qt целиком и полностью завязан на свои велосипеды, которые в нем рождены от бедности крестов. В ди все это нафиг не нужно, нужен только графический тулкит,...Высокая аналитика! Т.е. когда реализацию, скажем, строк прибили гвоздями к языку (вместе с проблемами данной конкретной реализации) то это --- (как там у вас? --- вау, да?)
В огромном количестве языков есть 2 типа, байтовый массив и строка, проблема в том что в "c" строк исторически(изначально)нет, но есть куча реализаций строк для разных случаев, естественно, несовместимых между собой.
Проблема именно в несовместимости, когда мы хотим не целиком писать всё приложение с нуля, а использовать готовые компоненты, т.к. писать высокоуровневые(в т.ч. gui) компоненты используя только выделенные куски памяти под char-ы немного дорого и неудобно, разработчики "компонентов" придумывают свои реализации ( QString и т.п. ), потому что единого стандарта нет, а если каждый раз выносить себе мозг с выделением памяти в местах, где это не столь важно, не хватит времени на реализацию основных идей.В Итоге мы имеем несколько вариантов перекосов в программировании:
1. Пишем на C, C++ очень долго используя только базовый стандарт - обычно не работает для больших проектов.
2. Пишем свои костыли для C, C++ или используем ограниченный набор чужих, обрезая себе возможность использовать код компонентов использующих другой набор костылей.
3. Пишем на другом "высокоуровневом" языке в т.ч. то что на нём писать не хорошо (java к примеру)
> 3. Пишем на другом "высокоуровневом" языке в т.ч. то что на нём писать не хорошо (java к примеру)Разверните вашу мысль.
>> Не суть. Главное - что Qt целиком и полностью завязан на свои велосипеды, которые в нем рождены от бедности крестов. В ди все это нафиг не нужно, нужен только графический тулкит,...
> Высокая аналитика! Т.е. когда реализацию, скажем, строк прибили гвоздями к языку (вместе
> с проблемами данной конкретной реализации) то это --- (как там у
> вас? --- вау, да?)Вау, вау. Строковый тип в D весьма продуман (см книгу Александреску).
Использовать другую реализацию никто не запрещает, в D это весьма легко.
> Вау, вау. Строковый тип в D весьма продуман (см книгу Александреску).... Для случая Александреску.
> Использовать другую реализацию никто не запрещает, в D это весьма легко.
Здесь объяснитесь, а то выходит, что строки _встроенные в язык_ не killer-feature вовсе.
>... Для случая Александреску.Это какой-то особый, экзотический случай?
>> Использовать другую реализацию никто не запрещает, в D это весьма легко.
>Здесь объяснитесь, а то выходит, что строки _встроенные в язык_ не killer-feature вовсе.Что вообще может быть за "киллеp-фьюче" в приложении к одному из базовых типов? У которых одна задача: компилятор должен иметь возможность достаточно эффективно их обрабатывать при сохранении достаточного удобства? Все остальные рюшечки --- дело библиотек.
Окей, в двух словах: в D строки строятся а) на уровне представления (литералов): не из машинных байт, а знаков юникода. Записывать можно как непосредственно знаки в utf-8, так и *имена* в стандарте Юникод, а также числовые представления для utf-8/16/32. Из знаков набираются строки, причём можно скармливать как привычные строки (ескейп-последовательности учитываются), так и "буквальные" строки, воспринимаемые "как есть". Кроме двойных и одинарных кавычек, разделителями могут быть любые знаки. Что необычного: имеются "строки токенов", состоящие из слов D, и "шестнадцетиричные строки", представляющие любые произвольные сырые данные.
б) на уровне кода, строка --- это массив неизменяемых знаков (immutable(XXchar)[]), причём тип не включает длину, но при необходимости, фиксированная длина может быть задана. Под XXchar имеется в виду, что при необходимости можно уточнить --- char (utf-8), wchar (utf-16), dchar (utf-32). Отельные знаки и их строки *автоматически* обрабатываются по правилам соотв. кодировки Юникода (если нужно работать с неюникодными строками, или байтовым представлением строки, в качестве базового типа ожидаемо используется ubyte).
Под "массивом" знаков имеется в виду массив в понимании D --- это *диапазон* и к нему применимы любые (в рамках :) ) алгоритмы стандартной библиотеки, а не только операции из строковой библиотеки. И понятно, что строки в D --- "интернированые" (в терминологии Qt/C#).
Ну и что тут такого специфичного только и исключительно "для Александреску"?
>Главное - что Qt целиком и полностью завязан на свои велосипеды, которые в нем рождены от бедности крестов.Поздравляю с выходом анабиоза! 10 лет ты провел в криокамере и теперь несешь х..ню по незнанию
Кстати. Вроде был проект переписать Qt на современных плюсах, поскольку в них (плюсах) появилось много того, чего небыло на момент создания Qt и необходимость в этих костылях отпала.
Никто не вкурсе, как там оно?
Ну постепенно так и делают. Но это же кресты - разве что в 1% необходимость костылей упала. А иной раз "некостыльное" и современное решение еще и гораздо кривее и костыльнее кутешного, навроде слотов-сигналов через шаблоны.
>хорошие биндинги к Qt вполне достаточны (и необходимы)И хорошие биндинги к KF тоже не помешают.
И какая же именно узкая ниша у Go? И почему чудо язык так и остался практически никому не нужным?
Всяческие сетевые сервисы?
>И почему чудо язык так и остался практически никому не нужным?Потому что чудо-язык это конечно хорошо, но он сам по себе, никто из корпораций его не проталкивает. И народ идет писать на хреновом языке, зато за деньги. И наоборот - всем выгодно нанимать жавамакак потому что все стабильно и отлажено.
Язык то много кому нужен - язык то шикарный, но в любительском секторе. Так то можно и на 2% линукса по такой же схеме пенять.
> Потому что чудо-язык это конечно хорошо, но он сам по себе, никто из корпораций его не проталкивает.Scala это не помешало.
Scala - не самостоятельный продукт, а придаток к жабе.
Скале это помогло, и сильно. Потому что она получила готовую инфраструктуру - конфигурация, управление жизненным циклом, отлаженную VM и так далее. В результате даже её общая чудовищность (а она концептуально адово сложна) её не убила. Ну и объём джава-экосистемы таков, что там всё поместится.
> Всяческие сетевые сервисы?Это узкая ниша? Может назовешь тогда хоть одну более широкую, чем эта? Особенно с учетом того, что вещи типа Docker и LXD ты тоже в нее пихаешь.
> Потому что чудо-язык это конечно хорошо, но он сам по себе, никто из корпораций его не проталкивает.Расскажи, какая корпорация проталкивает R, python, ruby, perl, haskell, skala, lua?
> Язык то много кому нужен - язык то шикарный, но в любительском секторе.
Ни разу не заметно, чтобы он был многим нужен. Более того, заметно, что чем дальше, тем менее он кому-то нужен.
>Так то можно и на 2% линукса по такой же схеме пенять
Вот только у D и 0.1% нет. Причем это тотально, а не только в самой слабой из ниш как у линукса.
Ясно, не стоило зря кормить очередного хейтерка.
Кормят вообще-то троллей, а не хейтеров. Хотя подозреваю, что ты не знаешь значения ни одного из этих слов и просто используешь их как ругательство, когда кончаются аргументы.
> Расскажи, какая корпорация проталкивает R, python, ruby, perl, haskell, skala, lua?сколько лет понадобилось тому-же Питону для прохода в мэйнстрим? И не тогда ли это произошло, когда его рискнули использовать крупные игроки?
>> Язык то много кому нужен - язык то шикарный, но в любительском секторе.
> Ни разу не заметно, чтобы он был многим нужен. Более того, заметно,
> что чем дальше, тем менее он кому-то нужен.
> Вот только у D и 0.1% нет. Причем это тотально, а не
> только в самой слабой из ниш как у линукса.Достаточно понять, что может дать обсуждаемый инструмент. Не стать "убийцей C++", что бы там не говорили восторженные последователи, а что может *реально* дать. Какое-то время назад я пытался сформулировать возможную нишу (посмотри также http://gleb-kulikov.livejournal.com/14112.html#comments) /правда, про Go сейчас сказал бы немного иначе, но суть от этого не поменяется/:
ИМХО, обсуждение ведётся совсем не с того конца. Какое к чёрту tiobe и HR!
Какие, к дьяволу, заработки! Это всё имеет смысл обсуждать при достаточном
распространении технологии, а не на этапе вялой пенетрации. Не надо рассуждать о
D как о полной замене C++ (с преданием последнего забвению). Всё гораздо проще.Ситуация, как я её вижу, на сегодня такова (и пожалуйста, постоянно держите за
скобками нужды открытых проектов, которые как правило, начинаются в одиночку или
очень небольшими коллективами!):из языкового инструментария программиста, на слуху C#, C++, Python, Java, Go,
Delphi, Ruby, Erlang —- в таком порядке. Про Хаскел, Лисп/Шему и т.п., давайте
не будем: технологии модные, но абсолютно маргинальные.Из этой "большой восьмёрки", честными компилируемыми языками являются только 2:
C++ и Delphi. C# интерпретируемый ("управляемый") принципиально, Go формально
компилируемый, но поддержка рантайма такова, что сводит "честность" к минимуму,
если не нулю. Само по себе это не страшно, современное железо достаточно мощное
(плюс поддержка JIT), чтобы делать на интерпретируемых языках практически любые
задачи, да ещё и "безопасно".Тем не менее, сплошь и рядом от интерпретируемых языков в проекте отказываются
(вынужденно —- деваться некуда!) и переходят на "честный" компилятор. Остаётся
C++ и Delphi.Про Delphi особый сказ: верятно, резкий спад популярности имеет под собой
достаточно серьёзные основания, кроме чисто коммерческого аспекта.Остаётся C++. И тут видим чудную картину: с одной стороны, программирование на
шаблонах стало настолько общим местом, что без него о развитии как
практического, так и теоретического программирования, говорить не приходится.
С другой стороны, реализация этой концепции в C++ настолько уродлива и
ненадёжна, а порог вхождения в неё настолько высок, что говорить об удобстве и
скорости разработки на C++ просто не приходится. Да, можно сделать всё, что
угодно (ассемблер не нужен!), но "процесс изготовления" будет идти весьма
неспешно.Язык, после долгого периода стагнации, бурно развивается, но устранить
уродливость механизмов шаблонного программирования —- без переработки языка в
ноль, до полной неузнаваемости —- невозможно.Результат: абсолютное большинство вновь начинаемых задач планируется на C#. В
процессе проект частенько несколько раз умирает (борьба с особенностями
"управляемой среды"), теряет кросс-платформенность, и т.п.Проект "одного человека" позволить себе такую роскошь, как правило, не может.
Поэтому сообществу СПО (И сообществу хобби — программистов, тем более, что это
часто пересекающиеся множества), как воздух необходим честный компилируемый
(высокопроизводительный) язык, дающий (ВСЕ условия необходимы) высокую скорость разработки, защиту от дурака и достаточно полную свободу рук.D доказал, что этим условиям он удовлетворяет: достаточно посмотреть на его
стандартную библиотеку, насколько мало (!) —- мало для такой большой и молодой
системы —- там багов, и насколько быстро она была разработана.Это не значит, что Rust и Go должны быть забыты —- у них другие ниши и цели.
А вот как универсальное решение —- D вполне перспективен и повторюсь, требуется
сообществу СПО, как воздух.Почему именно D? Предложите другую альтернативу. Я таковой, ПОКА, не знаю.
Язык и главное, компиляторы, стали достаточно зрелыми, чтобы начать их активно
использовать. Ну так используйте, чёрт побери!Перестаньте спорить, является ли "D могильщиком C++" —- речь вовсе не об этом.
Посмотрите, может ли D (а порог вхождения в него весьма низок, гораздо ниже, чем
в C++) быть мотором вашего проекта. И используйте!Ждать, пока на tiobe у технологии прибавятся проценты —- могут и должны! —-
только большие конторы. У малых коллективов такой роскоши нет.И если технология чего-то стоит, она заживёт. В противном случае, весь пар
выйдет в свисток бесплодных дискуссий, и через несколько лет останется только
сожалеть, что проморгали перспективную вещь, которая могла бы очень и очень
помочь.
> из языкового инструментария программиста, на слуху C#, C++, Python, Java, Go,
> Delphi, Ruby, Erlang —- в таком порядке. Про Хаскел, Лисп/Шему и т.п.,
> давайте
> не будем: технологии модные, но абсолютно маргинальные.На данный момент на github вот такая статистика по pull request, то бишь активной разработке
1 JavaScript
2 Python
3 Java
4 PHP
5 Ruby
6 Go
7 C++
8 C#
9 C
10 TypeScriptDelphi/Pascal не вошли в первые 50, как впрочем и D, Erlang 27-й, "маргинальный" Haskell на 19-м. Swift/Rust/Objective-C это 13/14/15 места соответственно. Сдается мне, ты живешь в каком-то другом мире. Ну а в следствии такой неверной посылки твоё натягивание совы на глобус единственности С++ как компилируемого языка рассыпается как карточный домик. И это без объяснения тебе разницы между компиляторами и интерпретаторами.
>На данный момент на github вот такая статистика по pull request, то бишь активной >разработке
>1 JavaScript
>2 Python
>3 Javaкак известно, есть ложь, большая ложь, а есть статистика
Ну и о чём говорит эта выборка? О том, что самое востребованное сейчас направление --- web-разработка, нет?
веб --- это единственное направление, больше ничего не осталось?
> потому что все стабильно и отлажено.Там есть ещё немало плюшек, удобных работодателям, к примеру меньшая зависимость от левой пятки корпорации, которая любит неожиданно закрывать поддержу тех или иных проектов.
[i]а ди - "язык для всего[/i] - с чего такое мнение? для go и d в общем случае нужен runtime. оба суть компилируемые языки со схожей производительностью.
> [i]а ди - "язык для всего[/i] - с чего такое мнение? для
> go и d в общем случае нужен runtime. оба суть компилируемые
> языки со схожей производительностью.а для си или си++ runtime уже не нужен ???? или что вы под этим понимаете ?
gc в d опционален и не обязателен
[i]а для си или си++ runtime уже не нужен ????[/i] - для C скорее нет, для C++ скорее да.что я понимаю - что вот допустим что мне нужно, чтобы начать писать на С - по сути настроить MMU и сделать на asm кое-какие примитивы, аля управление потоками и прерываниями.
дальше уже можно писать на С.
что мне нужно сделать, чтобы писать на C++ - ++еще сделать runtime, который скорее прочего будет хоть и довольно прост, однако уже завязан на динамическое управление памятью.
D, ровно как и Go, в существующих схемах применения, насколько мне известно, точно также требует серьезной поддержки со стороны runtime (требует ли ОС - затрудняюсь сказать).
> [i]а для си или си++ runtime уже не нужен ????[/i] - для
> C скорее нет, для C++ скорее да.
> что я понимаю - что вот допустим что мне нужно, чтобы начать
> писать на С - по сути настроить MMU и сделать на
> asm кое-какие примитивы, аля управление потоками и прерываниями.
> дальше уже можно писать на С.вообще-то, Си изначально "маленький компилятор + библиотеки". Кому интересен Си без libc?
[i]Кому интересен Си без libc?[/i] - странная постановка вопроса.
множество людей пишут библиотеки под свои нужды.
как появился bionic?
> как появился bionic?google c..л libc у BSD.
>> как появился bionic?
> c..л
>у BSD.у.п.р.л.с.?
""All original BSD pieces carry the BSD copyright disclaimer.""
> как появился bionic?из BSD.
и что? это НЕ библиотека, а неотъемлимая часть компилятора?
>... чтобы писать на C++ - ++еще сделать runtime, который скорее прочего будет хоть и довольно прост, однако уже завязан на динамическое управление памятью.Нет. К "динамическому управлению памяью" т.н. runtime С++ не имеет никакого отношения.
бред же городите. Вы не сможете нормально использовать C++ без динамического управления памятью.докажите обратное. Вот у Вас голое железо с поднятым MMU и есть возможность писать умозаключения на С++, но нет возможности динамического управления памятью.
какой тогда от С++ толк?
в то время как имея голое железо с поднятым MMU используя С, можете в рамках нормального использования языка написать себе динамическое управление памятью.
В огороде бузина, а в Киеве --- дядька.
>Нет. К "динамическому управлению памяью" т.н. runtime С++ не имеет никакого отношения.вызывающе неверно (внешние распределители --- особый разговор).
> а для си или си++ runtime уже не нужен ???? или что
> вы под этим понимаете ?
> gc в d опционален и не обязателенДля плюсов и С есть два типа окружения: hosted и freestanding. Для чистого С это прям официально в стандарте закреплено, плюсовый стандарт, каюсь, не читал, но по жизни приходилось использовать плюсы во freestanding-режиме. В общем, freestanding - это как раз "без рантайма", т.е. ты можешь пользоваться тем и только тем, что предоставляет тебе компилятор и что ты реализовал сам. Для D такое, кажется, невозможно.
> Для плюсов и С есть два типа окружения: hosted и freestanding. ...Начались городские легенды... Поколение пепси.
для работы с bare metal С++ компилятор бахает базовое окружение в память.
целую кучу разных вещей.
>Для D такое, кажется, невозможно.возможно, но вряд-ли нужно
> [i]а ди - "язык для всего[/i] - с чего такое мнение? для
> go и d в общем случае нужен runtime. оба суть компилируемые
> языки со схожей производительностью.go заточен (!) на модель акторов и имеет очень бедные выразительные возможности за пределами это модели. Для "сетевых" задач хорош, для "любой произвольной" --- вряд ли.
D не заточен на предопределённую модель, но имеет поддержку популярных парадигм и главное, отличную поддержку метапрограммирования. Кстати, это легко позволяет писать на D в стиле Go (статьи легко гуглятся).
> go заточен (!) на модель акторовgo заточен на модель CSP, а не на модель акторов.
>go заточен на модель CSP, а не на модель акторов.открываем страницу wiki (https://ru.wikipedia.org/wiki/Go), читаем
"Модель многопоточности Go была создана на основе CSP Тони Хоара по типу предыдущих распараллеливаемых языков программирования Occam и Limbo,[4], но также присутствуют такие особенности Пи-исчисления,
как к а н а л ь н а я передача." (разрядка моя)И?
> И?Ну так вы прочитали все слова правильно, теперь осталось понять, что Go заточен под CSP, а не под модель акторов, как вы изначально утверждали. И что "канальная передача" (чтобы она не означала в головах авторов русской Вики) -- это свойство модели CSP, а не модели акторов. Поскольку в модели акторов была бы передача на базе почтовых ящиков, а не каналов.
> И го до него далеко, у го вообще ниша узкая, а ди - "язык для всего".Сколько раз я слышал про "язык для всего". Знаете, я отказываюсь верить в существование серебряной пули. Для разных задач есть разные языки.
dlangui чем-то удовлетворяет этим требованиям, правда слабо, но ведь и разработкой занимается 1 человек, а не компания как у qt
Э... Биндинги к Qt же есть, не?
> Э... Биндинги к Qt же есть, не?к сожалению, что живое -- недостаточного качества, что мёртвое --- не шевелится.
> Гугл мог взять D и сделать конфетку, убийцу Java и C#.
> Вместо этого они предпочли изобрести Го...., продвигая его админресурсом.ну да, по такой логике получается что Bell Labs "сваляли дурака" предпочтя изобрести язык Си вместо того чтобы взять язык XXXX и сделать из него конфетку, для того чтобы он стал убийцей языков YYYY и ZZZZ
>предпочтя изобрести язык Си вместо того чтобы взять язык XXXXСи делался как практичный и работающий на любом железе "переносимый ассемблер", со всеми соответствующими соглашениями и ограничениями. Прочие языки, разрабатывались как полнофункциональные среды программирования.
>Ну а у них с го ниши разные, и против рекламы гугла и его ресурсов трудно переть.У меня на работе ребята раньше сетевые демоны на D писали, потом попробовали Go. Сейчас думают на Go переходить. По крайней мере, все новые проекты на нём пишут. Говорят, что Go попроще и программы на нём получаются без зауми - починить легко.
Ниши совпадают - компилируемый язык со сборкой мусора, со встроенными типами данных вроде строк, ассоциативных массивов и т.п. D, правда, больше в сторону ООП нацелен, а Go - в сторону сопрограмм.
>У меня на работе ребята раньше сетевые демоны на D писали,забавно :)
> потом попробовали Go. Сейчас думают на Go переходить.
для частной задачи, наверное, правильно
> Поздно, нишу уже почти заняли Go и Rust.чуть менее уродливые, чем C++, но этого недостаточно, чтобы оправдать медленный код (по сравнению с C++, не надо кричать, что он быстрее жавы)
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
Удивительные тесты, где раст быстрее си идут лесом
> Удивительные тесты, где раст быстрее си идут лесома что в этом удивительного?
Авто-векторизация может дать до 1500% ускорения,
см. например https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741#c26так что для языка в котором наличие ссылки на запись, запрещает
ссылки на чтение вполне можно лучше оптимизировать, за счет
того что с aliasing намного все проще обстоит, чем в С.
Rust слегка быстрее С всего на одном тесте из 10. Или ты из тех, кто C++ от C не отличает?
> Rust слегка быстрее С всего на одном тесте из 10. Или ты
> из тех, кто C++ от C не отличает?:) А какого из C, того который скомпилирован GCC или который через LLVM прошёл ;)
Абстракции не всегда бесплатны, поэтому понятно что вылизанный C код вероятно будет быстрее Rust кода использующего доп. защиту, дающуюся языком, точно так-же понятно что на Pascal-е во встроенном ассемблере вполне себе можно написать тот же код, что будет на выходе GCC для C, вопрос цены :)
Дополнительная защита в Rust работает на стадии компиляции, а не в runtime.
> Дополнительная защита в Rust работает на стадии компиляции, а не в runtime.И в runtime - тоже.
В рантайме там работает только проверка границ массивов, которая вполне себе обходится при необходимости. Это именно про _сам язык_. Все остальные рантаймовые проверки вынесены в стандартную библиотеку.
> Rust слегка быстрее С всего на одном тесте из 10. Или ты
> из тех, кто C++ от C не отличает?Какая разница, кто быстрее --- C, C++ или Rust, если ВРЕМЯ разработки законченного проекта на Rust запросто может оказаться даже больше, чем на C++?
вы поймите, Rust принял модель "давайте оставим возможность произвольных манипуляций с памятью, но сделаем их предельно строгими и попробуйте только на минуту отвлечься".
А D --- "произвольные манипуляции с памятью возможны в случае настоятельной необходимости, за пределами хитрых случаев достаточны и удобны стандартные средства, гарантирующие разумную безопасность".
Rust для драйверов --- за, обеими руками. Для всего остального --- спасибо, есть более вкусные блюда.
>> Rust слегка быстрее С всего на одном тесте из 10. Или ты
>> из тех, кто C++ от C не отличает?
> Какая разница, кто быстрее --- C, C++ или Rust, если ВРЕМЯ разработки
> законченного проекта на Rust запросто может оказаться даже больше, чем на
> C++?
> вы поймите, Rust принял модель "давайте оставим возможность произвольных манипуляций с
> памятью, но сделаем их предельно строгими и попробуйте только на минуту
> отвлечься".Бред какой-то, если мы не говорим об unsafe, то в Rust все контролирует компилятор,
отвлекся ты, не отвлекся, твоя программа не скомпилируется пока ты
нормально с памятью не станешь работать.да за попытками скомпилировать программму, программисты на Rust проведут
больше времени, чем те кто программируют на C++, зато они намного
меньше времени проведут за отладкой.
> А D --- "произвольные манипуляции с памятью возможны в случае настоятельной необходимости,
> за пределами хитрых случаев достаточны и удобны стандартные средства, гарантирующие разумную
> безопасность".В rust точно так же
> Бред какой-то, если мы не говорим об unsafe, то в Rust все контролирует компилятор,какая разница, кто контролирует: изначально, текст пишет человек
> да за попытками скомпилировать программму, программисты на Rust проведут
больше времени,
вот именно! О том и речь.
>чем те кто программируют на C++, зато они намного меньше времени проведут за отладкой.
Это не факт. Rust не гарантирует логическую правильность действий в программе, только правильность задекларированных операций в памяти. Не факт, что внесение дополнительных спецификаций (владения...) не внесёт дополнительной, не нужной путаницы.
а) Синтетика сocёт
б) даже по приведённым тестам - раст в 70% случаев проигрывает
> б) даже по приведённым тестам - раст в 70% случаев проигрываетТам по ссылке 10 тестов. В пяти выигрывает rust в других пяти плюсы. Как ни крути, а 5 из 10 это 50%, но не 70%
> а) Синтетика сocёт
У очень ценного мнения ниасиливших арифметику?
>> б) даже по приведённым тестам - раст в 70% случаев проигрывает
> Там по ссылке 10 тестов. В пяти выигрывает rust в других пяти
> плюсы. Как ни крути, а 5 из 10 это 50%, но не 70%Тогда уж 60%. spectral-norm - ничья, даром что Rust жирным выделен.
Я смотрю с арифметикой у многих проблемы. Если даже засчитать там ничью, хотя по cpu времени таки выигрывает rust, то это будет 55%(C++)/45%(rust) или 50%(C++)/40%(rust)/10%(ничья), но 60% не будет. При этом в fasta также можно засчитать ничью, что опять вернет к паритету по скорости(но не памяти)
angra, мне вообще-то плевать на оба языка, так что округляйте в любую приятную вам сторону!Вообще, имхо все эти бенчмарки - дурацкое занятие. Серебряной пули нет: для получения максимальной производительности при минимуме усилий языки надо комбинировать. Потому что для одних задач лучше один язык, для других - другой.
Узкая специализация - это то, чего хотят корпорации, потому что им выгодно иметь заменяемого сотрудника. Хорошему разработчику это не к лицу. :)
> Поздно, нишу уже почти заняли Go и Rust. Лет бы пять назад
> поменяли лицензию и всё было бы по другому, а если сразу
> бы под свободной лицензией выпустили мир мог бы поменяться.Ну с пересечением ниш у C/C++, D, Rust и Go непонятки.
В Rust и C/C++ это одна ниша - без GC,
Go и D другая - с GC,или D может и без GC нормально работать,
если да, то как у него при этом memory managment работает?
Как можно приравнивать Go/Rust до нормального ООП языка? Вы издеваетесь? Единственная альтернатива С++ - D, Go это игрушка для питонщиков, Rust вообще не понятно зачем, ИМХО (упасибоже от дискуссии ни о чем)
Нормальный ООП язык - это Java или Python? Потому что C++ нормальным с большого бодуна не назовёшь, особенно старые редакции.Rust - замена C с меньшими возможностями по оставлению бэкдоров для АНБ.
> Нормальный ООП язык - это Java или Python? Потому что C++ нормальным
> с большого бодуна не назовёшь, особенно старые редакции.Ну С++ все таки ООП язык, как не крути :) Да Java продвинутей, как и D, по Python у меня экспертизы нормальной нет в плане ООП.
> Rust - замена C, как и в плане популярности, поддержки, библиотек, так и в плане синтаксиса.
А вот тут как раз Go как по мне лучшая замена C.
В плане GC - у D есть @nogc, тогда все ручками чистишь как в C++.
>В плане GC - у D есть @nogc, тогда все ручками чистишь как в C++.... и не юзаешь стд либ, и всё что с GC :-\ Счассььтя то какое !
В дузло этот ваш Ды - его какие то осьминоги делали, за более чем 15 лет не взлетел, а сейчас 2\3 его фишечек уже в стд. С++ включено ...
>по Python у меня экспертизы нормальной нет в плане ООП.Выражайтесь по-русски. Экспертиза - это анализ, который делают эксперты. А то что вы хотели сказать называется по-русски компетенцией, опытом, квалификацией, профессионализмом.
>Как можно приравнивать Go/Rust до нормального ООП языка? Вы издеваетесь? Единственная альтернатива С++ - DНо вообще никакого нормального ООП нет, не в C++ (и если D наследует семантику
C++, то и в D).Должна быть как в smalltalk посылка сообщений, а не вызов методов напрямую.
Так что скорее в Go с duck typing что-то похожее на ООП, чем в C++/D
> Должна быть как в smalltalk посылка сообщений, а не вызов методов напрямую.
> Так что скорее в Go с duck typing что-то похожее на ООП,
> чем в C++/Dпринципы ООП напомнить? или сам нагуглишь?
В какое слово вторя буква О в этом вашем ООП разворачивается напомнить? "или сам нагуглишь?"
Не надо надувать шёки, лопнешь :)
>Должна быть как в smalltalk посылка сообщений, а не вызов методов напрямую.не путай сладкое с мягким.
>Так что скорее в Go с duck typing что-то похожее на ООП, чем в C++/D
Во-первых, тебе тогда в первую голову смотреть в сторону Objective C, там уж с сообщениями через селектор и следовательно, динамизмом, всё нормально.
Во-вторых, лучше бы познакомиться с предметом обсуждения поближе. Кстати, утиная типизация в D используется в полный рост.
> В Rust и C/C++ это одна ниша - без GC,
> Go и D другая - с GC,не совсем.
Rust претендует на предельную строгость, Go заточен на модель акторов (да-да, но не сейчас :) Управление памятью, это вторично.> или D может и без GC нормально работать,
скажем так, уже сейчас негативное влияние сборщика мусора, буде в конкретном проекте оно заметно, может быть доведено практически до нуля (см @nogc). И работы в этом направлении ведутся.
>скажем так, уже сейчас негативное влияние сборщика мусора, буде в конкретном проекте оно заметно, может быть доведено практически до нуля (см @nogc). И работы в этом направлении ведутся.Уже 15 лет ведутся. Другие Ёзыги познали взлёт и падение за этот срок :-) Дя - взлётов не имел, и не поимеет. Ибо не нужен уже. 15 лет назад - был альтернативой плюсам. Сейчас в плюсах почти все его фишки и так есть :-)))
По поводу GC. Лучший на рынке - уж нравится вам это или нет - у Java. И даже с таким замечательным и вылизанным - возникают проблемы. 5 лет назад присутствовал при решении одних мощнейших телекомовцев о переписывании кой чего на назад на плюсы, ибо GC в кластерке дёргался непредсказуемо и аж на пол часа 8-\ Ни голубые, ни сановцы (которые прямо в dc жили) - так и не помогли.
>Уже 15 лет ведутся. Другие Ёзыги познали взлёт и падение за этот срок :-)10, если считать от первой более- менее стабильной версии.
D пришёл на очень плотно заселённую площадку, в "отличие от".
> Ибо не нужен уже.
Если тебе не нужен, значит, ну нужен. Говорить тут не о чем, как и принимать участие в дискуссиях.
"Когда никто уже не ждал".Хорошая новость, если бы не опоздала, лет на 25.
> Хорошая новость, если бы не опоздала, лет на 25.На самом деле ИТ настолько инертен, что я не вижу, куда мог "опоздать" Ди. Сипиписники продолжают тянуть своё легаси гуано. Линукс - его новости 10-летней давности НИЧЕМ не отличаются от сегодняшних. Кругом всё те же "морды к базам", опердни, всякие поделки.
Так что если бы у мозиллы были бы мозги, она б давно перешла на Ди и постепенно заменяла всё линуксовое убожество на адекватные приложения. А там глядишь - и ядро б переписали!
Собсно, xomb (https://github.com/xomboverlord/xomb/tree/unborn) и есть "ОС на D".
ты не волнуйся! А лучше съешь этих хрустящих булок!
Точно! Типа :... это не к нам! Это вам теперь в Apache Foundation надыть! :-)))))
Им что не сказали, что сейчас в тренде Rust?
Сколько вакансий есть?
> Сколько вакансий есть?а на D в 250 раз меньше ?
>> Сколько вакансий есть?
> а на D в 250 раз меньше ?Вы бы глянули сколько вакансий на мой любимый Ocaml. В России их в +inf раз меньше, чем на Rust! :)
Догадываюсь, что это относится к функциональному программированию вообще.
> Догадываюсь, что это относится к функциональному программированию вообще.Казус в том, что Ocaml не чисто функциональный. Он тем и хорош, что в случае нужды позволяет программировать императивно *легко*. Это не какой-нибудь Haskell, где ради этого надо превращать ужа в ежа.
>> Сколько вакансий есть?
> а на D в 250 раз меньше ?На D и C и R и другие названия до 3-х букв искать неудобно :) Завели бы в utf новые символы для них ;)
> На D и C и R и другие названия до 3-х букв искать неудобно :)ищи dlang, golang... :0
> Сколько вакансий есть?У меня в компании сейчас back end на Java/PHP, но один проектик скоро запустим на D, если норм все будет, будем обучать студентов, ибо толку от вакансий если D-специалистов в Киеве нет
А где статистику глянуть, что раст в тренде?
раст??? Го - да, в тренде более-менее. А раста, может, пару проектов найти известных можно. В корпоративном сегменте, кстати (так уж вышло, что я к нему ближе) пока ни раст, ни го, ни свифт всерьёз не рассматриваются. Джава, шарп, джаваскрипт, кресты, PHP, кое-где - питон. Это плюс-минус в порядке убывания популярности.
> Джава, шарп, джаваскриптВы ведь большая корпорация занимающаяся разработкой потоковых кодировщиков в телекоме?
> Им что не сказали, что сейчас в тренде Rust?В тренде всегда были мозги, Раст поэтому даже рядом не стоял.
Ещё бы Watcom C/C++ открыли, а то тоже полуоткрыт. Код есть (http://www.openwatcom.org/), но может использоваться только в некоммерческих целях. А такой был компилятор....
Медленный, несовместимый и генерящий гoвнокод?
Вы уверены? На моей памяти (~2003-2005), watcom был один из лучших компиляторов своего времени.
Только время то ушло, и железо здорово поменялось...
Согласен. Тогда он был единственным компилятором, на то время, который поддерживал external шаблоны, если я не путаю...
> Вы уверены? На моей памяти (~2003-2005), watcom был один из лучших компиляторов
> своего времени.Не для C++. Потом они немного подергались, не потянули реализацию современного (на тот момент) C++ (т.е. то, что уже через CFront проблемно сделать) и побежали создавать D с большим театром и поэтессами.
Чо? Мы в своё время специально Ватком использовали в эмбеддовке, потому что он на тот момент самый лучший код генерил. А несовместим он был настолько же, насколько были несовместимы между собой все остальные компиляторы.
Между тем тихо и незаметно для аналитиков опеннета swift пробирается на linux/android.
Лучше чем Java
Java прекрасна
Как скажешь.
Потому, что она ж как заколдованная царевна :)
Она калечит психику. Судя по местным жабистам.
Тихо и незаметно - потому что его никто не ждет и всем покакать?
> Между тем тихо и незаметно для аналитиков опеннета swift пробирается на linux/android.Свифт - точно не игрок, поверьте. Он как "котлин" в мире Жабы - всего лишь "исправление ошибок" на давно ушедшем поезде.
Считаю, компилятор D представляется лучшим решением для системного компилятора, чем LLVM/Clang, при условии, что он не такой сложный и объёмный.
> Считаю, компилятор D представляется лучшим решением для системного компилятора, чем LLVM/Clang,Они ж для разных языков, Изен. )
> Они ж для разных языков, Изен. )"Изен" не писать, "Изен" читатель.
>> Считаю, компилятор D представляется лучшим решением для системного компилятора, чем LLVM/Clang,
> Они ж для разных языков, Изен. )Ну и что. Пусть напишут ОС на D. Есть неустранимые причины не делать этого?
> Ну и что. Пусть напишут ОС на D. Есть неустранимые причины не
> делать этого?Типичная "мысль" идиота: "вижу цель, не вижу препятствий".
Смени шаблоны.
> Ну и что. Пусть напишут ОС на D. Есть неустранимые причины не делать этого?Есть одна: Время.
> Есть одна: Время.Да просто никто не будет этим заниматься. Есть жирное непонятное ядро, кое-как поддерживаемое на плаву корпорациями, окружение ядра, монструозный компилятор (даже два) и на этом можно почивать как на лаврах. Новым операционкам, да, понадобятся другие инструменты и, возможно, языки — для лучшего обслуживания заданной функциональности. Но ведь на D легче перевести код с C, чем писать его заново. Так что, я считаю, это шанс для легаси-кода, и идей в нём оформленных, продолжить существование. Вопрос: кто этим займётся?
> Есть жирное непонятное ядро
> Но ведь на D легче перевести код с C, чем писать его зановоПредлагаете транслировать C в D? Танцев много, а профит не ясен.
Изен, ты лучше на заданный вопрос ответь: зачем тратить время на новое ядро, когда уже есть готовые Linux и BSD? Потому что если ты хочешь добиться повышенной надёжности за счёт новых фишек языка, то трансляция - не твой вариант. А если с нуля писать, то твой основной враг - Время. Столько времени ни у кого не попросту нет.
>> Есть жирное непонятное ядро
>> Но ведь на D легче перевести код с C, чем писать его заново
> Предлагаете транслировать C в D? Танцев много, а профит не ясен.
> Изен, ты лучше на заданный вопрос ответь: зачем тратить время на новое
> ядро, когда уже есть готовые Linux и BSD? Потому что если
> ты хочешь добиться повышенной надёжности за счёт новых фишек языка, то
> трансляция - не твой вариант. А если с нуля писать, то
> твой основной враг - Время. Столько времени ни у кого не попросту нет.Необязательно нести в новое ядро унаследованные идеи и обеспечивать прямую обратную совместимость. Для старых приложений необходимо и достаточно реализовать эмуляцию по типу Wine или syscalls (linuxulator), транслятор бинарного кода. Сформировать список востребованых системных вызовов и к открытым API системных библиотек на основе обработки "больших данных" существующих Open Source-проектов выглядит не такой уж неосуществимой целью. Wine, qemu и linuxulator как-то ведь работают.
Фантазёр ты, Изен. Как будто нам ядра BSD не хватает, так тебе ещё одно на D подавай, слепленное аналогичным образом. И всё-таки "зачем тратить на это время" - это ты так и не прояснил. "откуда взять на это время" - тоже. Тьфу.
https://www.opennet.ru/opennews/art.shtml?num=44666
> Ну и что. Пусть напишут ОС на D. Есть неустранимые причины не
> делать этого?изя, открой уже для себя волшебный сайт: google.com. он, например, может рассказать тебе про PowerNex. я понимаю, что у гугеля слишком сложный интерфейс, ты не разберёшься — ну так у тебя же есть соседи, у которых дети лет от пяти? так попроси, чтобы ребёнок уделил тебе пять минут времени — он всё тебе сделает.
usira, зачем я буду открывать какой-то сайт, если я думаю сам и не нуждаюсь в готовых ответах?
Не, ваше ядро он не скомпилит.
> Считаю, компилятор D представляется лучшим решением для системного компилятора, чем LLVM/Clang,Полностью поддерживаю, коллега! :) Ди настолько рванул вперёд от С++, что непонятно, что останавливает людей от замены таймбомб из С++ на адекватные Ди программы.
> Полностью поддерживаю, коллега! :)Кому и иЗень - коллега.
Кто видел вакансии "разработчик на D" ?
>Кто видел вакансии "разработчик на D" ?кто 15 лет назад видел вакансии "разработчик Python" ?
15 лет назад питон только появился, D немного позже, но тоже очень давно
> 15 лет назад питон только появилсяА не в 1991 году?
> , D немного позже, но тоже очень давно
"Немного" это не через 10 лет?
> 15 лет назад питон только появилсяНет ты.
>15 лет назад питон только появился,я впервые прочитал о Питоне в "Dr Dobbs", в 1993 или 95. Это не 15 лет. и о "батарейках в комплекте" тогда и речи не было.
Только к 2000 появилась хорошая стандартная библиотека и сообщество стало достаточно активно, чтобы уже всем стало очевидно, что у Питона отличная дорога. Кстати, я начал популяризировать Питон у нас и использовать его в преподавании где-то с 99.
> D немного позже, но тоже очень давно
2007 - 1993?
Те кто устраивался работать в RedHat, например. 15 лет назад python вовсю уже использовался для скриптописательства в linux'е. Во все щели. В 2000 году, например, стратанула gentoo, в которой ключевая фича -- emerge -- это скрипт на питоне. В редхате питон использовался скромнее, в основном для написания консольных/графических утилиток конфигурации чего-нибудь там, но там было достаточно таких утилиток.python менее чем через 10 лет после старта уже успел распространиться настолько широко, что его распространение раздражало. D через 15+ лет после старта до сих пор нераспространён настолько, что столкнуться с софтом написанным на D можно только если искать специально.
>>Кто видел вакансии "разработчик на D" ?
>кто 15 лет назад видел вакансии "разработчик Python" ?В 2002-м? Я видел. Ну понятно что не в России, там в эти года вообще с вакансиями проблема была :(
> кто 15 лет назад видел вакансии "разработчик Python" ?А что - сейчас уже пишут "разработчик"?
Ох уж эта толерастия - и для питоногoвноkодеров эвфемизм придумали...
>> кто 15 лет назад видел вакансии "разработчик Python" ?
> А что - сейчас уже пишут "разработчик"?
> Ох уж эта толерастия - и для питоногoвноkодеров эвфемизм придумали...Предъявите Ваше творчество, о гуру!
> Кто видел вакансии "разработчик на D" ?тот, кто умеет писать на D и интересуется этим. понятно, что к тебе это не относится.
А я осилил C++ и пишу быстрый код и использую миллионы уже готовых библиотек, а вы и дальше занимайтесь изучением новых языков и создания для них биндингов и компилируя все это в медленный код вместо реальной работы
> А я осилил C++ и пишу быстрый код и использую миллионы уже
> готовых библиотек, а вы и дальше занимайтесь изучением новых языков и
> создания для них биндингов и компилируя все это в медленный код
> вместо реальной работыИсходники на С++ жутко медленно компилируются и связываются. Вы когда-нибудь пробовали перекомпилировать GCC, LLVM? Занимались сборкой офисного пакета OpenOffice или LibreOffice, которые написаны на С++? Так вот, они по объёму строк кода сопоставимы с Eclipse, написанной на Java, а вот время компиляции и сборки удивительным образом отличается.
> Исходники на С++ жутко медленно компилируются и связываются.
> ...
> Вы когда-нибудь пробовали перекомпилировать GCC, LLVM? Занимались сборкой офисного пакета OpenOffice или LibreOffice,Очень показательно. LLVM (про GCC не поддержу --- там вменяемо), OpenOffice, LibreOffice, --- это жирнющщие монстры. Что там авторы написали такого, что их объем на порядок превышает kernel, glibc, binutils и gcc family вместе взятые?
Qt там же: сравните объем реализации (плохой, кстати) метафоры threads из Qt с threads из стандарта на библиотеку C++.
Справедливости ради, потоки в плюсах весьма и весьма ущербны в плане функциональности. Там кроме create и join не поддерживается вообще ничего. Даже простая наколенная обертка над pthreads, накидываемая за пять минут, умеет больше. Да, оно понятно, что создателям стандарта приходилось из огромного количества фич, поддерживаемых разными платформами, выбирать существующие абсолютно везде, но приятности это не добавляет. Впрочем, я рад, что оно теперь хотя бы в таком виде было включено в стандарт, до этого и вовсе атас был полный.
> Справедливости ради, потоки в плюсах весьма и весьма ущербны в плане функциональности.
> Там кроме create и join не поддерживается вообще ничего. Даже простая
> наколенная обертка над pthreads, накидываемая за пять минут, умеет больше. Да,
> оно понятно, что создателям стандарта приходилось из огромного количества фич, поддерживаемыхОй-ёоо...
Исходники на плюсах компилируются, конечно, медленно, но примеры ты привел совершенно наркоманские. GCC вообще на чистом С написан, откуда там плюсы? ЛибреОфис - форк ОпенОфиса, так что тут одна программа вместо двух. LLVM в текущем виде сам по себе блоатварь. Он был изящен и красив, пока не мог собирать 99% реального кода. Когда же его допилили - мама, роди меня обратно, что там внутре творится.
> ...
> GCC вообще на чистом С написан, откуда там плюсы?Уже нет.
> GCC вообще на чистом С написан, откуда там плюсы?здобры мутром. https://duckduckgo.com/?q=gcc+moves+to+"c++"
> текущем виде сам по себе блоатварь. Он был изящен и красив,
> - мама, роди меня обратно, что там внутре творится.
>> GCC вообще на чистом С написан, откуда там плюсы?#> здобры мутром. https://duckduckgo.com/?q=gcc+moves+to+"C%2B%...
> Исходники на С++ жутко медленно компилируются и связываются.
> Так вот, они по объёму строк кода сопоставимы с Eclipse, написанной на Java, а вот время компиляции и сборки удивительным образом отличается.Зато после компиляции есть шанс, что программа будет летать. С Java такого шанса нет (Eclipse, да).
Походу, это у фрибсдешников и гентушников пунктик на времени сборки Либреофиса и GCC. На Ява не пробовали переписать, лiл?
> А я осилил C++ и пишу быстрый, текущий как в браузерах и жрущий память как в Qt, код и использую миллионы уже
> готовых библиотек, а вы и дальше занимайтесь изучением новых языков и
> создания для них биндингов и компилируя все это в медленный код
> вместо реальной работыfix.
Мое впечатление после 7 лет знакомства с языком - в целом, D остается игрушкой энтузиастов, и в дальнейшем ситуация серьезно не изменится, если на D не появится какая-нибудь killer-либа. Проблема в том, что D появился поздновато - все нужное уже давно написано на других языках. Остаются только разнообразные пет-проекты - и вот тут, кстати, D реально уместен и даже применяется. Был, например, проект по созданию JIT-компилятора JS. В научной среде иногда используют - например, в биоинформатике и анализе данных. Кто-то с его помощью докторские защищает. Я лично помогал одному студенту с курсовой на D. Сейчас вот, кстати, пилят BLAS/GLAS, обгоняющий по скорости многие другие реализации. Еще D иногда используют вместо Питона там, где важна производительность - мелкие утилиты, скрипты и т.д. Чем не ниша? Нормальный язык для прототипов и экспериментов, а C++ никто вытеснять и не собирался, так что хейтеры могут успокоиться.
>в целом, D остается игрушкой энтузиастов,Да. И Нет.
Постепенно ситуация дрейфует.
> и в дальнейшем ситуация серьезно не изменится, если на D не появится какая-нибудь killer-либа
вряд-ли. пока не накопится критическая масса разработчиков и соответствующая масса экосистемы, никакие замечательные разработки ничего не изменят.
> Проблема в том, что D появился поздновато - все нужное уже давно написано на других языках.
Да.
> Остаются только разнообразные пет-проекты - и вот тут, кстати, D реально уместен и даже применяется.
О чём я и пытаюсь сказать: для малых коллективов, тем более одиночек, для опенсорса --- это критически важная находка. За счёт уменьшения сроков написания и отладки.
Врунишка. 1) В мире нет миллионов библиотек на С/С++ (если не считать каждый .h файл библиотекой). 2) тебе просто не хватит жизни на изучение/использование всех их. Элементарный расчет - в году <2000 рабочих часов, х 40 лет (с 20 до 60) = 80000. Вот теоретический предел кол-ва библиотек которые ты сможешь "использовать" за свою жизнь. По 1 часу на библиотеку. Качество такого кода будет индусским. Для профессионального использования любой нетривиальной библиотеки нужно минимум 1/2 года работы с ней. Т.е. на практике предел для профи - 80 библиотек за всю жизнь и 10-20 - актуальных здесь и сейчас.
А я осилил молоток и замечательно забиваю гвозди, а вы и дальше продолжайте ковырять плоскогубцами, отвёртками и прочими гаечными ключами, вместо реальной работы.
>А я осилил C++ и пишу быстрый код и использую миллионы уже готовых библиотек, а вы и дальше занимайтесь изучением новых языковЕщё раз: время разработки на D существенно меньше, чем таковое на C++.
Питонисты часто говорят, что на Питоне пишешь со скоростью мысли. Так вот, на D это ПОЧТИ так-же и почти так-же приятно.
> Питонисты часто говорят, что на Питоне пишешь со скоростью мысли. Так вот,
> на D это ПОЧТИ так-же и почти так-же приятно.обычно приятней. потому что строгая типизация роялит. это говорит arisu, который много лет считал строгую типизацию фигнёй для старпёров, а потом сам постарел, обленился, и теперь предпочитает, чтобы всякую фигню за него ловил компилятор, а не рантайм.
> обычно приятней. потому что строгая типизация роялит. это говорит arisuAlso sprach Zarathustra :)
Всё хорошо на своём месте. Нестрогая / динамическая типизация хороша для прототипирования, да иногда и альтернативы ей нет.
В любом случае, в D строгая типизация весьма ненавязчива!
> обычно приятней. потому что строгая типизация роялит. это говорит arisu, который много
> лет считал строгую типизацию фигнёй для старпёров, а потом сам постарел,
> обленился, и теперь предпочитает, чтобы всякую фигню за него ловил компилятор,
> а не рантайм.Неужто начал работать с алгебраическими типами данных и Хиндли-Милнером?
А в чём фишка, я никак понять не могу? Зачем нужен этот "официальный", "эталонный" компилятор, если есть фронтенды к gcc и llvm? Чем он лучше? Только скоростью компиляции? Я не верю в то, что он сможет конкурировать с llvm и gcc в качестве оптимизации кода, а скорость... это конечно приятно, когда компилятор реактивный, но приятно это разве что в процессе разработки программы, когда её многократно приходится пересобирать. Но даже для этого, в общем, скорость не носит какой-то первостепенной важности.Зачем вообще было пляски плясать вокруг закрытых сорцов? Давно бы положили на них болт и сделали бы эталонным фронтенд к llvm. И пускай бы symantec дальше владела бы никому не нужным кодом.
Или фронтенды эти не умеют половину фичей языка, отстают лет на десять в развитии, и пр.?
Короче, если кто в теме, проясните, плз, ситуацию.
Проще поддерживать то, что есть. Смена бэкенда - это море новых багов, а от DMD все привыкли ожидать какой-никакой стабильности. Или придется поддерживать две ветки - со старым бэкендом и LLVM, но существование LDC лишает эту затею смысла.
Вопрос немного в другом: зачем вообще нужен этот DMD, если есть LDC? Зачем возиться с фронтендом, с бэкендом, когда есть готовый фронтенд для llvm, а головные боли с бэкендами -- это проблемы разработчиков llvm. Можно же пилить фронтенд, не парясь о бэкендах. Или если аллергия на llvm, то можно пилить фронтенд к gcc, и хоть это будет сложнее, чем с llvm, но всё же проще, чем тянуть и фронтенд, и бекенд.Я могу предположить, что дело в скорости компиляции, но это мне не совсем понятно, я не думаю, что скорость компиляции стоит всех этих заморочек с поддержкой компилятора. Я могу предположить идейную составляющую: компилятор должен компилировать сам себя, иначе он не компилятор, а детская игрушка. Но эта идейность, сама по себе, больше похожа на детский сад, чем на причины тянуть разработку компилятора.
Может есть ещё какие-нибудь предположения?
Вся эта новость для меня выглядит как: symantec потерял надежду на то, что D взлетит и на нём можно будет как-то заработать, и поэтому открыл сорцы -- а вдруг от этого чего-нибудь изменится. И я никак не могу понять, что именно может измениться? Кому какое дело до DMD, если есть фронтенды к llvm и gcc, которые оптимизируют так, как DMD никогда не сможет?
LDC активно пилят не так уж давно - думаю, высока вероятность, что со временем он стабилизируется настолько, чтобы вытеснить DMD. В сообществе эта идея не раз высказывалась - реальных аргументов против такой перспективы вроде бы нет (ну разве что кроме пресловутой быстрой компиляции, которая подается как одна из главных фишек D - хз насколько она реально важна, особенно при инкрементальной сборке, но для кого-то наверняка критична).
Что касается бутстраппинга: фронтенд уже переписали на D - могут и бэкенд переписать, все к этому и идет.
А Symantec к D, насколько я знаю, никакого отношения не имеет, денег в язык не вкладывала, и правами на бэкенд владела по формальной причине: для создания DMD Брайт просто взял бэкенд из своего компилятора C++, который писал для Symantec. Как-то так.
dmd - это эталон. Появилось в языке = появилось в dmd. Ну, не говоря о том, что dmd сам написан на d.
> dmd - это эталон. Появилось в языке = появилось в dmd. Ну,
> не говоря о том, что dmd сам написан на d.Фронтенд в LDC тоже дишный. Только вот не в том суть, а в том, что кто-то тормозит фрагментацией свой же проект просто потому... что не хочет выкидывать свою родную игрушку, в которой в каждом релизе фиксят какие-то проблемы с кодогенерацией, а IDE или инструментов для неё хотя бы уровня того же что racer у раста — просто нету.
А ничего, что dmd существовал считай всегда, в отличие от ldc? Это кто еще "тормозит фрагментацией".
>а IDE или инструментов для неё хотя бы уровня того же что racer у раста — просто нету.Это шутка такая? dcd для автодополнения существует сто лет как, IDE тоже завались. И даже, в отличия от плагинов и редакторов, существует IDE на самом ди на дишном графическом тулките.
Очевидно что DMD можно было просто выкинуть и не тратить время на него — он генерирует просто убогий код и все тут, какие соревнования на одном поле с плюсами и растами. Вот например из последнего релиза — http://dlang.org/changelog/2.074.0.html#bugfix-list треть исправлений в кодогенераторе. Нахрена? Ну, Брайту нравится компиляторы вылизывать, он сам признавался на прошлой или позапрошлой dconf.
>dcd для автодополнения существует сто лет какСразу видно человека который садится воевать в комментах ни разу не пробовав ничего написать на сабже. Ну иди, посмотри как этот DCD работает. Он автокомплит с трудом для стандартной библиотеки вывозит, я молчу про сторонние и вообще навигацию.
>IDE тоже завалисьОна была всего одна единственная нормальная — в виде плагина для MD. Сейчас он сдох с обновлениями MD. Плагин для эклипса всегда был тормозным гуаном, но раньше хоть как-то работал, только вот он тоже дохлый и не обновляется, у него уже не всегда заводится даже парсер. Не то что плагин для студии или идеи — у одной просто подсветка синтаксиса и дебаггер, у второй просто подсветка синтаксиса и... DCD который хрен прикрутишь.
> существует IDE на самом ди на дишном графическом тулките.Ты её видел-то хоть? Сделай как нибудь dub fetch dlangide и собери — посмотри что это. Там есть: блокнот с подсветкой синтаксиса и чудовищными шрифтами. Все.
> Это шутка такая? dcd для автодополнения существует сто лет как, IDE тоже
> завались. И даже, в отличия от плагинов и редакторов, существует IDE
> на самом ди на дишном графическом тулките.подскажите названия, желательно IDE уровня ИДЕИ
Ммм, идея - достаточно уровня идеи?
> А ничего, что dmd существовал считай всегда, в отличие от ldc? Это
> кто еще "тормозит фрагментацией".
>>а IDE или инструментов для неё хотя бы уровня того же что racer у раста — просто нету.
> Это шутка такая? dcd для автодополнения существует сто лет как, IDE тожеК сожалению, dcd штука довольно убогая.
Из ide хвалят только плагин для VC++, что довольно странно.
Плагины для эклипса у меня нормально не заводились.> существует IDE на самом ди на дишном графическом тулките.
на настоящий момент, это недоразумение.
Интересная IDE (убогая и примитивная, но компактная, поддерживает автодополнение и навигацию про коду) --- coedit, делает один автор на Lazarus.
>на настоящий момент, это недоразумение.Ее пилит один разработчик, и она существует - может год-два от силы. Вспомните как выглядел софт на qt2/qt3, какой-нибудь qdevelop бородатых времен. Удобно сравнивать с выверенным софтом, который существует десятилетия (не говоря о том, в который были вложены миллиарды)
>К сожалению, dcd штука довольно убогая.
Но она есть. Линукс в 90х тоже был штука убогая, и потребовался очень долгий путь развития. Штука хоть какая-то есть, а теперь эту штуку надо развивать и улучшать.
>>на настоящий момент, это недоразумение.
> Ее пилит один разработчик, и она существует - может год-два от силы.
> Штука хоть какая-то есть, а теперь эту
> штуку надо развивать и улучшать.Да, разумеется, кто спорит?
> Но она есть. Линукс в 90х тоже был штука убогая, и потребовался
> очень долгий путь развития.И замечу, потребовались колоссальные(!) средства, влитые IBM в начале 2000-ых.
Увы.