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

Забавно. В треде про D адепт руста пишет код на русте.

Я же честно предлагал перенести обсуждение, связанное только с ржавчиной, в другую тему)

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

Я по чужим макросам разбирался, проблем особых не помню.

• $x - метапеременная;
• $()* - сколько-то повторов выражения;
• $()+ - один и больше повторов выражения;
• $(),* - тож самое, только разделенное запятыми.

Ну и в образце для метапаременных надо указывать классы:

* ident: ident. Examples: x; foo.
* path: a qualified name. Example: T::SpecialA.
* expr: an expression. Examples: 2 + 2; if true then { 1 } else { 2 }; f(42).
* ty: a type. Examples: i32; Vec<(char, String)>; &T.
* pat: a pattern. Examples: Some(t); (17, 'a'); _.
* stmt: a single statement. Example: let x = 3.
* block: a brace-delimited sequence of statements. Example: { log(error, "hi"); return 12; }.
* item: an item. Examples: fn foo() { }; struct Bar;.
* meta: a "meta item", as found in attributes. Example: cfg(target_os = "windows").
* tt: a single token tree.

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

..Все, вроде, что надо знать на практике.

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

Ну, там макросы гораааздо теснее интегрированы с языком, к ним там другое отношение. Хм, надо будет почитать про него повнимательней. Чего-то слышал там и сям, в /r/rust точно мелькало в комментах, но слово «дотнет» тут же убило весь интерес для меня.

Ну и в образце для метапаременных надо указывать классы:

Да я мануал читал, всё это понимаю (более-менее).

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

А вот макросы - они ведь как совсем отдельный язык выглядят. Может, конечно, практики мало...

но слово «дотнет» тут же убило весь интерес для меня.

Похожая ситуация, но в плане того «как можно сделать» всё равно интересно.

И насчёт «интеграции» - разработчики языка считают, что (условно) «макросы надо применять как можно чаще». Вплоть до написания ДСЛ под каждую задачу. Не могу сказать, что полностью с ними согласен, но подозреваю, что как раз удобство применения и написания макросов сильно меняет подход. И раст тут ничего принципиально не изменил, к сожалению.

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

Так, что бы сразу избежать вопросов о неосиляторстве:

Q: What should be improved in C++ first?

A: There's really so much: compile times, better support for Generic Programming, reflection, ranges, Unicode support, etc, etc. But if I had to pick the one things that would transform the C++ world the most, I would say an easy-to-use, robust, powerful, and flexible package manager. Finding, downloading, compiling, and installing libraries — with all their dependencies at the correct versions — is just way too hard today.

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

Ну был бы свой менеджер у плюсов. Под линукс все равно нужно было бы, как и сейчас,
делать deb/rpm. Под виндой - писать инсталлятор. Так что бы это упростило? Я
понимаю с питоном, у которого своя инфраструктура, всякие там virtualenv и пр.
А тут-то нативно все. Зачем мне ещё один менеджер пакетов?

Как уже сказали, deb-rpm-msi-что-там-еще это для готового приложения и языковой менеджер пакетов к этому отношения не имеет.

ИМХО, менеджер пакетов уровня ОС вообще не должен давать пользователю возможность самому ставить библиотеки. Только приложения.

Для нативного языка.

Почему ты так акцентируешь внимание на нативности языка? Ничего принципиально не меняется.

Если нужна изоляция и независимость, то лучше уж docker.

Совсем упоролись этим своим докером, везде пихают)

Для начала хотелось бы понять, а зачем такая функциональность нужна.

Ну, вот что мне в голову приходит:

• Под, допустим, виндой родного пакетного менеджера вообще нет. Без cargo там чегото собрать было очень сложно.
• Менеджер пакетов позволяет не заниматься запихиванием всего, что плохо лежит, в стандартную библиотеку. Да, знаю что не все с этим согласны, но я вот считаю хорошей практикой.
• Повторяемость сборки на любой платформе.
• Стандартный способ организации проектов.
• Пакет, который был загружен в crates.io, не может быть оттуда удален.
• При внесении изменений в компилятор/библиотеки можно пройтись скриптом по crates.io и проверить, что ты ничего не поломал. Там, конечно, не весь написанный код, но уже кое-какая гарантия.
• Если работаешь над несколькими программами одновременно, то они легко могу зависить от разных версий одной библиотеки и это не вызовет проблем на любой системе.
• Да и вообще, зависимость твоей библиотеки от какой-то версии другой библиотеки перестает быть частью внешнего API.
• http://doc.crates.io/manifest.html#the-[features]-section (я хз как эту ссылку нормально скормить лору) - полезно бывает, вроде это не каждый менеджер пакетов уровня ОС умеет.

Иии вот кусок из обсуждения анонса cargo:

We can't rely on OS package managers to package Rust for a good developer experience.

* First of all, it's a chicken and egg problem: the OS package managers are slow to update, and they don't have much of a motivation to update without Rust uptake. But without a good package management system, Rust will have a hard time getting that uptake to begin with. Look at the situation now: Rust has been around for a while and OS package managers have little support for it. We have to take the situation into our own hands.

* Some OS package managers (most notably Homebrew) do not like language-specific packages as a matter of policy, other than for C and C++; they prefer that languages have their own package managers.

* Many developers prefer faster development than OS package managers allow for. We live in the age of GitHub, and the dead simple «push your libraries to a server for the world to use» has been extremely important for communities like Node.

* For servers, it's very important that your production machine be able to replicate the development environment precisely. This is why you need a system that can tie your software to the exact versions of your dependencies.

И насчёт «интеграции» - разработчики языка считают, что (условно) «макросы надо применять как можно чаще». Вплоть до написания ДСЛ под каждую задачу. Не могу сказать, что полностью с ними согласен, но подозреваю, что как раз удобство применения и написания макросов сильно меняет подход. И раст тут ничего принципиально не изменил, к сожалению.

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

Да я мануал читал, всё это понимаю (более-менее).

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

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

Ну хз. В теме про регулярки говорили, их я тоже не особо люблю и бегло читать/писать не умею. Вероятно, дело в отсутствии практики. Вот только немерловые макросы можно понимать просто зная язык плюс несколько дополнительных правил. Лисповые тоже, кстати. А с растом так не выйдет.

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

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

Всё-таки думаю, что макросы в расте не делали специально «более неудобными», просто так получилось. Да и «делать всё явным» - это довольно размытое понятие. Можно привести кучу примеров, где поведение будет не более «явным», чем в том же С++. Чего только плагины к компилятору стоят.

Да и если не дать этих возможностей, то люди всё равно будут переизобретать. Скажем, нет в С виртуальных функций, но это не мешает делать подобие ООП. При этом «встроенное» решение явно удобнее будет. Или взять даже «отказ» раста от исключений - постепенно появляются возможности более удобной работы с паникой. И я уверен, что рано или поздно люди будут делать (если уже не сделали) привычные try/catch на макросах - ведь всё необходимое и так уже есть, вроде. Ну и от отсутствия наследования в Серво тоже страдают и что-то там костыляют.

Опять же, у тебя типичные аргументы противника макросов. Был бы я лиспером/немерлистом - рассказал бы про «парадокс блаба». А я сам не уверен, что всюду совать макросы - это так уж здорово. Но иметь более удобный инструмент мне никогда не казалось плохим, пусть его и можно «применять неправильно».

Всё-таки думаю, что макросы в расте не делали специально «более неудобными», просто так получилось.

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

Можно привести кучу примеров, где поведение будет не более «явным», чем в том же С++.

Приведи, мне в голову не приходят сходу)

Чего только плагины к компилятору стоят.

Аналог макросов в этом плане - оно есть, но на крайний случай.

Да и если не дать этих возможностей, то люди всё равно будут переизобретать.

Это мы еще о макросах или вообще? Пытаться сделать все подряд удобным - получишь еще один C++. У языка (да и вообще любых проектов) должен быть четкий фокус.

Или взять даже «отказ» раста от исключений - постепенно появляются возможности более удобной работы с паникой. И я уверен, что рано или поздно люди будут делать (если уже не сделали) привычные try/catch на макросах - ведь всё необходимое и так уже есть, вроде.

Это меня настораживает, как не особого религиозного любителя исключений) Я бы вот хотел бы удобный флажок для rustc/Cargo.toml, который бы всю раскрутку стека отключал и просто грохал приложение если чего. Для игр больше и не надо) Вроде, кто-то там такое хотел сделать.

Ну и от отсутствия наследования в Серво тоже страдают и что-то там костыляют.

Тут нужны анонимные поля)

Опять же, у тебя типичные аргументы противника макросов. Был бы я лиспером/немерлистом - рассказал бы про «парадокс блаба». А я сам не уверен, что всюду совать макросы - это так уж здорово. Но иметь более удобный инструмент мне никогда не казалось плохим, пусть его и можно «применять неправильно».

Ок, ок. Я бы не был против, если бы macro_rules! сделали более удобными без ущерба для чего либо еще) Просто они и в текущем варианте, как по мне, совсем не так плохи, как о них в этой теме отзываются.

Как плюс слабой интеграции макросов в язык - в rust 2.0 вполне могут другую макросистему прикрутить, если будет много жалоб.

Приведи, мне в голову не приходят сходу)

Ну некоторые считают «сложным для понимания кода» даже виртуальные функции и перегрузку операторов. В расте всё это есть - вызывая метод у трейта ты (если утрировать) понятия не имеешь, что он будет делать.

Аналог макросов в этом плане - оно есть, но на крайний случай.

Но ведь есть и позволяет сделать много всякого. А «на крайний случай» - это ведь просто «рекомендации». Но почему-то в ряде случаев (типа исключений), они (и ты) считают, что рекомендаций будет недостаточно.

Это мы еще о макросах или вообще? Пытаться сделать все подряд удобным - получишь еще один C++. У языка (да и вообще любых проектов) должен быть четкий фокус.

Спорный вопрос. Всё-таки раст язык «общего назначения». Ещё не дошли руки почитать про реализацию ГЦ, на которую давали ссылку в соседней теме. Но если ГЦ позволит не заморачиваться с лайфтаймами, то писать на расте можно будет гораздо легче.

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

Это меня настораживает, как не особого религиозного любителя исключений)

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

Мне это кажется маловероятным. Исключения удобны уже в логике приложения, а библиотеки должны предоставлять выбор. Вон в плюсах с этим всё более-менее нормально. Тот же буст даёт выбор.

в rust 2.0 вполне могут другую макросистему прикрутить, если будет много жалоб.

Мне нравится как развивается язык и во многоm, действительно, всё можно подправить и допилить. Но вот как раз макросы вызывают сомнение. Если добавлять «новую макросистему», то что делать со старой? Поддерживать тоже? Такими темпами и правда можно в С++ превратиться.

Я бы вот хотел бы удобный флажок для rustc/Cargo.toml, который бы всю раскрутку стека отключал и просто грохал приложение если чего. Для игр больше и не надо)

Всё-таки вопрос - это просто чтобы упасть быстрее?

Ну и у меня всё-таки есть сомнения, что во всех играх так делают. Всё-таки как-то поддерживать надо. И удобнее, если игра крашнувшись предлагает отправить что-то разработчику, разве нет?

Да запросто. Этим мне он и нравится. Например он позволяет автоматически генерировать vertex specification для opengl на основании пользовательского типа. Можно в автомате преобразовывать пользовательский тип данных в тип данных hdf5 и обратно. И так далее. Это значительно облегчает код. Интроспекция в нем мощная, при этом язык проще чем плюсы. Я не программист, но то что могу делать на Ди, я не могу делать на плюсах. И в моих глазах этой большой плюс для Ди.

Главное, что адепты Ди не тратят свое время на пустую болтовню. Я использую Ди в работе. Зачем мне тратить свое время на описание каких-то фичей, как вот оно сделано? За это мне денег никто не заплатит. Меня он отлично устраивает для решения моих задач, не факт, что эти задачи есть у других. Зачем мне кому-то что-то доказывать? Человек, который ведется на количество постов о языке мне не интересен, а человек, которому нужен новый инструмент для решения его задач сам сможет попробовать и оценить. А если человека устраивает его текущий язык, пусть даже D и намного круче - зачем ему что-то менять?

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

Так ведь можно просто не знать, что есть что-то лучше.

Ну и больше людей пользуется языком - больше библиотек/инструментов. Так что популяризировать язык вполне полезно.