Здравствуйте, hi_octane, Вы писали:

FR>>А это не следствие нормировки графиков?
FR>>Пока я только увидел что Rust и Scala растут, остальные падают.
_>Ну да, так и есть — не-мэйнстрим программистов мало, и как только они увлекаются чем-то новым, сразу начинает проседать то во что уже наигрались.

Все-таки там нормировано к 100 пунктам, величины не абсолютные, хотя большая доля правды в том что ты пишешь есть

FR>>Ну это нормально, любой график развития это S образная кривая.
_>Для не-мэйнстрим языков так наверное даже не S, а вообще колокольчик — подъём, пик, и потом исчезновение. Что интересно — пик go, если по трендам мерять, возможно, уже позади. Может даже из-за того что rust вырос достаточно чтобы появился выбор между ним и go.

Ну тогда по эталонному шумомеру C# тоже не-мэйнстрим хотя objective-c конечно намного круче.

FR>>Весь вопрос насколько высоко заберется.
_>Да, если пробьёт уровень Ruby на пике — будет очень даже интересно посмотреть. Но внимание толпы очень динамичное — начнёт серьёзно расти rust — утонут сразу и go и scala и что-нить ещё до кучи Только, имхо, с такой неудобной обработкой ошибок серьёзный рост вряд-ли реален.

Go, c обработкой ошибок хуже, вполне взлетел, хоть и низенько пока.
Думаю основная проблема Rust это слишком крутая кривая обучения, покруче чем у C++
хотя похоже сам язык при этом намного проще. Но на С++ можно тупо сесть и начать колбасить
страшный код, а с Rust это может не получится.
Основной же плюс Rust то что у него нет GC что позволяет конкурировать с Си и С++ на самом
низком уровне, чего нет у других новых языков.

Здравствуйте, FR, Вы писали:

_>>По первому пункт в C++ сейчас всё очень слабо (есть возможность получить имя типа и проверить факт наличия у него каких-то свойств), но в C++23 обещают появление полноценной статической интроспекции. Да, ждать очень долго (на мой взгляд комитет C++ совершенно не верно расставляет приоритеты), но это однозначно в планах, а такая задержка вызвана тем (по их словам), что для реализации рефлексии им необходимо ввести перед этим (в C++20) ряд "поддерживающих" её технологий.
FR>В D же это давно реализовано, могли бы и спереть
FR>В общем по этому пункту все глухо пока, а в языках с нормальными макросами это есть сразу
FR>из коробки, да и D тоже неплохо сделано.

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

FR>Да миксины D это круто, если не видел нормальные макросы.
FR>Метаклассы никакой ни прорыв, а так бледное подобие нормальных макросов
FR>Растовские proc_macro_attribute + квазицитирование (https://docs.rs/quote/0.6.10/quote/) вроде полностью
FR>закрывают функциональность метаклассов C++.
FR>В Rust кстати макросы на нормальный уровень только-только вышли с завозом в
FR>стабильную версию процедурных макросов.

Не, метаклассы как раз хороши своей "ограниченностью". Потому как я вполне представляю себе их полноценную поддержку различными инструментами (т.е. всяческие введённые ими понятия, типа interface и т.п. именно так и будут обрабатываться, а не как какой-то произвольный метакод). Более того, я могу предположить, что появится множество "подвидов" языка, которые станут стандартами де факто, а не ограничатся рамками одной библиотеки, как происходит с макросами.

Здравствуйте, FR, Вы писали:

_>>Лично мне в Rust больше всего не нравится слишком высокая "синтаксическая цена" за даваемые им гарантии. В принципе того же уровня безопасности можно достичь в современном C++, если следовать ряду простейших административных правил. Rust следует им на уровне компилятора, так что это действительно несколько больший уровень гарантий (хотя говорят статические анализаторы C++ в последнее время тоже научились отслеживать это всё, но я сам не проверял), однако за это приходится расплачиваться большим объёмом "лишнего", "мусорного" кода. По моим ощущениям (пробовал писать небольшие тестовые программки на Rust) цена высоковата...

FR>А вообще синтаксис тупо вопрос привычки, да и у Rust эта цена плюс-минус одинаковая с C++.
FR>А если хоть немного писал на OCaml так вообще синтаксис Rust уже приятнее чем у C++ .
FR>Тоже сейчас играюсь с rust и кроме borrow checker от которого мозги страшно скрипят,
FR>ничего страшного почему-то не вижу, наоборот одни приятности и паттерн матчинг и вывод
FR>типов и макросы да и даже его недообъекты и плюс отдельно crate.

Я собственно borrow checker (ну и всё остальное, что осуществляет его поддержку в языке) и имел в виду тут. Только он меня больше раздражает не за "скрип мозгов", а за большое количество мусорного кода.

Здравствуйте, alex_public, Вы писали:

_>По первому пункт в C++ сейчас всё очень слабо (есть возможность получить имя типа и проверить факт наличия у него каких-то свойств), но в C++23 обещают появление полноценной статической интроспекции.

"Уже наше поколение будет жить при коммунизме!"
Пока С++ дорастет до того, что в D было 5-10 лет назад, уже все С++сники выйдут на пенсию, и некому будет насладиться этим чудесным языком. Тем временем молодежь все перепишет на JS.

Здравствуйте, D. Mon, Вы писали:

_>>По первому пункт в C++ сейчас всё очень слабо (есть возможность получить имя типа и проверить факт наличия у него каких-то свойств), но в C++23 обещают появление полноценной статической интроспекции.
DM>"Уже наше поколение будет жить при коммунизме!"
DM>Пока С++ дорастет до того, что в D было 5-10 лет назад, уже все С++сники выйдут на пенсию, и некому будет насладиться этим чудесным языком.

Да, это будет долго. Но нюанс в том, что обязательно случится, т.к. D перестал развиваться.

Более того, когда C++ вберёт в себя все интересные фичи D, он окажется не просто равным, а намного превосходящем. Потому как уже даже сейчас в C++ имеется ряд замечательных оригинальных фич, которые было бы очень правильно позаимствовать для D. Но т.к. язык перестал развиваться, то...

DM>Тем временем молодежь все перепишет на JS.

С учётом того, что сам JS и вся его инфраструктура написаны на C++, то это вполне реальный и приемлемый для C++'ов сценарий. ))) Хотя лично я бы предпочёл видеть на его месте Python.

Здравствуйте, alex_public, Вы писали:

_>D перестал развиваться.

А что позволяет сделать вывод о том, что D перестал развиваться?

Здравствуйте, alex_public, Вы писали:

_>1. Анализ кода (передаваемого в макрос)
_>По первому пункт в C++ сейчас всё очень слабо (есть возможность получить имя типа и проверить факт наличия у него каких-то свойств), но в C++23 обещают появление полноценной статической интроспекции.

Уточни, ты имеешь в виду интроспекцию типов, их полей и т.п. (рефлексия), или интроспекцию каких-то кусков кода/statements/ast (а-ля разбор форм в макросах Lisp)?
Если рефлексия — то в ограниченном виде уже доступно, например уже доступно всё необходимое для автоматической сериализации. В грядущих стандартах должны добавить нативное.
Если про второе — то можно поподробнее?

_>никак не влияет на другие части языка и может быть очень эффективно использовано как раз с приходом C++20 (и строк времени компиляции в нём).

Сторки времени компиляции доступны уже давно. Даже есть библиотека для построений DSL'ей на них:

Metaparse is a parser generator library for template metaprograms. The purpose of this library is to support the creation of parsers that parse at compile time. This library is intended to be used for embedded domain specific language creation for C++. The input of the generated parser is a compile time string, see string. The result of the parsing process is either an error or any other result the writer of the parser specifies.

Здравствуйте, Pzz, Вы писали:

Pzz>Польза высокоэффективной кодогенерации сильно переоценена. Это, конечно, приятно с целью рассчесывания чувства собственного достоинства думать, что моя программа исполняется со скоростью, как если бы она была написана на ассемблере, но только круче, но судя по тому, как много нового кода пишется на питоне, яваскрипте и т.п., никому особо до этой скорости дела нет.

Python обычно используется в качестве высокоуровнего клея для уже оптимизированных библиотек и поэтому его тормоза не напрягают. Если же пытаться делать мало-мальски весомую обработку непосредственно на Python — то его "производительность" расцветает во всей красе.

Pzz>Кроме того, использование подходящих по случаю алгоритмов и структур данных, тщательный выбор "внешних" по отоношению к программе инструметов, таких, как базы данных и т.п., дают в конечном итоге большую отдачу в плане повышения производительности, чем оптимизация кодогенерации ассемблерного уровня.

О, начинается, "да мы вас на алгоритмах заборем, да всё в базу упирается".
1. Никто не заставляет на C++ использовать не подходящие по случаю алгоритмы и структуры данных.
2. C++ на данный момент действительно не является лучшим выбором для формочек и crud'а.

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

Почему? Даже в языках где количество пробелов не влияет на семантику, код всё равно в большинстве своём нормально выровнен — так зачем тогда платить больше?

Здравствуйте, alex_public, Вы писали:

DM>>Пока С++ дорастет до того, что в D было 5-10 лет назад, уже все С++сники выйдут на пенсию, и некому будет насладиться этим чудесным языком.

_>Да, это будет долго. Но нюанс в том, что обязательно случится, т.к. D перестал развиваться.

Так может показаться, но кое-какие экспериментальные или нишевые штуки там продолжают появляться. Например, Rust-style контроль времени жизни, позволяющий делать такие вещи: https://github.com/atilaneves/fearless (понятно, что целиком все фичи Раста не будут копировать; как обычно D идет своим путем).

_>Потому как уже даже сейчас в C++ имеется ряд замечательных оригинальных фич, которые было бы очень правильно позаимствовать для D.

А можно примеров?

Здравствуйте, alex_public, Вы писали:

_>Я собственно borrow checker (ну и всё остальное, что осуществляет его поддержку в языке) и имел в виду тут. Только он меня больше раздражает не за "скрип мозгов", а за большое количество мусорного кода.
А можно пример мусорного кода?

Здравствуйте, so5team, Вы писали:

_>>D перестал развиваться.
S>А что позволяет сделать вывод о том, что D перестал развиваться?

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

Здравствуйте, Evgeny.Panasyuk, Вы писали:

_>>1. Анализ кода (передаваемого в макрос)
_>>По первому пункт в C++ сейчас всё очень слабо (есть возможность получить имя типа и проверить факт наличия у него каких-то свойств), но в C++23 обещают появление полноценной статической интроспекции.
EP>Уточни, ты имеешь в виду интроспекцию типов, их полей и т.п. (рефлексия), или интроспекцию каких-то кусков кода/statements/ast (а-ля разбор форм в макросах Lisp)?
EP>Если рефлексия — то в ограниченном виде уже доступно, например уже доступно всё необходимое для автоматической сериализации. В грядущих стандартах должны добавить нативное.
EP>Если про второе — то можно поподробнее?

Я хочу простейшую вещь. Возможность написать функцию вида template<typename T> string to_json(T t){...}, которую можно было бы использовать так:

struct User{
    string name;
    int age;
};
cout<<to_json(User{"Xxx", "123"});

Про грядущие стандарты (правда это будет к сожалению не C++20, а дальше) я в курсе, но хотелось бы уже прямо сейчас.

_>>никак не влияет на другие части языка и может быть очень эффективно использовано как раз с приходом C++20 (и строк времени компиляции в нём).
EP>Сторки времени компиляции доступны уже давно. Даже есть библиотека для построений DSL'ей на них:
EP>

EP>Metaparse is a parser generator library for template metaprograms. The purpose of this library is to support the creation of parsers that parse at compile time. This library is intended to be used for embedded domain specific language creation for C++. The input of the generated parser is a compile time string, see string. The result of the parsing process is either an error or any other result the writer of the parser specifies.

Да, я помню. Но сейчас это хитрый хак. А начиная с C++20 это будет обычный std::string.

Здравствуйте, alex_public, Вы писали:

_>Однако набор возможностей языка, являющийся передовым на 2010-ый, сейчас уже точно не выглядит таковым.

А чего хотелось бы в дополнение к тому, что в D уже есть?

Здравствуйте, D. Mon, Вы писали:

DM>>>Пока С++ дорастет до того, что в D было 5-10 лет назад, уже все С++сники выйдут на пенсию, и некому будет насладиться этим чудесным языком.
_>>Да, это будет долго. Но нюанс в том, что обязательно случится, т.к. D перестал развиваться.
DM>Так может показаться, но кое-какие экспериментальные или нишевые штуки там продолжают появляться. Например, Rust-style контроль времени жизни, позволяющий делать такие вещи: https://github.com/atilaneves/fearless (понятно, что целиком все фичи Раста не будут копировать; как обычно D идет своим путем).

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

_>>Потому как уже даже сейчас в C++ имеется ряд замечательных оригинальных фич, которые было бы очень правильно позаимствовать для D.
DM>А можно примеров?

Ну например семантику перемещения, концепты, сопрограммы (ну это естественно не оригинальное и ещё не в стандарте, но сейчас на пике обсуждения в комитете C++). Это из крупных блоков. Но там уже и разный синтаксический сахар появился (хотя раньше D был во всех подобных мелочах удобнее C++), типа автоматической распаковки кортежей, инициализации в if/switch и т.д.

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

Здравствуйте, alex_public, Вы писали:

DM>>Так может показаться, но кое-какие экспериментальные или нишевые штуки там продолжают появляться. Например, Rust-style контроль времени жизни, позволяющий делать такие вещи: https://github.com/atilaneves/fearless (понятно, что целиком все фичи Раста не будут копировать; как обычно D идет своим путем).
_>Не очень понятно зачем это надо при наличие ключевого слова shared в языке. Не говоря уже о наличие встроенных в язык акторов, позволяющих для многих задач (ну разве что кроме какой-нибудь реалтаймой обработки видео) вообще забыть про все эти проблемы.

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

_>>>Потому как уже даже сейчас в C++ имеется ряд замечательных оригинальных фич, которые было бы очень правильно позаимствовать для D.
DM>>А можно примеров?

_>Ну например семантику перемещения, концепты, сопрограммы (ну это естественно не оригинальное и ещё не в стандарте, но сейчас на пике обсуждения в комитете C++). Это из крупных блоков. Но там уже и разный синтаксический сахар появился (хотя раньше D был во всех подобных мелочах удобнее C++), типа автоматической распаковки кортежей, инициализации в if/switch и т.д.

Я подробно не слежу за обсуждениями комитетов и новостями из будущего С++, потому не очень хорошо это представляю.
Но сдается мне, что большая часть перечисленного уже есть в D, пусть и с некоторыми отличиями. И перемещения, и файберы (вместо сопрограмм), и инициализация в if (часто пользуюсь), и свой подход к тому, что должны делать концепты (всякие isForwardRange!R).

Здравствуйте, alex_public, Вы писали:

EP>>Если рефлексия — то в ограниченном виде уже доступно, например уже доступно всё необходимое для автоматической сериализации. В грядущих стандартах должны добавить нативное.
_>Я хочу простейшую вещь. Возможность написать функцию вида template<typename T> string to_json(T t){...}, которую можно было бы использовать так:
_>

_>struct User{
_>    string name;
_>    int age;
_>};
_>cout<<to_json(User{"Xxx", "123"});
_>

Вот как раз с вышеприведённой библиотекой так можно, и даже потом можно from_json обратно. Ньюанс в том что ключи будут сурогатные ибо доступа к именам нет.
Пока нет поддержки языка обхожусь BOOST_FUSION_DEFINE_STRUCT/BOOST_HANA_DEFINE_STRUCT. С поддержкой было бы удобнее, но не прям чтобы киллер-фича.
А вот хочется чтобы на горизонте замаячили макросы а-ля Lisp, или макрОсы а-ля Nemerle

Здравствуйте, WolfHound, Вы писали:

_>>Я собственно borrow checker (ну и всё остальное, что осуществляет его поддержку в языке) и имел в виду тут. Только он меня больше раздражает не за "скрип мозгов", а за большое количество мусорного кода.
WH>А можно пример мусорного кода?

Речь в основном про всяческие типы-обёртки и функции их преобразования между собой, необходимы для работы концепции Rust'а.

Кстати, могу рассказать некий забавный момент. Я был знаком с парочкой C++ программистов, которые утверждали что их напрягает использование unique_ptr своей излишней многословностью (в каком-то смысле тем самым мусорным кодом) — типа с голыми указателями код выглядит более лаконично и читаемо. Так вот я послал их изучить как выглядит работа с памятью в Rust... Они ТАК впечатлились увиденным, что после этого начали считать unique_ptr идеалом удобства при работе с памятью.

P.S. Тут в соседней темке подкинули забавную ссылку (http://smallcultfollowing.com/babysteps/blog/2018/11/10/after-nll-moving-from-borrowed-data-and-the-sentinel-pattern/) почти по теме. Хотя там уже не про "мусорный код", а про архитектурные проблемы, но и то и то происходит из одной первопричины — излишнее переусложнее базовой концепции.

Здравствуйте, so5team, Вы писали:

_>>Однако набор возможностей языка, являющийся передовым на 2010-ый, сейчас уже точно не выглядит таковым.
S>А чего хотелось бы в дополнение к тому, что в D уже есть?

Про фичи из C++ я ответил здесь http://rsdn.org/forum/flame.comp/7321558.1

Автор: alex_public
Дата: 10.12.18

. Если говорить из других языков, то даже не знаю... Ну наверное продвинутое сопоставление с образцом (pattern matching) не помешало бы. Может ещё что, так навскидку трудно сказать)

Здравствуйте, D. Mon, Вы писали:

_>>Ну например семантику перемещения, концепты, сопрограммы (ну это естественно не оригинальное и ещё не в стандарте, но сейчас на пике обсуждения в комитете C++). Это из крупных блоков. Но там уже и разный синтаксический сахар появился (хотя раньше D был во всех подобных мелочах удобнее C++), типа автоматической распаковки кортежей, инициализации в if/switch и т.д.

DM>Я подробно не слежу за обсуждениями комитетов и новостями из будущего С++, потому не очень хорошо это представляю.
DM>Но сдается мне, что большая часть перечисленного уже есть в D, пусть и с некоторыми отличиями. И перемещения, и файберы (вместо сопрограмм), и инициализация в if (часто пользуюсь), и свой подход к тому, что должны делать концепты (всякие isForwardRange!R).

Что-то не припомню в D ни семантики перемещения, ни концептов. Покажи примеры кода что ли...

Про инициализацию в if ты видимо подумал немного не о том — в D (так же как и в самом древнем C/C++) можно приравнять проверяемое выражение к некой переменной. Но это совсем не то. Речь идёт об отдельном блоке инициализации, как у оператора for. Который соответственно позволяет производить произвольные объявление. И да, это мелкий синтаксический сахар. Но множество таких мелочей постепенно делают C++ удобнее D, хотя раньше было наоборот. Да, кстати, а вот автоматическая распаковка кортежей на мой вкус является хотя и тоже сахаром, но не мелким.

Насчёт файберов вместо сопрограмм — это вообще не о том. Посмотри например это https://www.youtube.com/watch?v=LNXkPh3Z418 видео, с 33 по 48 минуты, чтобы понять о чём я. Хотя если у тебя есть время, то советовал бы глянуть с начала, чтобы сравнить с аналогичной реализацией в D (особенно про GPU наверное интересно будет).

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Если рефлексия — то в ограниченном виде уже доступно, например уже доступно всё необходимое для автоматической сериализации. В грядущих стандартах должны добавить нативное.
_>>Я хочу простейшую вещь. Возможность написать функцию вида template<typename T> string to_json(T t){...}, которую можно было бы использовать так:
_>>

_>>struct User{
_>>    string name;
_>>    int age;
_>>};
_>>cout<<to_json(User{"Xxx", "123"});
_>>

EP>Вот как раз с вышеприведённой библиотекой так можно, и даже потом можно from_json обратно. Ньюанс в том что ключи будут сурогатные ибо доступа к именам нет.

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

EP>Пока нет поддержки языка обхожусь BOOST_FUSION_DEFINE_STRUCT/BOOST_HANA_DEFINE_STRUCT.

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

EP>С поддержкой было бы удобнее, но не прям чтобы киллер-фича.

Когда появится поддержка рефлексии в языке, думаю очень значительную часть Boost'а можно будет просто выкинуть за ненадобностью (хотя на самом деле оно конечно останется, для совместимости со старыми компиляторами)...

EP>А вот хочется чтобы на горизонте замаячили макросы а-ля Lisp, или макрОсы а-ля Nemerle

Это да, но это отдельная тема. Мне кажется, что метапрограммирование в C++ всё же будет ограничено шаблонами (хотя это частенько и криво), а вот их постепенно будут развивать через constexpr вычисления.