Создание D foundation, организации, которая будет заниматься развитием языка

gcc и clang умели это

Но это не было частью языка.

Вот только надо это для крайне узкого круга задач.

Такого уж узкого?

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

Но это не было частью языка.

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

Такого уж узкого?

Ровно такого же узкого, как и вероятность встретить подобное в каком-нибудь серьезном проекте.

Ровно такого же узкого, как и вероятность встретить подобное в каком-нибудь серьезном проекте.

Даже https://github.com/rust-lang/regex использует их для компиляции регулярок.

Ты видимо так и не понял, что раст и шланг ведут себя тут одинаково:

<anon>:11:24: 4:34 error: the trait `core::cmp::PartialEq<[i32; 2]>` is not implemented for the type `[_; 3]` [E0277]
(internal compiler error: unprintable span)
<anon>:1:1: 7:2 note: in expansion of eq!
<anon>:11:20: 11:39 note: expansion site
note: in expansion of format_args!
<std macros>:2:25: 2:56 note: expansion site
<std macros>:1:1: 2:62 note: in expansion of print!
<std macros>:3:1: 3:54 note: expansion site
<std macros>:1:1: 3:58 note: in expansion of println!
<anon>:11:5: 11:41 note: expansion site

Только https://github.com/rust-lang/regex использует их для компиляции регулярок.

Починено.

Ты видимо так и не понял, что раст и шланг ведут себя тут одинаково:

Конечно, абсолютно одинаково, не волнуйся.

(internal compiler error: unprintable span)

LOOOOL

Модулей в С++ до сих пор нет и непонятно
Менеджера пакетов нет

жабозомби так и тянут свои поганые лапищи к нармальному ЯП.

В 2015 до сих пор надо с памятью руками работать.
bash: segmentation fault.

программисты на жабе не могут писать программы по человечески, это всем известно.

самый прикол что в жабище надо про память думать. есть такая библиотека - box2d. она написана на языке программирования. но обжабаные её переписали на жабе, и в описании рассказали, как им пришлось ухищряться, чтоб не выделять память лишний раз. вот где страдалово и попадалово. а этим уродам ведь еще и ресурсы приходится в ручную освобождать.

не могут писать программы по человечески

Этот универсальный аргумент сишников и плюсовиков. Но что самое характерное, никто за полвека существования этих языков «по человечески» писать так и не научился.

но обжабаные её переписали на жабе, и в описании рассказали, как им пришлось ухищряться, чтоб не выделять память лишний раз.

А где можно почитать про эту драму?

Этот универсальный аргумент сишников и плюсовиков.

Не стоит обобщать. многие сишники и плюсовики прекрасно понимают минусы своих языков и плюсы чужих.

Но что самое характерное, никто за полвека существования этих языков «по человечески» писать так и не научился.

(картинка Линуса с пальцем)

программисты на жабе не могут писать программы по человечески, это всем известно.

Это же ты работал над проприетарным драйвером AMD? Из-за которого иксы сегфолтятся. Программисты на жабе не могут, конечно.

У меня тут родилась мысль:
на D пробовал писать, изучал его 3 года тому назад (как и на Go). И только сейчас на лоре идёт активное обсуждение этого языка. Почему?

По результату оказалось, что бинарник на Go стартует быстрее и раньше заканчивает работу.

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

Ты еще скажи, что файлы hs_err_pid в жизни не видел. Кроме того Java-программа, которая на старте выматерилась на два экрана и сдохла, ничем не лучше С-программы, которая на старте же выпадет в coredump. И тот и другой вариант неюзабелен.

D
только сейчас на лоре идёт активное обсуждение этого языка

По факту тут обсуждают rust, C, C++ и Java.

пусть на D запилит хорошую IDE для D, покажет всяким эклипсам с идеями.

Да глупость. Нужен просто отличный плагин для idea/clion. Чтобы D как родной был, с пакетным менеджером/системой сборки dub, и т.д. В принципе, дебаг можно выполнять и без брейкпоинтов IDE - там качественная отладочная информация.

По факту тут обсуждают rust, C, C++ и Java.

Ну дык, по меньшей мере три из них являются самой реальной альтернативой D.

По крайней мере я не раз был этому свидетелем.

Ну у меня другой опыт. Да и аргумент очень напоминает аргументы, скажем, противников макросов - «фича слишком мощная, значит будут проблемы».

Мне тоже нравится «строгость» растовых дженериков, но сложно спорить с тем, что в ряде случаев приходится писать больше кода. Ведь с шаблонами достаточно, чтобы нужные методы были. А в расте придётся самому реализовывать трейты, если автор типа об этом не позаботился, чтобы передать его в дженерик.

Как и плюсовое ооп - пускай в плюсах и остается.

Как будто в плюсах какое-то особенное, чисто плюсовое, ООП.

Уникальность C++ в том, что в нем нет различий между value и reference types

Чем в этом плане раст отличается?

Отсюда и таки шаблоны с такими возможностями.

Не думаю, что это связано.

Но я уверен, что ровно та же логика, только реализованная на нормальных макросах ржавчины, nim`а или чего подобного

Ну ты всё-таки не смешивай макросы и шаблоны. (Нормальные) макросы - это более мощный инструмент всё-таки и да, в плюсах его нет, вот и обходятся чем могут.

Но вообще растовые макросы нефига не бегло читаются. И официальный мануал явно говорит, что это мощная штука и отлаживать их тоже нелегко.

Чем в этом плане раст отличается?

Я уже говорил выше по треду: Rust — это пока хрен знает что. И во что он трансформируется, если на нем начнет писать куча народу, никто не может пока сказать. Тут нужно выждать несколько лет.

И это еще ничего, в вашем коде даже нет ни одного ::

А чем :: тебя пугают? Чем точка сильно лучше?

Я уже говорил выше по треду: Rust — это пока хрен знает что. И во что он трансформируется, если на нем начнет писать куча народу, никто не может пока сказать.

Думаешь введут value/eference типы? Готов спорить, что нет.

Но вообще меня удивило такое противопоставление и связь с шаблонами.

А как по твоему надо было изменить синтаксис сопоставления с образцом в макросах? Я согласен, что оно несколько странно выглядит поначалу, но я вот чего-то однозначно более удачного не могу придумать.

Мне, если честно, лисповые макросы и то проще, чем растовые давались.

В немерле они однозначно более приятно выглядят, чем в расте. Паттерн матчин тоже присутствует.

Думаешь введут value/eference типы?

Нет, думаю, что скорее через несколько лет Rust уйдет в небытие и о нем будут вспоминать как о каком-нибудь cyclone :)

Но вообще меня удивило такое противопоставление и связь с шаблонами.

В C++ если шаблон получает параметр T, то внутри шаблона разработчик спокойно может написать создание объекта типа T. Что-то вроде:

template< typename T > sample() {
  T tmp;
  ...
}

В Java и C#, насколько я помню, такие фокусы не проходят.

В немерле они однозначно более приятно выглядят, чем в расте.

Я бы даже сказал - шикарно. Те же <[]> вообще не режут глаз и не мешают читать, даже помогают.

Вообще, как ни странно, чаще встречаюсь с одобрением D со стороны питонистов, чем C++ников.

Дык, большинство плюсовиков считают главным приоритетом скорость (пусть и потенциальную). D с GC по умолчанию несколько смещает акценты. Облегчённое управление памятью, опять же, преимуществом считать не привыкли.

Остальные плюсы лежат в области метапрограммирования, а этим занимаются далеко не все. Тем более, что и тут D далеко не лучший вариант.

Я бы даже сказал - шикарно.

Ага, да и в остальном код похож на «обычный». В расте же - макросы как совсем другой язык выглядят. Понятное дело, что немерле имеет популярность, пожалуй, даже меньшую чем раст, но всё равно могли бы поактивнее на другие языки смотреть.

немерле

Кстати, а он живой еще? А то тут:

https://github.com/rsdn/nemerle/downloads

после 2012-го тишина. Хочется потыкать в него, даже несмотря на платформу, но имеет ли смысл.

и о нем будут вспоминать как о каком-нибудь cyclone :)

Как по мне, то след он явно больший оставит, даже если всё-таки умрёт. Но я всё-таки думаю, что популярность будет немного больше, чем у D, если только чего-то нового не появится.

то внутри шаблона разработчик спокойно может написать создание объекта типа T. Что-то вроде:

Ну скажем, совсем не «спокойно» - Т может быть не «default constructible». Да и std::decay не зря придумали, так что нюансов хватает.

Хотя мне тоже больше нравится ссылочность/константность на уровне «экземпляров», а не типов.

Кстати, а он живой еще?

Я на немерле не пишу, если что. Но вообще живой. Сейчас они нитру пилят, потом хотят сделать немерле 2 на ней.

Я на немерле не пишу, если что. Но вообще живой. Сейчас они нитру пилят, потом хотят сделать немерле 2 на ней.

Спасибо, значит обязательно ознакомлюсь.

жабозомби так и тянут свои поганые лапищи к нармальному ЯП.
тред о D

но при чем здесь жаба? Но раз уж вспомнили по нее, то давайте сравним количество и качество инструментов для работы с кодом в Java и в C++. Думается, результат будет не в пользу последнего. И одна из причин - нифига не удобная для парсинга система хедеров, да еще препроцессор, кусок реликтового Г.

По результату оказалось, что бинарник на Go стартует быстрее и раньше заканчивает работу.

Хоть расскажите, что и как замеряли.

Да ничем;; собственно:: Просто как-то визуально меньше мусора;; лаконичнее;; что-ли::

А можно поинтересоваться, где метапрограммирование намного лучше чем в D?

Но вообще живой.

Welcome to the club.

Я всего лишь культурно ем любимый кактус в компании единомышленников, и как будто никого особо не агитирую присоединяться. Пара новостей на лоре - это не агитация.

Главное энтузиазм не растеряй. Я хоть и на D переходить не собираюсь, но узнать новое о языке интересно. Да и языку оно полезно - больше народу услышит, может кто-то заинтересуется.

Да ничем;; собственно:: Просто как-то визуально меньше мусора;; лаконичнее;; что-ли::

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

Если разные сущности выглядят иначе, то это бывает удобно.

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

А вы таки что-то имеет против однобуквенных переменных?

А можно поинтересоваться, где метапрограммирование намного лучше чем в D?

Обязательно намного? Ну а вообще в D, в основном, всего-лишь «немного» улучшенные плюсовые шаблоны, которые далеки от идеала. Ну и всякие миксины, где код тупо строками передаётся - тоже не самый лучший вариант.

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

Ну а так в расте макросы, при том, что я о не лучше мнения, всё-таки отдельный предназначенный как раз для этого инструмент. Ну и, опять же, немерле - там макросы и выглядят нормально.

иксы не наша зона ответственности.

А вы таки что-то имеет против однобуквенных переменных?

+

давайте сравним количество и качество инструментов для работы с кодом в Java и в C++

сравнение Qt Creator, где можно просто работать и всё под рукой, и какой нибудь идеи будет избиением младенцев. Почему то в Qt Creator есть настройки, куда _иногда_ надо заходить раз в полгода что-то подкрутить или новый Qt добавить. А всё остальное делается прямо в окне.

А в цука идее жопорукие жопоголовые жабисты нагородили тонны менюшек, какие-то сраные панельки системы «таблица из непонятной херни», всё заныкано-переныкано-перепрятано. Полный ынтерпрайз.

Вот такой вот инструмент «работы с кодом». В Qt Creator я работаю с кодом, в идее я работаю с инструментом, который предназначен для работы с ним жопой.

бинарник на Go стартует быстрее

я думаю, что на х86-64 можно тупо на установке статически слинковать все бинарники, и линкер будет летать. Олени, не могущие в С++, вечно придумывают какие-то соревнования инвалидов, где в одной дисциплине «бег по диагонали с мусорным ведром на голове» они таки лучше.

А можно поинтересоваться, где метапрограммирование намного лучше чем в D?

Кстати о D, а там можно сделать так:

class A {
...
    A( int v );
    int foo( int a, int b ) const { return ...; }
...
};

GENERATE_C_FUNCTIONS( A );

Чтоб GENERATE_C_FUNCTIONS развернулось, например, в:

APtr A_new( void ) {...}
void A_delete( APtr a ) {...}
int A_foo( APtr a, int a, int ) {...}
...

Т.е. можно ли именно на основании «левой» декларации класса нагенерить новый код? Вот это было бы круто.

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

Как это будет на rust?

Да примерно так же, с поправкой на языковые особенности: надо явно указать, что элементы умеют сравнивать, ну и переменного количества аргументов (без макросов) нет - надо использовать или итератор или слайс.

Хотя можно и на макросах изобразить (в теме уже было), тогда будет похоже на плюсовый вариант. Но макросы лучше использовать тогда, когда без них будет заметно хуже.

Да примерно так же

Выше уже обсудили - варианта с проверкой типа (что в основном то и хотелось) так и не привели.

Выше уже обсудили - варианта с проверкой типа (что в основном то и хотелось) так и не привели.

Ну если тупо на слайсах, то так:

fn eq<T: PartialEq>(a: &[T], b: &[T]) -> bool {
    a == b
}