Nim lang - Компьютерные священные войны

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

_>1. Компиляция с помощью трансляции в оптимизированный C код. Соответственно поставив дальше в цепочке какой-нибудь gcc с правильными настройками оптимизации мы получим программу намного опережающую по быстродействию аналоги из D и Rust (на данный момент — когда-нибудь их компиляторы возможно и дойдут до уровня C/C++). Для языка претендующего на роль замены C/C++ это очень важный фактор. Ну и соответственно с поддерживаемыми платформами и библиотеками тоже всё хорошо.
_>2. Современный синтаксис в стиле Питона (если бы он был статически типизированным (с выводом типов) и с доступом на системный уровень (указатели, структуры и т.п.)) по краткости, но далеко не ограничивается его возможностями (например имеются мультиметоды, дженерики, ограниченные диапазоном типы, исполнение кода при компиляции и ещё множество других мелких вкусностей). Понятно что это в основном синтаксических сахар, но всё же на подобном языке гораздо приятнее программировать.
_>3. Мощное метапрограммирование на макросах работающих непосредственно с AST — эффективная замена всем костылям на шаблонах C++, позволяющая расширять язык в любую сторону до бесконечности. )))

Все это прикольно, но это, ИМХО, не киллер-фичи, а просто приятные вещи.

Есть, к примеру, Eiffel, который уже 25 лет назад:
— точно так же, как и Nim, компилировался в оптимизированный С код;
— имел Design by contract (которого в нормальном виде нет нигде до сих пор);
— имел крутое множественное наследование (причем, ИМХО, лучшей реализации опять же нет до сих пор ни в одном языке);
— имел command-query separation principle на уровне языка;
— развивает простой и мощный подход к параллелизму — SCOOP;
— тонны других мелочей, строгий и последовательный синтаксис, ну и вообще Eiffel — один из самых продуманных языков, какие я знаю.

На фоне всего этого восторженные мнения о Nim вызывают в лучшем случае недоумение. А ведь есть и другие крутые продуманные языки, тот же Ceylon. Rust и безымянный C#-подобный язык от Joe Daffy — тоже мощные проекты с центральными идеями, вокруг которых построено все остальное.

_>Сочетание этих трёх пунктов даёт вполне оригинальную концепцию. )

Мдя...

ARK>>Кстати, было бы неплохо взглянуть на уродства Nim (кои у него, безусловно, есть).
_>Для этого надо хотя бы поработать на нём. Лично я не написал на нём ни одной программки (хотя внимательно листал документацию), так что пока не могу давать какие-то практические отзывы.
_>По слухам там есть какие-то существенные извращения с именами переменных и пробельными символами... )))

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

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

MTD>Вполне секси, очень изящно можно использовать код на С, транслируется в него же. Какие же фатальные недостатки мешают ему стать популярным?

На экспертное мнение не претендую, мое личное ИМХО — в нем нет ни одной киллер-фичи, все ровненько, относительно красивенько. Но таких языков дофига, взять тот же Ceylon, например. Короче, недостаточно хорош, чтобы откусить кусок у имеющихся языков. И бабла за ним нет, чтобы пропихнуть его.

Вот у руста киллер-фича есть. А у Go и Swift есть бабло.

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

_>1. Компиляция с помощью трансляции в оптимизированный C код. Соответственно поставив дальше в цепочке какой-нибудь gcc с правильными настройками оптимизации мы получим программу намного опережающую по быстродействию аналоги из D и Rust (на данный момент — когда-нибудь их компиляторы возможно и дойдут до уровня C/C++).

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

_>Для языка претендующего на роль замены C/C++ это очень важный фактор.

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

_>2. Современный синтаксис в стиле Питона (если бы он был статически типизированным (с выводом типов) и с доступом на системный уровень (указатели, структуры и т.п.)) по краткости, но далеко не ограничивается его возможностями (например имеются мультиметоды, дженерики, ограниченные диапазоном типы, исполнение кода при компиляции и ещё множество других мелких вкусностей). Понятно что это в основном синтаксических сахар, но всё же на подобном языке гораздо приятнее программировать.

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

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

EP>Языку не обязательно иметь новые фичи чтобы претендовать на что-то. Удачно скомбинировав существующие фичи (лучше чем в других языках, или вообще в уникальной комбинации) можно получить вполне конкурентоспособный язык

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

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

_>Угу, только это вполне можно переформулировать совсем по другому: это Eiffel не вписывается в концепцию современного системного языка. ))) Разве что на специфическую узенькую его часть, и так уже занятую Ada. )))

Ну, Nim-то вообще никуда не вписывается.

"Почти С++ с питоновским синтаксисом" — кому это нужно настолько, чтобы развивать это из нынешнего состояния?

Если брать гипотетическую ситуацию, когда у Nim уже все есть на уровне С++ — проекты, community, библиотеки, литература — это другое дело. Только вот если бы это все магическим образом возникло для D, Eiffel, Rust, да даже для ~~розового слона~~ Nemerle — то и для них ситуация была бы качественно иная, и С++ пришлось бы очень-очень потесниться, а какие-то ниши покинуть совсем. Но толку-то от этих фантазий. А в текущей ситуации лично я не вижу ничего, чем Nim мог бы выделиться и заинтересовать широкие массы. Видимо, поэтому он в заднице и сидит.

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

_>Вообще после выхода C++11 и с учётом дальнейшей скорости развития (C++14, C++17 и т.п.), взятой комитетом, создаётся впечатление, что старичок C++ прошёл курс омоложения и планирует ещё попьянствовать на поминках своих молодых конкурентов. ))) Даже не знаю хорошо это или плохо — у меня двойственные ощущения. )

C++ конечно вечно молодой, но блин убивают меня такие темы http://rsdn.org/forum/cpp/7304124
Я на нем не пишу, чисто поржать захожу, как мэтры обсуждают "что это могло бы значить". ИМХО в хорошем языке не должно быть такого, но C++ какой есть. И он при всем при этом просудится на похоронах C# какого-нибудь.

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

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

А, ну т.е. это очередной "киллер", который умрёт раньше того, кого был должен убить.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

_>>Хы, ну типизации там не чутка, а побольше чем в C++. Причём настолько, что становится уже неудобно писать... )

M>А можно с примерами? Из доки как-то не очевидно. Дока вообще на полных ньюбов походу расчитана. Мне потом подсказали, что то, что меня заинтересовало, бульменее описано в каком-то супер-пупер адвансед кук-буке.

"Бульменее"
Ты б более серьёзно отнёсся к прочитанному, тогда возможно и увидел бы и типизацию, и прочее. А то ты пишешь тут на албанском в духе "встал-посрал", книгу он за день прочитал и ничего не понял. Читать надо медленнее. Если ты глядишь в книгу и видишь фигу, то виноват в этом ты, а не книга, и не язык, которому она посвящена.

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

_>>>Хы, ну типизации там не чутка, а побольше чем в C++. Причём настолько, что становится уже неудобно писать... )

M>>А можно с примерами? Из доки как-то не очевидно. Дока вообще на полных ньюбов походу расчитана. Мне потом подсказали, что то, что меня заинтересовало, бульменее описано в каком-то супер-пупер адвансед кук-буке.

С>"Бульменее"
С>Ты б более серьёзно отнёсся к прочитанному, тогда возможно и увидел бы и типизацию, и прочее. А то ты пишешь тут на албанском в духе "встал-посрал", книгу он за день прочитал и ничего не понял. Читать надо медленнее. Если ты глядишь в книгу и видишь фигу, то виноват в этом ты, а не книга, и не язык, которому она посвящена.

Я вполне серьезно сначала относился. Прочитав RTPL так и не понял, в чем прикол, чего народ так на этот раст мастурбирует. Потом мне объяснили, что есть три мега-фичи — борроу-чекинг, паттерн матчинг и крутые макросы. Этим вопросам посвящены мелкие разделы где-то в конце мануала. Я пробежался по ним, но глубоко не вникал — они не показались мне какими-то важными. Даже если эти мега-фичи реально полезны (а я сомневаюсь — на плюсах с некоторой гигиеной борроу-чекинг не нужен; паттерн матчинг вообще непонятно зачем нужен — с минимумом оверхеда реализуется на плюсах — да и вообще не нужно — мне такой функционал раз в пять лет нужен; крутые макросы — возможно получше плюсовых шаблонов, тут — хз), остальной язык какой-то убогий. Это как с питоном — первый день пишешь — вроде всё круто, второй — норм, третий — ну ё-маё, верните мне мои плюсы, я на них быстрее (и по скорости разработки, и по скорости выполнения) напишу.

Как я понял, это мозилла-тормозилла не осилила нормально написать свой бравзер на плюсах, и решили что проще запилить свой язык, и на нем переписать бравзер. И что, таки переписали на расте?

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

KP>но ещё и гарантия по дедлокам, что уже реально выглядит как фича-убийца.

Не дедлоков (с этим Rust не может справится в принципе), а гонок. В дополнение к ссылке, которую уже дали, вот еще одна ссылка для общего понимания: https://doc.rust-lang.org/book/ch16-03-shared-state.html (ну и еще до кучи: https://doc.rust-lang.org/book/ch16-04-extensible-concurrency-sync-and-send.html).

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

a> Но я подозреваю, что про сборку ide ты написал не ради самой ide, а потому что при её сборке можно наткнуться на какие-то увлекательные квесты? )))

Ну да, хотелось просто что-то собрать из "рекомендованного собаководами".

Начинается все с того, что язык не компилируется на некоторых дистрибутивах. Дальше для сборки чего-нибудь требуется пакетный менеджер nimble, который качает все зависимые библиотеки на каждую(!) сборку. В конце я наткнулся на то, что в данном конкретном проекте IDE из за разницы в регистре имени файла (autocomplete.nim) по сравнению с импортом в коде (import AutoComplete) происходит замечательный прострел ноги, т.к. язык позволяет переменной присвоить тип "модуль" (или что-то в этом духе) и переименование файла в нужный регистр приводит к конфликту между классом AutoComplete и модулем AutoComplete — т.е. с тестированием у них тоже все грустно.

После сборки выясняется, что отсутствует системная библиотека (а куда же смотрел nimble?), которая к тому же загружается динамически (прощай автоматическое прописывание зависимостей при пакетировании приложений).

И это у меня еще было время/желание во всем этом покопаться. Простой человек™ после первой же проблемы бросит все нафиг и пойдет искать то, что работает "из коробки". Хотя, может я просто привык к хорошему...

Бэкапимся на Яндекс.Диск

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

ARK>Я не эксперт в таких вопросах, по моему мнению, главным фактором забвения послужила платность и закрытость компилятора — слишком долгое время. Раньше так принято было, но времена меняются. Потом-то, конечно, открыли и вроде бы сейчас официальный компилятор уже бесплатен — но время уже упущено.

Сейчас у них двойное лицензирование: https://www.eiffel.com/eiffelstudio/licensing/

Для коммерческих, закрытых проектов, нужно покупать коммерческую лицензию. Цену на сайте они уже не озвучивают. Ранее было что-то порядка $8K за одного пользователя и за одну платформу. Т.е. если нужно было разрабатывать и под Win, и под Lin, то $16K на одного разработчика.

Бесплатно только для OpenSource.

Здравствуйте, Лось Чтостряслось, Вы писали:

_>>В общем это третий (после D и Rust) реальный претендент на замену устаревшего C++
ЛЧ>эм... и че, как дела у этих реальных претендентов?

Как у них особо не в курсе. А вот если в C++20/C++23 реализуют всё, что обещали, то сомневаюсь что у кого-то будут шансы... )))

Здравствуйте, 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.

Здравствуйте, 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 наверное интересно будет).

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

_>>Ха))) Зато если код на Rust всё же заставить скомпилироваться, то можно быть уверенным, что он будет работать правильно (во всяком случае в работе с памятью).
KP>Вроде еще где-то проскакивала информация, что гарантия не только по памяти, что сравнительно легко достигается в C++ если писать с нуля, но ещё и гарантия по дедлокам, что уже реально выглядит как фича-убийца.

Ничего даже близкого там нет. Есть только простейшая возможность обеспечить гарантированно не одновременный доступ на запись к одной области памяти из нескольких потоков. https://doc.rust-lang.org/nomicon/races.html

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

MTD>Вполне секси, очень изящно можно использовать код на С, транслируется в него же. Какие же фатальные недостатки мешают ему стать популярным?

Поглядываю на него с интервалом в полгода — имхо, не выходит из состояния альфы и почти не развивается.

Nemerle — power of metaprogramming, functional, object-oriented and imperative features in a statically-typed .NET language

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

_>В общем это третий (после D и Rust) реальный претендент на замену устаревшего C++, со своей оригинальной концепцией

Э... какая это у него оригинальная концепция, я что-то пропустил?

Там же полное отсутствие какой-либо оригинальности.
Или "язык с эффективностью C++ и при этом без врождённых уродств C++" и есть оригинальность?
Кстати, было бы неплохо взглянуть на уродства Nim (кои у него, безусловно, есть).

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

a> AB>Не совсем понятно какую проблему решает язык, какая у него "сверх-способность"?
a> Это язык с эффективностью C++ и при этом без врождённых уродств C++.

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

А с инфраструктурой у nim все плохо. Я сначала много написал про свое первое знакомство с ним, потом удалил и решил написать проще — попробуй на CentOS 6 собрать, скажем, их же IDE Aporia по их же рекомендациям (используя последнюю версию языка и вот это все).

А "врожденное уродство" в виде nimble я даже обсуждать не хочу — много раз обсуждалось на примере python pip, ruby gem, etc. Еще один подобный "уродец"? No Way!

Бэкапимся на Яндекс.Диск

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

_>В общем это третий (после D и Rust) реальный претендент на замену устаревшего C++

эм... и че, как дела у этих реальных претендентов?

Здравствуйте, Лось Чтостряслось, Вы писали:

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

_>>В общем это третий (после D и Rust) реальный претендент на замену устаревшего C++

ЛЧ>эм... и че, как дела у этих реальных претендентов?

Ну из этих троих, только Rust в будущем реальный претендент. По росту интереса (сообщества, книги, поделия, конференции и прочие смартконтракты

) у него стабильный рост.

M>По росту интереса (сообщества, книги, поделия, конференции и прочие смартконтракты

) у него стабильный рост.
Увы, с 2000-х стабильный рост кто только не показывал за последние лет 20. Имхо есть какой-то процент отчаянных (допустим 10%), которые готовы взяться за любой язык. И эта группа энтузиастов мечется кто куда — кто-то в Rust, кто-то в D, кто-то в Go, в Dart, в Haskell, Scheme, PHP, Ruby и т.п. В итоге в пределах мелких процентов экзотические языки показывают стабильный рост, а через несколько лет хайп переключается на кого-то новенького.

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

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

Сюда нужно добавить еще и то, что, скажем в 2000-х, при покупке EiffelStudio разработчик получал только стандартную библиотеку (пусть и довольно большую, но не всеобъемлющую) и один GUI-фреймворк на Eiffel-е (на нем и была написана EiffelStudio). Какой-то внешней экосистемы библиотек вокруг языка, по сути, и не было. Сторонние библиотеки было сложно найти и живыми из них были вообще считанные единицы. Т.е. заплатив приличные деньги за инструмент разработки человек оказывался в ситуации, когда недостающие библиотеки нужно было либо писать самому, либо использовать из Eiffel-я чужие библиотеки через C-шный интерфейс. Что разительно отличало Eiffel от Java, .NET-а, С++ и других распространенных языков.

Можно предполагать, почему Eiffel не стал мейнстримом в конце 1980-х и начале 1990-х, когда продажа средств разработки за деньги (в том числе и большие) была нормальным явлением. Но в 2000-х у Eiffel-я уже не было шансов бороться на массовом рынке. И он остается жить там, где за качество готовы платить дорого.

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

_>Как-то много работы. Может ты начинай, а я подхвачу?

Динамика популярности в Google Trends по ключевым словам "Rust, Nim, dlang"
(По всему миру, 11.06.2016 – 06.12.2018) — https://g.co/trends/13dGn

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

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

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

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

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

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

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

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

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

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

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

_>>Только всё же Rust, D, Nim, если смотреть по порядку популярности... А вот Go не из этой песочницы — это управляемый язык, так что заменой C++ не может служить в принципе.
M>Почему не может?

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

_>>Хы, ну типизации там не чутка, а побольше чем в C++. Причём настолько, что становится уже неудобно писать... )
M>А можно с примерами? Из доки как-то не очевидно. Дока вообще на полных ньюбов походу расчитана. Мне потом подсказали, что то, что меня заинтересовало, бульменее описано в каком-то супер-пупер адвансед кук-буке.

Примерами чего?

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

Нет, концептуально Rust может всё тоже самое, что и C++ и даже больше. Сейчас правда ситуация не такая, потому что его оптимизатор не способен пока бороться с C++ (даже с учётом использования llvm), многие библиотеки не доделаны, инструменты не доработаны и т.п. Но, как ты понимаешь, это всё временные проблемы и со временем всё станет как минимум на уровне C++, поскольку концепция (низкоуровневость) позволяет. Проблемы (на мой взгляд) у Rust немного в другом (см. ниже).

M>А те проблемы, которые он решает — кажутся как минимум несколько надуманными.

Rust оригинально решает ровно одну задачу: гарантированное управление памятью без сборщика мусора. Для C++ программистов это проще всего объяснить как встроенные в компилятор подобия unique_ptr, shared_ptr и другие, причём являющиеся единственным инструментом работы с памятью в safe режиме. В теории это всё звучит отлично, но на практике приводит к такому количеству "лишнего" кода, что на мой вкус цена таких гарантий становится слишком высока. Однако многие со мной не согласны и готовы платить такую цену за гарантии компилятором.

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

Ха))) Несмотря на в чём-то похожий синтаксис, Rust концептуально является скорее противоположностью Питона. Во всяком случае если говорить о практике. На Питоне решение задачи обычно самое быстрое (в смысле написание, я не исполнения кода). На C++ для решения той же задачи потребуется заметно больше усилий (хотя она и работать будет намного эффективнее). А на Rust'е потребуется написать ещё больше кода, чем на C++, при сравнимой производительности. Зато если код на Rust всё же заставить скомпилироваться, то можно быть уверенным, что он будет работать правильно (во всяком случае в работе с памятью).

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

_>>>Ну наверное продвинутое сопоставление с образцом (pattern matching) не помешало бы. Может ещё что, так навскидку трудно сказать)
M>>А что это такое? В расте, как я понял, это тупой кейс по типу union'а (в плюсах было бы отдельное поле typeTag и по нему бы был case).
_>Как на плюсах написать выделенное жирным?
_>

_>struct Point {
_>    x: i32,
_>    y: i32,
_>}

_>fn main() {
_>    let p = Point { x: 0, y: 7 };
_>    let Point { x, y } = p;
_>    assert_eq!(0, x);
_>    assert_eq!(7, y);
_>}
_>

Данный код записывается на C++ буквально так:

struct Point {
        int32_t x;
        int32_t y;
};

int main()
{
    auto p=Point{0, 7};
    auto [x, y]=p;
    assert(0==x);
    assert(7==y);
}

И к сопоставлению с образом это не имеет ни малейшего отношения. )

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

_>>Хотя если у тебя есть время, то советовал бы глянуть с начала, чтобы сравнить с аналогичной реализацией в D (особенно про GPU наверное интересно будет).
WH>По сравнению с этим http://halide-lang.org/ ренжи детский сад ясельная группа.

Эм, и как ты вообще можешь сравнивать некую абстрактную концепцию работы с коллекциями (следующий уровень абстракции над понятием итератор) с отдельным специализированным языком, заточенным на решение SIMD задач? Между ними если и будет когда-то какая-то связь, то исключительно "дружеская" (скажем можно будет написать на Halide какой-то алгоритм, работающий с данными в виде диапазонов) и уж точно не "конкуренция".

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

M>>А что это такое? В расте, как я понял, это тупой кейс по типу union'а (в плюсах было бы отдельное поле typeTag и по нему бы был case).

_>Как на плюсах написать выделенное жирным?
_>

_>struct Point {
_>    x: i32,
_>    y: i32,
_>}

_>fn main() {
_>    let p = Point { x: 0, y: 7 };
_>    let Point { x, y } = p;
_>    assert_eq!(0, x);
_>    assert_eq!(7, y);
_>}
_>

Такого в плюсах нет. Но меня как-то никогда отсутствие данной фичи не напрягало. И что-то такое вроде то ли таки запилили, то ли вот вот запилят

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

_>>Мдаа, ты снова умудрился показать не сопоставление с образцом, а какую-то ненужную ерунду. А всего то стоило проставить значение у какой-нибудь из переменных в образце (как в примере на Эрланге или в примере 18-14 на Расте). Я начинаю думать, что ты реально не понимаешь смысл технологии сопоставления с образцом.
_>Когда на плюсах реализуешь этот "смешной код", тогда и поговорим.

Твой "сложнейший" код на большинстве языков программирования записывается как "red=cp.c.r;".

Говорить о том, что сопоставление с образцом нужно для решения этой "задачки" — это просто феерическое непонимание. Причём непонимание как сопоставления с образцом, так и структурного связывания: это разные технологии с разными задачами, но обе эти задачи очень далеки от показанной тобой глупости.

Структурное связывание в C++ (и во многих других языках, например в Питоне) создано для удобного написания такого кода:

pair<Result, ErrorCode> F()
{
    //...
    return {r, e};
}
auto [r, e]=F();

Сопоставление с образом в том же Rust'е помогает в написание кода такого вида (как видно, нет никаких намёков на "деструкцию" — это всего лишь одна из опций):

fn main() {
    let x = Some(5);
    let y = 10;

    match x {
        Some(50) => println!("Got 50"),
        Some(y) => println!("Matched, y = {:?}", y),
        _ => println!("Default case, x = {:?}", x),
    }
    println!("at the end: x = {:?}, y = {:?}", x, y);
}

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

_>Это вот реальные инструменты для вычислений на GPU, хотя речь в данной дискуссии была совсем не о них.
В теории самые быстрые программы на ассемблере. А на практике попытки обогнать современные компиляторы мало кто может.
С Halide ситуация ещё хуже.
Просто за счёт того что на нем можно перебрать не один десяток планов исполнения за день. А руками у тебя будет уходить несколько дней на один план исполнения.
А производительность кода зависит от плана исполнения намного сильнее, чем от микрооптимизаций. А если быстрейший план упирается в пропускную способность памяти, то от них вообще ничего не зависит.

_>Какая библиотека то? )))
Та, про которую он говорил. Ибо просто взять и закинуть код в GPU может сработать только для наиболее примитивных случаев.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

_>>В которой динамический полиморфизм применяется только в тех случаях, когда он реально необходим (весьма редко на самом деле), а не по всякому чиху.
WH>Простейший пример: Дерево разбора программы. Как ты собираешься его представлять в "правильной архитектуре"? Без выделения кучи отдельных объектов?

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

WH>>>1)Все проверки в моём варианте исключительно статические. Соответственно скорость работы в самом худшем случае будет как у rust'а.
_>>Всё верно, будет та же самая максимальная скорость, что в C++ или Rust'e. Соответственно возникает вопрос — а зачем нам какая-то более сложная система, если существующие и так уже работают точно так же?
WH>Нет. Не верно. Ты вообще прочитал, что я написал?
WH>В С++ ты можешь сделать то о чем я говорю. Но не будет никаких гарантий со стороны компилятора.

Да.

WH>А вот в расте нет.
WH>Там система типов обязывает удалять каждый объект.

В Rust'е есть режим C/C++ под названием unsafe. )))

_>>Ну видимо потому, что реального RAII в .Net нет, а его бледные подобия дико неудобны. )))
WH>Нет. По тому, что объекты с деструкторами нужны только на стеке.
WH>Показать пример, когда это не так ты не можешь. Вот и юлишь.

Ну для начала "на стеке" — это довольно широкое понятие. К примеру выделенное "на стеке" функции main по сути является глобальной переменной.

Далее, я так понимаю, что тебя интересуют примеры объектов в куче, деструкторы которых используются не только для управления памятью? Ну вот тебе элементарный пример: пишем приложение, являющееся контейнером OLE-объектов (ну грубо говоря свой Word). В таком приложение у нас естественно где-то внутри должен быть динамический список неких обёрток вокруг COM-интерфейсов, обеспечивающих как удобный доступ к их функциональности, так и автоматическое освобождение...

_>>Эм, ты похоже всё перепутал. Здесь у нас вообще то речь шла о другом твоём подходе (у тебя в изначальном сообщение было несколько предложений). С идеей о том, чтобы убивать разом некие кучи логически связанных между собой объектов, я никогда не спорил — она абсолютно верная. Более того, она прямо сейчас эффективно используется (только без всяких гарантий от компилятора) в некоторых C++ проектах. А здесь мы обсуждали твою идею с разделением (с помощью системы типов) всех объектов на имеющих и не имеющих деструкторы. Такая смесь подходов на мой взгляд не принесёт вообще никаких преимуществ.
WH>Я ничего не перепутал.
WH>Для того чтобы убивать объекты пачками нужна гарантия отсутствия там деструкторов.
WH>Причём не только из-за производительности но главное из-за того что не понятно в каком порядке эти деструкторы вызывать.

Ну т.е. по факту из плюсов:
— гарантии компилятора на безопасное уничтожение пула.
Из минусов:
— невозможность использования объектов с деструктором
— усложнение системы типов (возможно приводящее к написанию большого количества лишнего кода, как в Rust'e).

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

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

WH>Причем тут С++? Ты вообще прочитал о чём разговор?

Было бы замечательно, если бы вы собрали ваши мысли о новом способе управления памятью: из тех трёх эпичных постов, из прочих тредов, и оформили бы это в единую статью с Q&A в конце.

Вполне секси, очень изящно можно использовать код на С, транслируется в него же. Какие же фатальные недостатки мешают ему стать популярным?

Бэкапимся на Яндекс.Диск

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

MTD>Вполне секси, очень изящно можно использовать код на С, транслируется в него же. Какие же фатальные недостатки мешают ему стать популярным?

Отсутствие развитого сообщества и команды разработчиков. Т.е. там ситуация не сравнимая не то что D, а возможно даже хуже чем у Nemerle.

А так язык конечно же очень интересный. Позволяет писать код сравнимый по краткости с Питоном (при этом статически типизированный), который исполняется со скоростью C/C++.

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

_>>В общем это третий (после D и Rust) реальный претендент на замену устаревшего C++, со своей оригинальной концепцией
ARK>Э... какая это у него оригинальная концепция, я что-то пропустил?

Там же полное отсутствие какой-либо оригинальности.
ARK>Или "язык с эффективностью C++ и при этом без врождённых уродств C++" и есть оригинальность?

1. Компиляция с помощью трансляции в оптимизированный C код. Соответственно поставив дальше в цепочке какой-нибудь gcc с правильными настройками оптимизации мы получим программу намного опережающую по быстродействию аналоги из D и Rust (на данный момент — когда-нибудь их компиляторы возможно и дойдут до уровня C/C++). Для языка претендующего на роль замены C/C++ это очень важный фактор. Ну и соответственно с поддерживаемыми платформами и библиотеками тоже всё хорошо.
2. Современный синтаксис в стиле Питона (если бы он был статически типизированным (с выводом типов) и с доступом на системный уровень (указатели, структуры и т.п.)) по краткости, но далеко не ограничивается его возможностями (например имеются мультиметоды, дженерики, ограниченные диапазоном типы, исполнение кода при компиляции и ещё множество других мелких вкусностей). Понятно что это в основном синтаксических сахар, но всё же на подобном языке гораздо приятнее программировать.
3. Мощное метапрограммирование на макросах работающих непосредственно с AST — эффективная замена всем костылям на шаблонах C++, позволяющая расширять язык в любую сторону до бесконечности. )))

Сочетание этих трёх пунктов даёт вполне оригинальную концепцию. )

ARK>Кстати, было бы неплохо взглянуть на уродства Nim (кои у него, безусловно, есть).

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

По слухам там есть какие-то существенные извращения с именами переменных и пробельными символами... )))

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

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

ARK>Есть, к примеру, Eiffel, который уже 25 лет назад:
ARK>...
ARK>На фоне всего этого восторженные мнения о Nim вызывают в лучшем случае недоумение. А ведь есть и другие крутые продуманные языки, тот же Ceylon. Rust
_>>Сочетание этих трёх пунктов даёт вполне оригинальную концепцию. )
ARK>Мдя...

А в чём недоумение? Есть ли в Eiffel мощное метапрограммирование? Или лаконичный (Python-like) синтаксис у Rust?

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

EP>А в чём недоумение?

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

EP>Есть ли в Eiffel мощное метапрограммирование? Или лаконичный (Python-like) синтаксис у Rust?

Метапрограммирования и лаконичного синтаксиса нет. Но они не являются "абсолютным благом" (в отрыве от назначения языка). В концепцию Eiffel — надежное программирование по контракту — они просто не вписываются.

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

EP>>А в чём недоумение?
ARK>Недоумение в том, что неоригинальный, не содержащий ни одной новой (или реализованной на качественно ином уровне) фичи язык пытается претендовать на что-то.

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

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

ARK>Все это прикольно, но это, ИМХО, не киллер-фичи, а просто приятные вещи.

Киллер-фичей является сочетание всех этих возможностей в одном языке. )

ARK>Есть, к примеру, Eiffel, который уже 25 лет назад:
ARK>- точно так же, как и Nim, компилировался в оптимизированный С код;
ARK>- имел Design by contract (которого в нормальном виде нет нигде до сих пор);
ARK>- имел крутое множественное наследование (причем, ИМХО, лучшей реализации опять же нет до сих пор ни в одном языке);
ARK>- имел command-query separation principle на уровне языка;
ARK>- развивает простой и мощный подход к параллелизму — SCOOP;
ARK>- тонны других мелочей, строгий и последовательный синтаксис, ну и вообще Eiffel — один из самых продуманных языков, какие я знаю.

Нет, Eiffel не может сейчас претендовать на замену C++. Когда-то (при рождение) он ещё мог занять эту нишу, но не сложилось (так же как скажем и у Ada). А сейчас уже поздно. Потому что C++ — это мейнстрим и для его замены пойдёт только язык с как минимум теми же самыми возможностями, только сделанными по человечески. А Eiffel хотя и обладает множеством дополнительных возможностей (только кто сказал, что они нужны пользователям C++?), но не покрывает все возможности текущего C++.

Я уже писал, что претендентами на нишу C/C++ сейчас могут быть D, Rust, Nim, причём каждый подходит к этому со своей оригинальной стороны. Хотя пока что серьёзно заявить о себе (в смысле не пиара, а процентов популярности в реальных проектах) не удалось никому из них. Точнее до выхода C++11 язык D явно начал активно перехватывать аудиторию C++, но с выходом нового стандарта причин для перехода стало гораздо меньше, так что процесс похоже остановился. Вокруг Rust'а много разговоров (благодаря Mozilla), но это всё больше пиар, чем реальные проекты. Ну а Nim вообще в заднице даже на их фоне. )))

ARK>На фоне всего этого восторженные мнения о Nim вызывают в лучшем случае недоумение. А ведь есть и другие крутые продуманные языки, тот же Ceylon. Rust и безымянный C#-подобный язык от Joe Daffy — тоже мощные проекты с центральными идеями, вокруг которых построено все остальное.

Так Ceylon — это уже претендент на другую целевую нишу. На область энтерпрайзных языков, в которой сейчас царят Java/C#. Интересных претендентов на их замену естественно тоже не мало (скажем Scala/Nemerle), но они опять же пока не добились особо заметных успехов.

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

EP>>Есть ли в Eiffel мощное метапрограммирование? Или лаконичный (Python-like) синтаксис у Rust?

ARK>Метапрограммирования и лаконичного синтаксиса нет. Но они не являются "абсолютным благом" (в отрыве от назначения языка). В концепцию Eiffel — надежное программирование по контракту — они просто не вписываются.

Угу, только это вполне можно переформулировать совсем по другому: это Eiffel не вписывается в концепцию современного системного языка. ))) Разве что на специфическую узенькую его часть, и так уже занятую Ada. )))

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

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

Согласен. Как раз поэтому я пока даже "hello world" не пытался на нём написать. )

AB>А с инфраструктурой у nim все плохо. Я сначала много написал про свое первое знакомство с ним, потом удалил и решил написать проще — попробуй на CentOS 6 собрать, скажем, их же IDE Aporia по их же рекомендациям (используя последнюю версию языка и вот это все).

Не не не, никаких самодельных недо-IDE, вне зависимости от языка. Подобное всегда уродливо и не стоит даже пытаться смотреть на них. Только плагины к ведущим мировым IDE или редакторам. Ну и кстати у того же Nim с этим вроде (судя по документации) не так уж и плохо: https://github.com/nim-lang/Nim/wiki/editor-support — все главные редакторы и несколько ведущих IDE охвачены. Хотя я конечно же не проверял на практике реальную работоспособность данных плагинов.

Но я подозреваю, что про сборку ide ты написал не ради самой ide, а потому что при её сборке можно наткнуться на какие-то увлекательные квесты? )))

AB>А "врожденное уродство" в виде nimble я даже обсуждать не хочу — много раз обсуждалось на примере python pip, ruby gem, etc. Еще один подобный "уродец"? No Way!

Хех, тема пакетных менеджеров для программных библиотек или языков — это вообще отдельный большой вопрос. )

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

ARK>Ну, Nim-то вообще никуда не вписывается.

"Почти С++ с питоновским синтаксисом" — кому это нужно настолько, чтобы развивать это из нынешнего состояния?

Не, Nim то как раз отлично вписывается в нишу C++. Весь вопрос в том, настолько ли он при этом лучше C++, чтобы решаться на переход (теряя при этом бонусы мейнстрим языка). И вот в этом уже есть большие сомнения...

ARK>Если брать гипотетическую ситуацию, когда у Nim уже все есть на уровне С++ — проекты, community, библиотеки, литература — это другое дело. Только вот если бы это все магическим образом возникло для D, Eiffel, Rust, да даже для ~~розового слона~~ Nemerle — то и для них ситуация была бы качественно иная, и С++ пришлось бы очень-очень потесниться, а какие-то ниши покинуть совсем. Но толку-то от этих фантазий. А в текущей ситуации лично я не вижу ничего, чем Nim мог бы выделиться и заинтересовать широкие массы. Видимо, поэтому он в заднице и сидит.

Так а я нигде и не писал, что верю в светлое будущее Nim. ))) Что впрочем не делает саму концепцию языка хуже. )

Вообще после выхода C++11 и с учётом дальнейшей скорости развития (C++14, C++17 и т.п.), взятой комитетом, создаётся впечатление, что старичок C++ прошёл курс омоложения и планирует ещё попьянствовать на поминках своих молодых конкурентов. ))) Даже не знаю хорошо это или плохо — у меня двойственные ощущения. )

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

ARK> безымянный C#-подобный язык от Joe Daffy

M# он назывался.

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

EP>А в чём недоумение? Есть ли в Eiffel мощное метапрограммирование? Или лаконичный (Python-like) синтаксис у Rust?

У Rusta точно не python-like синтаксис. В Питоне упор на читаемость, а не лаконичность.

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

EP>>А в чём недоумение? Есть ли в Eiffel мощное метапрограммирование? Или лаконичный (Python-like) синтаксис у Rust?

SI_>У Rusta точно не python-like синтаксис.

О том и речь.

SI_>В Питоне упор на читаемость, а не лаконичность.

Упор да, но тем не менее лаконичность там тоже есть, как минимум по сравнению с другими mainstream языками.

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

MTD>Вполне секси, очень изящно можно использовать код на С, транслируется в него же. Какие же фатальные недостатки мешают ему стать популярным?

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

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

M>>По росту интереса (сообщества, книги, поделия, конференции и прочие смартконтракты

) у него стабильный рост.
_>Увы, с 2000-х стабильный рост кто только не показывал за последние лет 20. Имхо есть какой-то процент отчаянных (допустим 10%), которые готовы взяться за любой язык. И эта группа энтузиастов мечется кто куда — кто-то в Rust, кто-то в D, кто-то в Go, в Dart, в Haskell, Scheme, PHP, Ruby и т.п. В итоге в пределах мелких процентов экзотические языки показывают стабильный рост, а через несколько лет хайп переключается на кого-то новенького.

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

_>>а через несколько лет хайп переключается на кого-то новенького.
M>Ну давай так. Сколько в новостях было о чем-то написаном на D, Nim, Rust? Сколько новых книг было выпущено за последние три года по каждому языку?

Как-то много работы. Может ты начинай, а я подхвачу?

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

_>>>а через несколько лет хайп переключается на кого-то новенького.
M>>Ну давай так. Сколько в новостях было о чем-то написаном на D, Nim, Rust? Сколько новых книг было выпущено за последние три года по каждому языку?

_>Как-то много работы. Может ты начинай, а я подхвачу?
Ну давай начнем с книжек.

https://www.amazon.com/s/ref=sr_ex_n_1?rh=n%3A283155%2Cn%3A5%2Ck%3Arust&bbn=5&sort=date-desc-rank&keywords=rust&ie=UTF8&qid=1543951483

Manning еще в этом декабре обещал Rust In Action.

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

EP>Упор да, но тем не менее лаконичность там тоже есть, как минимум по сравнению с другими mainstream языками.

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

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

GIV>C++ конечно вечно молодой, но блин убивают меня такие темы http://rsdn.org/forum/cpp/7304124
Там ж правильно ответили: "ТС решал последствия отсутствия определения переменной через ~~задн~~ чёрный ход." (С) alexku

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

ARK>- тонны других мелочей, строгий и последовательный синтаксис, ну и вообще Eiffel — один из самых продуманных языков, какие я знаю.

Тогда что с ним не так? Должны же быть какие-то причины, почему на нем никто не пишет?

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

GIV>>C++ конечно вечно молодой, но блин убивают меня такие темы http://rsdn.org/forum/cpp/7304124
CC>Там ж правильно ответили: "ТС решал последствия отсутствия определения переменной через ~~задн~~ чёрный ход." (С) alexku

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

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

ARK>>- тонны других мелочей, строгий и последовательный синтаксис, ну и вообще Eiffel — один из самых продуманных языков, какие я знаю.

CM>Тогда что с ним не так? Должны же быть какие-то причины, почему на нем никто не пишет?

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

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

S>Для коммерческих, закрытых проектов, нужно покупать коммерческую лицензию. Цену на сайте они уже не озвучивают. Ранее было что-то порядка $8K за одного пользователя и за одну платформу. Т.е. если нужно было разрабатывать и под Win, и под Lin, то $16K на одного разработчика.

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

В наследниках ML(SML, F#, OCaml)-пробелы очень органичны. Если кто-то "нишмогла", то это его проблемы.
Мне вот F# отлично зашел в бекэнде, где soft real time не нужен.

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

H>В наследниках ML(SML, F#, OCaml)-пробелы очень органичны.

Вроде, из этих трех только у F# синтаксис чувствителен к отступам.
А еще в неупомянутых Хаскеле и Идрисе. И там вполне неплохо зашел.

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

H> MTD>Вполне секси, очень изящно можно использовать код на С, транслируется в него же. Какие же фатальные недостатки мешают ему стать популярным?
H> А язык тем временем развивается.

Что нового появилось за последнее время?

Бэкапимся на Яндекс.Диск

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

M>>>По росту интереса (сообщества, книги, поделия, конференции и прочие смартконтракты

) у него стабильный рост.
_>>Увы, с 2000-х стабильный рост кто только не показывал за последние лет 20. Имхо есть какой-то процент отчаянных (допустим 10%), которые готовы взяться за любой язык. И эта группа энтузиастов мечется кто куда — кто-то в Rust, кто-то в D, кто-то в Go, в Dart, в Haskell, Scheme, PHP, Ruby и т.п. В итоге в пределах мелких процентов экзотические языки показывают стабильный рост, а через несколько лет хайп переключается на кого-то новенького.
M>Ну давай так. Сколько в новостях было о чем-то написаном на D, Nim, Rust? Сколько новых книг было выпущено за последние три года по каждому языку? Сколько конференций было за последние два года? Ну и количество вакансий по каждому из.
M>И по какому из языков больше?

Мне кажется, что hi_octane имел в виду, что надо сравнивать D/Nim/Rust не между собой а с C/C++. Потому как совершенно не важно кто из этих троих претендентов сильнее, если при этом никто из них не способен выполнить главную миссию (заменить C++).

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

_>>1. Компиляция с помощью трансляции в оптимизированный C код. Соответственно поставив дальше в цепочке какой-нибудь gcc с правильными настройками оптимизации мы получим программу намного опережающую по быстродействию аналоги из D и Rust (на данный момент — когда-нибудь их компиляторы возможно и дойдут до уровня C/C++).
Pzz>Совершенно не обязательно. Когда язык более высокого уровня компилируется через язык более низкого уровня, то часть полезной для оптимизации информации при этой промежуточной перекомпиляции теряется.

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

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

Ха.

Столько кода пишется на Питоне и JS как раз потому, что для них написаны соответствующие C/C++ библиотеки, позволяющие одновременно писать на удобном язык и получать нормальное быстродействие.

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

Именно! Алгоритмы и структуры данных. Так вот структуры данных динамических языков в принципе не способны выдавать приемлемую производительность, в силу произвольности их содержимого (например массив может одновременно содержать и числа и строки и объекты). А вот если мы возьмём скажем библитечку numpy (которая позволила занять Питону лидирующее место у учёных, инженеров, аналитиков, специалистов по Machine Learning), то вот она уже позволяет реализовать приемлемое быстродействие, благодаря использованию правильных структур данных (по сути C массивы, в подходящем для SIMD виде). Ну и наверное не надо подсказывать на каком языке написана numpy? )))

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

Хы, скобки, отступы и т.п. — это всё мелкие вкусовые особенности и очевидно не они определяют особенности синтаксиса языка.

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

_>>1. Компиляция с помощью трансляции в оптимизированный C код. Соответственно поставив дальше в цепочке какой-нибудь gcc с правильными настройками оптимизации мы получим программу намного опережающую по быстродействию аналоги из D и Rust (на данный момент — когда-нибудь их компиляторы возможно и дойдут до уровня C/C++). Для языка претендующего на роль замены C/C++ это очень важный фактор. Ну и соответственно с поддерживаемыми платформами и библиотеками тоже всё хорошо.
vsb>Это не плюс, это в общем случае минус. Такой код не может быть быстрым.

Это очевидно не верно. Правильна формулировка могла бы быть такой: подобный код может быть не быстрым, при не правильной генерации.

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

vsb>В С можно скомпилировать что угодно. Так делают, когда хочется кроссплатформенности, но самому писать её не хочется.

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

vsb>Правильный способ это компилятор с LLVM. Компилировать в LLVM-байткод относительно несложно и это правильней, чем компилировать в С, а LLVM уже умеет все оптимизации.

С этим согласен. Хотя всё же замечу, что пока llvm уступает gcc в производительности даже на C/C++ коде. Но это в любом случае лучше всяческих самодельных оптимизаторов (причём даже с большой историей, типа C#).

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

_>Как у них особо не в курсе. А вот если в C++20/C++23 реализуют всё, что обещали, то сомневаюсь что у кого-то будут шансы... )))

так отож! даже 17 это уже прорывище

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

_>>>В общем это третий (после D и Rust) реальный претендент на замену устаревшего C++
ЛЧ>>эм... и че, как дела у этих реальных претендентов?

_>Как у них особо не в курсе. А вот если в C++20/C++23 реализуют всё, что обещали, то сомневаюсь что у кого-то будут шансы... )))

Макросов нормальных, хотя бы на уровне rust, не говоря уже о nim, в C++ нет и вряд-ли будут.
Метаклассы предложенные Саттером до нормальных макросов не дотягивают, да и с ними
скорее всего тянуть с принятием будут не меньше чем с концептами если вообще примут.

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

_>Мне кажется, что hi_octane имел в виду, что надо сравнивать D/Nim/Rust не между собой а с C/C++. Потому как совершенно не важно кто из этих троих претендентов сильнее, если при этом никто из них не способен выполнить главную миссию (заменить C++).

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

FR>Динамика популярности в Google Trends по ключевым словам "Rust, Nim, dlang"
FR>(По всему миру, 11.06.2016 – 06.12.2018) — https://g.co/trends/13dGn

Ну кто как умеет читать — такие опровержения и делает

Я написал что хайп вокруг очередного языка меняется с интервалом несколько лет. А ты это хочешь опровергнуть трендами за последние 2 года? Лол. Да, последние 2 года на хайпе rust. Потому что грабли которые там наверняка есть ещё не исследовали, legacy не набралось, восхвалительные посты ещё не уравновешены опытом реальной работы. Но борется вся эта толпа претендентов в своей нише в 10% от мэйнстрима с другими такими-же. Вот тебе сравнение чуть лучше — с 2006-го (меньше год гугл не дал выбрать) и на Rust, Haskell, Ruby, Ocaml, Scala:

https://trends.google.ru/trends/explore?date=all,all,all,all,all&geo=,,,,&q=%2Fm%2F0dsbpg6,%2Fm%2F03j_q,%2Fm%2F06ff5,%2Fm%2F09wmx,%2Fm%2F091hdj#TIMESERIES

Или вот с Эрлангом вместо Ruby (тоже от него кипятком писяли, каждый день то книжка то статья выходила о том как без эрланга ничего высоконагруженного не написать):

https://trends.google.ru/trends/explore?date=all,all,all,all,all&geo=,,,,&q=%2Fm%2F0dsbpg6,%2Fm%2F03j_q,%2Fm%2F09wmx,%2Fm%2F091hdj,%2Fm%2F02mm3#TIMESERIES

Обрати внимание как рост одних вызывает снижение других на практически те же цифры.

И я совершенно спокойно могу представить как rust плавненько заборет всю нишу "экзотики" и выйдет на те же (очень здоровые, кстати) размеры как и ruby в 2007-м. А что будет с ним дальше — хез. Скорее всего развитие языка начнёт подтормаживать из-за появления legacy, толпы энтузиастов найдут себе новый МЛЯ (мой-любимый-язык), и гуд-бай rust, здравствуй новый "blabl". Но эти явления надо изучать на периодах лет в 10, а не в 2-3 года. А сейчас rust огонь, я и сам на нём по мелочи пописываю, чтобы быть в форме к тому дню когда предложат "довести до ума один важный проект, за любые деньги"

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

_>Ну кто как умеет читать — такие опровержения и делает

Чукча писатель

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

Но на больших сроках тренд по rust даже лучше видно.

_>Я написал что хайп вокруг очередного языка меняется с интервалом несколько лет. А ты это хочешь опровергнуть трендами за последние 2 года? Лол. Да, последние 2 года на хайпе rust. Потому что грабли которые там наверняка есть ещё не исследовали, legacy не набралось, восхвалительные посты ещё не уравновешены опытом реальной работы. Но борется вся эта толпа претендентов в своей нише в 10% от мэйнстрима с другими такими-же. Вот тебе сравнение чуть лучше — с 2006-го (меньше год гугл не дал выбрать) и на Rust, Haskell, Ruby, Ocaml, Scala:

_>https://trends.google.ru/trends/explore?date=all,all,all,all,all&geo=,,,,&q=%2Fm%2F0dsbpg6,%2Fm%2F03j_q,%2Fm%2F06ff5,%2Fm%2F09wmx,%2Fm%2F091hdj#TIMESERIES

Вроде особых колебаний не видно, кроме Ruby конечно.

_>Или вот с Эрлангом вместо Ruby (тоже от него кипятком писяли, каждый день то книжка то статья выходила о том как без эрланга ничего высоконагруженного не написать):

_>https://trends.google.ru/trends/explore?date=all,all,all,all,all&geo=,,,,&q=%2Fm%2F0dsbpg6,%2Fm%2F03j_q,%2Fm%2F09wmx,%2Fm%2F091hdj,%2Fm%2F02mm3#TIMESERIES

_>Обрати внимание как рост одних вызывает снижение других на практически те же цифры.

А это не следствие нормировки графиков?
Пока я только увидел что Rust и Scala растут, остальные падают.

_>И я совершенно спокойно могу представить как rust плавненько заборет всю нишу "экзотики" и выйдет на те же (очень здоровые, кстати) размеры как и ruby в 2007-м. А что будет с ним дальше — хез. Скорее всего развитие языка начнёт подтормаживать из-за появления legacy, толпы энтузиастов найдут себе новый МЛЯ (мой-любимый-язык), и гуд-бай rust, здравствуй новый "blabl". Но эти явления надо изучать на периодах лет в 10, а не в 2-3 года. А сейчас rust огонь, я и сам на нём по мелочи пописываю, чтобы быть в форме к тому дню когда предложат "довести до ума один важный проект, за любые деньги"

Ну это нормально, любой график развития это S образная кривая.
Весь вопрос насколько высоко заберется.

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

_>>Как у них особо не в курсе. А вот если в C++20/C++23 реализуют всё, что обещали, то сомневаюсь что у кого-то будут шансы... )))
FR>Макросов нормальных, хотя бы на уровне rust, не говоря уже о nim, в C++ нет и вряд-ли будут.
FR>Метаклассы предложенные Саттером до нормальных макросов не дотягивают, да и с ними
FR>скорее всего тянуть с принятием будут не меньше чем с концептами если вообще примут.

Я бы разбил функциональность макросов на 3 логические части и обсудил их отдельно:

1. Анализ кода (передаваемого в макрос)
2. Какая-то логическая работа — собственно исполнение метапрограммы
3. Генерация нового кода, вставляемого по месту макроса

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

По второму пункту на каком-то минимальном уровне метапрограммирование на шаблонах было в C++ уже несколько десятилетий. И с каждым новым стандартом оно понемногу совершенствовалось. Кроме этого сейчас у нас есть уже полноценные constexpr функции, с не особо страшными ограничениями. А в C++20 наконец то появится (это уже точная информация) поддержка контейнеров (т.е. string, vector и т.п. работающие на этапе компиляции), что доведёт уровень метапрограммирования на шаблонах практически до уровня языка D, что уже очень не плохо. Причём благодаря появлению (в C++20 опять же) концептов, этот внутренний метаязык будет ещё и типизированным.

По третьему пункту опять же на простеньком уровне (работая по схеме "вставить или нет заранее подготовленный кусок кода") генерация кода через шаблоны существовала давным давно (тот же Boost.Spirit — это по сути генератор кода, управляемый специальным DSL). Сейчас её ещё упростили (static if и т.п.). Если введут метаклассы, то это вообще будет прорывом не просто в C++, а среди всех языков программирования, но я сильно сомневаюсь, что это случится в ближайшее время. Кроме метаклассов по генерации кода есть ещё много предложений, но пока нет ничего однозначно принимаемого. Лично я добавил бы функцию преобразования строки в код, как в языке D — это делается очень просто, никак не влияет на другие части языка и может быть очень эффективно использовано как раз с приходом C++20 (и строк времени компиляции в нём).

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

_>>Мне кажется, что hi_octane имел в виду, что надо сравнивать D/Nim/Rust не между собой а с C/C++. Потому как совершенно не важно кто из этих троих претендентов сильнее, если при этом никто из них не способен выполнить главную миссию (заменить C++).
FR>Они не смогут заменить С++.

Эти трое скорее всего действительно не смогут. Но мы то как раз ждём язык способный заменить! Потому как даже при всех последних улучшениях называть C++ приятным языком вряд ли можно. Он лучший в своей области, но при этом ужасен. А хотелось бы что-то приятное... )))

FR>Но откусить свою долю, хотя бы на уровне того же Go или Scala вполне способны.
FR>Самые лучшие шансы у Rust, так как он конкурент не только С++ но и чистому Си.

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

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

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

В D же это давно реализовано, могли бы и спереть

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

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

Да новые версии C++ больнее всего бьют по D. Так скоро и все фичи оттуда перетаскают

Ну и даже при таком уровне это будет слабее чем с полноценными макросами.

_>По третьему пункту опять же на простеньком уровне (работая по схеме "вставить или нет заранее подготовленный кусок кода") генерация кода через шаблоны существовала давным давно (тот же Boost.Spirit — это по сути генератор кода, управляемый специальным DSL). Сейчас её ещё упростили (static if и т.п.). Если введут метаклассы, то это вообще будет прорывом не просто в C++, а среди всех языков программирования, но я сильно сомневаюсь, что это случится в ближайшее время. Кроме метаклассов по генерации кода есть ещё много предложений, но пока нет ничего однозначно принимаемого. Лично я добавил бы функцию преобразования строки в код, как в языке D — это делается очень просто, никак не влияет на другие части языка и может быть очень эффективно использовано как раз с приходом C++20 (и строк времени компиляции в нём).

Да миксины D это круто, если не видел нормальные макросы.
Метаклассы никакой ни прорыв, а так бледное подобие нормальных макросов

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

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

_>Эти трое скорее всего действительно не смогут. Но мы то как раз ждём язык способный заменить! Потому как даже при всех последних улучшениях называть C++ приятным языком вряд ли можно. Он лучший в своей области, но при этом ужасен. А хотелось бы что-то приятное... )))

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

FR>>Но откусить свою долю, хотя бы на уровне того же Go или Scala вполне способны.
FR>>Самые лучшие шансы у Rust, так как он конкурент не только С++ но и чистому Си.

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

За приятным синтаксисом это к Nim, несколько лет назад немного пописал, очень понравилось.

А вообще синтаксис тупо вопрос привычки, да и у Rust эта цена плюс-минус одинаковая с C++.
А если хоть немного писал на OCaml так вообще синтаксис Rust уже приятнее чем у C++

.
Тоже сейчас играюсь с rust и кроме borrow checker от которого мозги страшно скрипят,
ничего страшного почему-то не вижу, наоборот одни приятности и паттерн матчинг и вывод
типов и макросы да и даже его недообъекты и плюс отдельно crate.

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

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

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

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

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

Здравствуйте, 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 (ну и всё остальное, что осуществляет его поддержку в языке) и имел в виду тут. Только он меня больше раздражает не за "скрип мозгов", а за большое количество мусорного кода.

Здравствуйте, 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, Вы писали:

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

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

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

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

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

Здравствуйте, 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.

Здравствуйте, 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. Если говорить из других языков, то даже не знаю... Ну наверное продвинутое сопоставление с образцом (pattern matching) не помешало бы. Может ещё что, так навскидку трудно сказать)

Здравствуйте, 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 вычисления.

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

MTD>Вполне секси, очень изящно можно использовать код на С, транслируется в него же. Какие же фатальные недостатки мешают ему стать популярным?

Прочитал весь топик. Решил посмотреть, о чем вообще речь — Nim, Go, Rust...

На работе некоторые коллеги подрачивают на раст, решил начать с него.

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

Скучно. Скучно и уныло. И что, вот на таких вот языках сейчас всё (или большую часть) продакшена пишут?

ЗЫ На что только люди не пойдут, лишь бы не изучать плюсики

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

M>Прочитал весь топик. Решил посмотреть, о чем вообще речь — Nim, Go, Rust...

Только всё же Rust, D, Nim, если смотреть по порядку популярности... А вот Go не из этой песочницы — это управляемый язык, так что заменой C++ не может служить в принципе.

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

Хы, ну типизации там не чутка, а побольше чем в C++. Причём настолько, что становится уже неудобно писать... )

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

_>Только всё же Rust, D, Nim, если смотреть по порядку популярности... А вот Go не из этой песочницы — это управляемый язык, так что заменой C++ не может служить в принципе.

Почему не может?

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

_>Хы, ну типизации там не чутка, а побольше чем в C++. Причём настолько, что становится уже неудобно писать... )

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

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

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

_>Ха))) Зато если код на Rust всё же заставить скомпилироваться, то можно быть уверенным, что он будет работать правильно (во всяком случае в работе с памятью).

Вроде еще где-то проскакивала информация, что гарантия не только по памяти, что сравнительно легко достигается в C++ если писать с нуля, но ещё и гарантия по дедлокам, что уже реально выглядит как фича-убийца.

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

_>Ничего даже близкого там нет. Есть только простейшая возможность обеспечить гарантированно не одновременный доступ на запись к одной области памяти из нескольких потоков. https://doc.rust-lang.org/nomicon/races.html

ааа, это банальные атомарные операции, я почему-то ожидал чего-то сопоставимого с гарантиями по памяти

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

Да, жаль, конечно

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

_>Кстати, могу рассказать некий забавный момент. Я был знаком с парочкой 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/) почти по теме. Хотя там уже не про "мусорный код", а про архитектурные проблемы, но и то и то происходит из одной первопричины — излишнее переусложнее базовой концепции.
Тут скорее недоусложнение.
Они пытаются на этапе компиляции определить момент удаления каждого объекта. Делают они это при помощи построения дерева владения.

Проблема в том, что в реальности нужно отслеживать время жизни групп объектов.
Например, результат работы парсера нитры является кучей связанных объектов.
Причем в общем случае невозможно определить дерево владения.
При этом для нормальной работы с результатом нужна вся куча. А после того как результат стал не нужен все объекты нужно одновременно удалить.

А в совсем клинических случаях нужен ГЦ. Чтобы он не мешал нужно разделять программу на легковесные процессы, что позволит собирать мусор в каждом процессе отдельно.
Причем по умолчанию ГЦ можно выключить. И по желанию программиста либо включить в автоматически режиме. Либо запускать вручную в те моменты, когда известно, что большая часть мусора была зачищена детерминированным удалением.

Ещё одна проблема, которая у них появилась это простота реализации деструктора в каждом объекте. Null тоже появился по тому что было легко сделать. А теперь всем очевидно, что это зло.
Нужно на уровне системы типов разделять объекты с деструкторами и все остальные.
Практика показывает, что это вполне возможно. В .НЕТ хоть и нет поддержки этого на уровне системы типов. Но на уровне соглашений такое разделение есть. И оно мне ни разу не мешало.

Их желание сделать код, в котором гарантированно не будет паники похвально, но боюсь, что тут понадобится что-то типа https://github.com/Microsoft/dafny
Более простые решения работать не будут.
Кроме того для не паникующих функций придётся сделать запрет на выделение памяти и определить максимальный размер стека который нужно будет проверять при вызове не паникующего кода из паникующего. Ибо нехватка памяти и переполнение стека это паника.
Короче для простого кода ограничения слишком сильные. Но для низкоуровневых библиотечных выкрутасов вполне адекватны.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

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

А что это такое? В расте, как я понял, это тупой кейс по типу union'а (в плюсах было бы отдельное поле typeTag и по нему бы был case).

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

_>Хотя если у тебя есть время, то советовал бы глянуть с начала, чтобы сравнить с аналогичной реализацией в D (особенно про GPU наверное интересно будет).
По сравнению с этим http://halide-lang.org/ ренжи детский сад ясельная группа.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

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

Что это даст?

WH>Кроме того для не паникующих функций придётся сделать запрет на выделение памяти и определить максимальный размер стека который нужно будет проверять при вызове не паникующего кода из паникующего. Ибо нехватка памяти и переполнение стека это паника.

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

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

WH>>Нужно на уровне системы типов разделять объекты с деструкторами и все остальные.
ARK>Что это даст?
Позволит удалять объекты пачками, не разбираясь, что там.
Пять пример с тем же результатом работы парсера.
Там вполне может быть клубок из десятков тысяч объектов. Расту придётся при удалении этих объектов потрогать каждый объект чтобы вызвать все деструкторы.
Но там нет деструкторов. Там только память, которую нужно освободить. И если компилятор об этом знает, то он выделит память для этих объектов в одной куче. После чего удалит всю кучу которая состоит из нескольких блоков размером десятки или сотки килобайт.

И что характерно я вообще не могу вспомнить ситуацию, когда объект с деструктором, который делает что-то кроме удаления памяти, был бы не на стеке. Максимум что приходит в голову тонкая обёртка.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

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

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

M>А что это такое? В расте, как я понял, это тупой кейс по типу union'а (в плюсах было бы отдельное поле typeTag и по нему бы был case).

Как на плюсах написать выделенное жирным?

struct Point {
    x: i32,
    y: i32,
}

fn main() {
    let p = Point { x: 0, y: 7 };
    let Point { x, y } = p;
    assert_eq!(0, x);
    assert_eq!(7, y);
}

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

_>>Ну наверное продвинутое сопоставление с образцом (pattern matching) не помешало бы. Может ещё что, так навскидку трудно сказать)
M>А что это такое? В расте, как я понял, это тупой кейс по типу union'а (в плюсах было бы отдельное поле typeTag и по нему бы был case).

В C++ более менее неплохое сопоставление с образом можно организовать с помощью этой https://github.com/solodon4/Mach7 библиотечки.

Так же с приходом последнего стандарта появилась возможность сделать такой https://en.cppreference.com/w/cpp/utility/variant/visit (см. пример) забавный хак, который по сути является одним из видов сопоставления с образцом.

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

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

_>>Ничего даже близкого там нет. Есть только простейшая возможность обеспечить гарантированно не одновременный доступ на запись к одной области памяти из нескольких потоков. https://doc.rust-lang.org/nomicon/races.html
KP>ааа, это банальные атомарные операции, я почему-то ожидал чего-то сопоставимого с гарантиями по памяти

Ну по смыслу это скорее напоминает shared_ptr со встроенным автоматическим мьютексом, но в любом случае ничего нового там нет. Всё это давным давно используется во множестве языков и библиотек.

_>>Насколько малый процент всех возможных случаев возникновения дедлоков покрывает данное решение, думаю ты и сам прекрасно представляешь...
KP>Да, жаль, конечно

Кое-какие продвижения в данной области наблюдаются как раз в C++ (http://clang.llvm.org/docs/ThreadSafetyAnalysis.html) и помнится ещё в Go что-то было на эту тему. Но в общем случае задача естественно не имеет автоматического решения.

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

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

WH>Лично я предпочту повоевать с системой типов но иметь железные гарантии того что ничего плохого не случится.

Ну это дело вкуса. Кстати, а ты хоть где-нибудь скриптовые языки используешь? )

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

Если бы только это, то никаких проблем бы не было — такое уже прямо сейчас в C++ работает и не привносит никаких проблем. А в Rust'е всё гораздо сложнее.

WH>Проблема в том, что в реальности нужно отслеживать время жизни групп объектов.
WH>Например, результат работы парсера нитры является кучей связанных объектов.
WH>Причем в общем случае невозможно определить дерево владения.
WH>При этом для нормальной работы с результатом нужна вся куча. А после того как результат стал не нужен все объекты нужно одновременно удалить.

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

Если второе, то это элементарно реализуется например в C++ с помощью кастомного аллокатора на пуле (после использования просто убиваешь пул и всё). Однако если ты тут ошибёшься (объект из пула будет связан с кем-то снаружи), то после удаления пула у тебя могут возникнуть проблемы.

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

WH>Ещё одна проблема, которая у них появилась это простота реализации деструктора в каждом объекте. Null тоже появился по тому что было легко сделать. А теперь всем очевидно, что это зло.
WH>Нужно на уровне системы типов разделять объекты с деструкторами и все остальные.
WH>Практика показывает, что это вполне возможно. В .НЕТ хоть и нет поддержки этого на уровне системы типов. Но на уровне соглашений такое разделение есть. И оно мне ни разу не мешало.

Это ещё зачем? Архитектурно в этом нет никакого смысла — будут недостатки от обеих существующих схем (с RAII или без).

WH>Их желание сделать код, в котором гарантированно не будет паники похвально, но боюсь, что тут понадобится что-то типа https://github.com/Microsoft/dafny
WH>Более простые решения работать не будут.
WH>Кроме того для не паникующих функций придётся сделать запрет на выделение памяти и определить максимальный размер стека который нужно будет проверять при вызове не паникующего кода из паникующего. Ибо нехватка памяти и переполнение стека это паника.
WH>Короче для простого кода ограничения слишком сильные. Но для низкоуровневых библиотечных выкрутасов вполне адекватны.

Это да.

А вообще говоря не вижу ничего плохого в паниках/исключениях в случае проблем с памятью и т.п. — это вполне себе правильное решение, т.к. в такой ситуации программе практически гарантированно положено "скончаться". ) Это как раз тот самый случай, когда подход исключений уместен, в отличие от многих других мест, в которые их частенько суют.

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

WH>Проблема в том, что в реальности нужно отслеживать время жизни групп объектов.

Это же в Расте есть — через lifetime annotations.

WH>Их желание сделать код, в котором гарантированно не будет паники похвально, но боюсь, что тут понадобится что-то типа https://github.com/Microsoft/dafny

В статье такого желания я не заметил. Было желание получить корректный код при наличии возможных паник.

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

WH>А в совсем клинических случаях нужен ГЦ. Чтобы он не мешал нужно разделять программу на легковесные процессы, что позволит собирать мусор в каждом процессе отдельно.
WH>Причем по умолчанию ГЦ можно выключить. И по желанию программиста либо включить в автоматически режиме. Либо запускать вручную в те моменты, когда известно, что большая часть мусора была зачищена детерминированным удалением.
Вот этот момент я не понял. В чём смысл приседать с детерминированным удалением мусора до вызова GC, если время работы GC зависит только от объёма живых объектов? Вроде бы, наоборот — GC надо запускать тогда, когда мы знаем, что живых осталось мало.

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

S>Вот этот момент я не понял. В чём смысл приседать с детерминированным удалением мусора до вызова GC, если время работы GC зависит только от объёма живых объектов? Вроде бы, наоборот — GC надо запускать тогда, когда мы знаем, что живых осталось мало.
Детерминированное удаление всё равно быстрее и имеет намного меньшую латентность.

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

WH>>Проблема в том, что в реальности нужно отслеживать время жизни групп объектов.
DM>Это же в Расте есть — через lifetime annotations.
Нету. Если бы было, то этой статьи бы не было.
Просто по тому, что если бы отслеживалась жизнь группы объектов, то вот этот код

    self.chain = Chain::with(self.chain);

прямо в таком виде бы и заработал.

DM>В статье такого желания я не заметил. Было желание получить корректный код при наличии возможных паник.

The most obvious change is that we could plausibly extend the borrow checker to permit moves out of an &mut, so long as the value is guaranteed to be replaced before the function returns or panics. The “or panics” bit is the tricky part, of course.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

_>Ну это дело вкуса. Кстати, а ты хоть где-нибудь скриптовые языки используешь? )
Только если другого выхода нет.

_>Если бы только это, то никаких проблем бы не было — такое уже прямо сейчас в C++ работает и не привносит никаких проблем. А в Rust'е всё гораздо сложнее.
Вся сложность в гарантии отсутствия висящих ссылок.

_>Если же ты хочешь систему, которая сама будет отслеживать все связи и гарантированно разделять (на этапе компиляции) объекты на независимые группы для удаления, то думаю от такого бы никто не отказался. Но у меня есть большие сомнения в реализуемости подобного.
А у меня нет.
Re: Мысли о эффективном автоматическом управлении памятью
Re[2]: Мысли о эффективном автоматическом управлении памятью
Re[2]: Мысли о эффективном автоматическом управлении памятью
Re[2]: Мысли о эффективном автоматическом управлении памятью
При этом подход раста и данная система не противоречат друг другу. И их можно объедение, получив более мощную и гибкую систему, чем каждая из них по отдельности.

_>Это ещё зачем? Архитектурно в этом нет никакого смысла — будут недостатки от обеих существующих схем (с RAII или без).
За тем, что просто удалять память намного проще чем удалять память, вызывая при этом, какой то код.
И недостатков я не вижу. Попробуй придумать сценарий, в котором объект с дуструктором должен быть вне стека.

_>А вообще говоря не вижу ничего плохого в паниках/исключениях в случае проблем с памятью и т.п. — это вполне себе правильное решение, т.к. в такой ситуации программе практически гарантированно положено "скончаться". ) Это как раз тот самый случай, когда подход исключений уместен, в отличие от многих других мест, в которые их частенько суют.
Обработку ошибок нужно делать, как описано в этой статье.
http://joeduffyblog.com/2016/02/07/the-error-model/

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

_>Эм, и как ты вообще можешь сравнивать некую абстрактную концепцию работы с коллекциями (следующий уровень абстракции над понятием итератор) с отдельным специализированным языком, заточенным на решение SIMD задач? Между ними если и будет когда-то какая-то связь, то исключительно "дружеская" (скажем можно будет написать на Halide какой-то алгоритм, работающий с данными в виде диапазонов) и уж точно не "конкуренция".
Если мы говорим про засунуть код в GPU, то они решают одну и ту же исходную задачу. Только Halide намного мощнее.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

WH>>>Проблема в том, что в реальности нужно отслеживать время жизни групп объектов.
DM>>Это же в Расте есть — через lifetime annotations.
WH>Нету.

Есть. Ибо что такое lifetime annotations, как не оно?

WH>Если бы было, то этой статьи бы не было.
WH>Просто по тому, что если бы отслеживалась жизнь группы объектов, то вот этот код
WH>

WH>    self.chain = Chain::with(self.chain);
WH>

WH>прямо в таком виде бы и заработал.

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

Здравствуйте, WolfHound, Вы писали:
WH>Детерминированное удаление всё равно быстрее и имеет намного меньшую латентность.
Продолжаю непонимать. Речь об освобождении памяти, или о финализации?
Если первое — то детерминированное освобождение всегда медленнее.

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

_>

_>И к сопоставлению с образом это не имеет ни малейшего отношения. )

Destructuring assignment это основа pattern matching.

Вот документация pattern matching для Erlang: http://erlang.org/doc/reference_manual/patterns.html , тут мы видим, что pattern matching-ом прямо называется deconstructing assignment.

Вот для Rust: https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html#destructuring-to-break-apart-values , тут deconstructing assignment описывается как часть механизма pattern matching

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

_>Данный код записывается на C++ буквально так:
_>

_>struct Point {
_>        int32_t x;
_>        int32_t y;
_>};

_>int main()
_>{
_>    auto p=Point{0, 7};
_>    auto [x, y]=p;
_>    assert(0==x);
_>    assert(7==y);
_>}
_>

Ок, совсем недавно появилось. Но судя по proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0144r0.pdf это предназначено для простейших случаев, и что-то чуть более сложное, как в коде ниже, сделать уже невозможно. И, кроме того, полноценного pattern matching в c++, все-равно так и не появилось.

#[allow(dead_code)]
struct Point {
    x: i32,
    y: i32,
}

#[allow(dead_code)]
struct Color {
    r: u8,
    g: u8,
    b: u8
}

#[allow(dead_code)]
struct ColoredPoint {
    p: Point,
    c: Color,
}

fn main() {
  let p = Point { x: 0, y: 7 };
  let c = Color {r: 255, g: 1, b: 1};
  let cp = ColoredPoint {p: p, c: c};
  
  let ColoredPoint {p: _, c: Color{r: red, g: _, b: _}} = cp;
  
  println!("Red color: {}", red);
}

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

_>Так что утверждать что-то наподобие "И к сопоставлению с образом это не имеет ни малейшего отношения", по меньшей мере, безграмотно. И посмеяться можно в сторону этого утверждения.

Скажите, а вы специально такие убогие примеры приводите? Казалось бы, можно было бы взять пример Rust-овского enum-а (да хоть тот же готовый Result или Option) и инструкцию match.

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

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

_>>Так что утверждать что-то наподобие "И к сопоставлению с образом это не имеет ни малейшего отношения", по меньшей мере, безграмотно. И посмеяться можно в сторону этого утверждения.

S>Скажите, а вы специально такие убогие примеры приводите? Казалось бы, можно было бы взять пример Rust-овского enum-а (да хоть тот же готовый Result или Option) и инструкцию match.

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

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

WH>>Детерминированное удаление всё равно быстрее и имеет намного меньшую латентность.
S>Продолжаю непонимать. Речь об освобождении памяти, или о финализации?
Финализация мешает удалять объекты пачками.

S>Если первое — то детерминированное освобождение всегда медленнее.
В теории. А на практике грамотно сделанное детерминированное удаление всегда быстрее.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

DM>Есть. Ибо что такое lifetime annotations, как не оно?
Оно вообще за время жизни объектов не отвечает.
Оно отвечает за удаление всех не владеющих ссылок на объект до того как будет удалена владеющая.
А за время жизни объекта отвечает владеющая ссылка, которая в расте существует в единственном экземпляре.
Это ограничивает структуру владения деревом.

DM>Прямо в таком и не должен, а если правильно расставить аннотации, то может и заработает.
Удачи.

DM>Или не заработает, ты сперва обоснуй, почему именно он должен заработать.
В расте не должен.
Для того чтобы он заработал нужно иметь как минимум две владеющие ссылки на объект.
Что в системе типов раста невозможно.
А вот в этой системе типов такое делается без проблем.

Причём обе системы типов можно подружить.
Для объектов с деструкторами деревянное владение. Как врасте.
Для всех остальных объектов кластерное. Как в моей системе типов.
И для не владеющих ссылок борроучекер.

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

S>>можно было бы взять пример Rust-овского enum-а (да хоть тот же готовый Result или Option) и инструкцию match.

_>Скажите, а вы специально такими бессодержательными претензиями на форуме раскидываетесь? Казалось бы, можно было что-то конструктивное написать.

Конструктивное как раз и было написано. Предложили бы на C++ написать что-то вроде:

match some_optional {
  Some(v) => ... // Some action on v.
  _ => return
}

Здравствуйте, WolfHound, Вы писали:
WH>Финализация мешает удалять объекты пачками.
Это понятно. Непонятно, про какой случай идёт речь — про финализацию или её отсутствие.

WH>В теории. А на практике грамотно сделанное детерминированное удаление всегда быстрее.
Непонятно, как можно быть меньше, чем 0.

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

_>>

_>>И к сопоставлению с образом это не имеет ни малейшего отношения. )
_>Destructuring assignment это основа pattern matching.

Т.е. по твоему все языки с возможностью деструктурирующего присваивания (а это и JS и Python и ещё множество других) автоматически обладают и сопоставлением с образцом? ))) У тебя похоже какое-то очень убогое представление о последнем... )

_>Вот документация pattern matching для Erlang: http://erlang.org/doc/reference_manual/patterns.html , тут мы видим, что pattern matching-ом прямо называется deconstructing assignment.

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

_>Вот для Rust: https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html#destructuring-to-break-apart-values , тут deconstructing assignment описывается как часть механизма pattern matching

Всё с точность до наоборот. Сопоставление с образцом (причём в самом тривиальном его виде) может быть использовано в Rust'е для осуществления механизма деструкции. И кстати именно так написано по твоей же ссылке — ты вообще сам читал то, на что ссылаешься? )))

Однако сопоставление с образцом — это далеко не единственный способ реализации деструктурирующего присваивания, что демонстрирует целый ряд языков.

_>Так что утверждать что-то наподобие "И к сопоставлению с образом это не имеет ни малейшего отношения", по меньшей мере, безграмотно. И посмеяться можно в сторону этого утверждения.

Это смотря в каком языке. )

_>>Данный код записывается на C++ буквально так:
_>>

_>>struct Point {
_>>        int32_t x;
_>>        int32_t y;
_>>};

_>>int main()
_>>{
_>>    auto p=Point{0, 7};
_>>    auto [x, y]=p;
_>>    assert(0==x);
_>>    assert(7==y);
_>>}
_>>

_>Ок, совсем недавно появилось. Но судя по proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0144r0.pdf это предназначено для простейших случаев, и что-то чуть более сложное, как в коде ниже, сделать уже невозможно.

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

_>И, кроме того, полноценного pattern matching в c++, все-равно так и не появилось.

Полноценное сопоставление с образом без проблем реализуется в C++ например с помощью этой https://github.com/solodon4/Mach7 библиотечки. И это гораздо более мощная вещь чем структурное связывание, но при этом нужная гораздо реже.

смешной код

_>#[allow(dead_code)]
_>struct Point {
_>    x: i32,
_>    y: i32,
_>}

_>#[allow(dead_code)]
_>struct Color {
_>    r: u8,
_>    g: u8,
_>    b: u8
_>}

_>#[allow(dead_code)]
_>struct ColoredPoint {
_>    p: Point,
_>    c: Color,
_>}

_>fn main() {
_>  let p = Point { x: 0, y: 7 };
_>  let c = Color {r: 255, g: 1, b: 1};
_>  let cp = ColoredPoint {p: p, c: c};
  
_>  let ColoredPoint {p: _, c: Color{r: red, g: _, b: _}} = cp;
  
_>  println!("Red color: {}", red);
_>}
_>

Мдаа, ты снова умудрился показать не сопоставление с образцом, а какую-то ненужную ерунду. А всего то стоило проставить значение у какой-нибудь из переменных в образце (как в примере на Эрланге или в примере 18-14 на Расте). Я начинаю думать, что ты реально не понимаешь смысл технологии сопоставления с образцом.

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

_>Полноценное сопоставление с образом без проблем реализуется в C++ например с помощью этой https://github.com/solodon4/Mach7 библиотечки. И это гораздо более мощная вещь чем структурное связывание, но при этом нужная гораздо реже.

_>

смешной код

_>>

_>>#[allow(dead_code)]
_>>struct Point {
_>>    x: i32,
_>>    y: i32,
_>>}

_>>#[allow(dead_code)]
_>>struct Color {
_>>    r: u8,
_>>    g: u8,
_>>    b: u8
_>>}

_>>#[allow(dead_code)]
_>>struct ColoredPoint {
_>>    p: Point,
_>>    c: Color,
_>>}

_>>fn main() {
_>>  let p = Point { x: 0, y: 7 };
_>>  let c = Color {r: 255, g: 1, b: 1};
_>>  let cp = ColoredPoint {p: p, c: c};
  
_>>  let ColoredPoint {p: _, c: Color{r: red, g: _, b: _}} = cp;
  
_>>  println!("Red color: {}", red);
_>>}
_>>

_>Мдаа, ты снова умудрился показать не сопоставление с образцом, а какую-то ненужную ерунду. А всего то стоило проставить значение у какой-нибудь из переменных в образце (как в примере на Эрланге или в примере 18-14 на Расте). Я начинаю думать, что ты реально не понимаешь смысл технологии сопоставления с образцом.

Когда на плюсах реализуешь этот "смешной код", тогда и поговорим.
А паттерн матчинг ~~из говна и палок~~ на текстовом препроцессоре это действительно смешно.

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

WH>>В теории. А на практике грамотно сделанное детерминированное удаление всегда быстрее.
S>Непонятно, как можно быть меньше, чем 0.
Ты не посчитал количество вызовов ГЦ. А это весьма дорогая процедура.
В случае с детерминированным удалением в большинстве случаев их вообще не будет.
А в тех случаях, когда без ГЦ никак их будет намного меньше.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

Здравствуйте, WolfHound, Вы писали:
WH>Ты не посчитал количество вызовов ГЦ. А это весьма дорогая процедура.
WH>В случае с детерминированным удалением в большинстве случаев их вообще не будет.
WH>А в тех случаях, когда без ГЦ никак их будет намного меньше.
Во-первых, это опять зависит от количества удаляемых обьектов.
Во-вторых, чтобы обеспечить уменьшение вызовов ГЦ, нам нужно научиться выполнять выделение на reclaimed памяти, а это — удорожание каждого выделения. Ведь в чисто-GC сценарии выделение стоит O(1) и с очень небольшой константой.
Я сходу даже не рискну написать неравенство, чтобы прикинуть соотношение параметров, при котором детерминированное удаление будет в целом быстрее.

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

KP>Вроде еще где-то проскакивала информация, что гарантия не только по памяти, что сравнительно легко достигается в C++ если писать с нуля, но ещё и гарантия по дедлокам, что уже реально выглядит как фича-убийца.

Гарантия дедлоков эквивалентна проблеме останова со всеми вытекающими

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

_>>Эм, и как ты вообще можешь сравнивать некую абстрактную концепцию работы с коллекциями (следующий уровень абстракции над понятием итератор) с отдельным специализированным языком, заточенным на решение SIMD задач? Между ними если и будет когда-то какая-то связь, то исключительно "дружеская" (скажем можно будет написать на Halide какой-то алгоритм, работающий с данными в виде диапазонов) и уж точно не "конкуренция".
WH>Если мы говорим про засунуть код в GPU, то они решают одну и ту же исходную задачу. Только Halide намного мощнее.

В приведённой презентации (ты похоже её даже не посмотрел) вообще не было собственно GPU кода. Там речь шла о том, что если вдруг потребуется написать подобный код, то он отлично интегрируется в конвейер обработки данных на Ranges.

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

_>>Это ещё зачем? Архитектурно в этом нет никакого смысла — будут недостатки от обеих существующих схем (с RAII или без).
WH>За тем, что просто удалять память намного проще чем удалять память, вызывая при этом, какой то код.
WH>И недостатков я не вижу. Попробуй придумать сценарий, в котором объект с дуструктором должен быть вне стека.

Смотри, единственным недостатком классического подхода RAII в данном контексте является вроде как медленное освобождение памяти, из-за того, что для каждого объекта вызывается его деструктор. Но в реальности для большинства кода (при правильной современной архитектуре) это не так: если ты будешь хранить в каком-нибудь std::vector набор структур с пустым деструктором, то при удаление этого вектора оптимизатор вырежет не только вызов к пустой функции, но и вообще весь этот цикл. Ненужное (когда деструктор не делает ничего полезного, но всё равно вызывается) замедление возможно только в случае использования полиморфных объектов с виртуальными деструкторами.

В то же время предложенный тобой вариант будет эффективно работать только в том случае, если на уровне типов запретить выделять в данном пуле (или GC, не суть) память для объектов с деструкторами. Т.е. этот метод уже не будет работать для тех областей кода, в которых нам нужны объекты обоих типов (с RAII и без — ты же хотел поддерживать и тех и тех, правильно?), т.к. проверка на тип объекта будет даже медленнее чем обращение к пустому виртуальному деструктору.

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

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

_>В приведённой презентации (ты похоже её даже не посмотрел) вообще не было собственно GPU кода. Там речь шла о том, что если вдруг потребуется написать подобный код, то он отлично интегрируется в конвейер обработки данных на Ranges.
Я всё посмотрел.
Но ты подменяешь задачу одним из возможных решений.
Если у нас встал вопрос с GPU значит изначальная задача: быстро перемолотить большую пачку данных.
А это означает, что нужно сразу брать правильный инструмент.
Ибо данная библиотека в самом лучшем для неё случае сыграет с Halide в ничью.
Просто по тому, что Halide позволяет задавать план исполнения руками.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

_>Смотри, единственным недостатком классического подхода RAII в данном контексте является вроде как медленное освобождение памяти, из-за того, что для каждого объекта вызывается его деструктор. Но в реальности для большинства кода (при правильной современной архитектуре) это не так:
И что это за правильная архитектура такая?

_>В то же время предложенный тобой вариант будет эффективно работать только в том случае, если на уровне типов запретить выделять в данном пуле (или GC, не суть) память для объектов с деструкторами. Т.е. этот метод уже не будет работать для тех областей кода, в которых нам нужны объекты обоих типов (с RAII и без — ты же хотел поддерживать и тех и тех, правильно?), т.к. проверка на тип объекта будет даже медленнее чем обращение к пустому виртуальному деструктору.
1)Все проверки в моём варианте исключительно статические. Соответственно скорость работы в самом худшем случае будет как у rust'а.
2)В моём варианте память это не ресурс. Соответственно объектов с деструктором становится примерно 0. Сколько я писал на .НЕТ IDisposable был реализован у ничтожного количества объектов.
И я ни разу не хранил такие объекты. 100% случаев выглядело примерно так.

      using (StreamReader sr = new StreamReader(filename))
      {
         txt = sr.ReadToEnd();
      }

_>По сумме этих двух пунктов, получаем что предложенный подход (с одновременным использованием объектов с RAII и без, разделяемых системой типов) будет иметь какие-то преимуществ в быстродействие на столько ничтожном проценте возможных задач, что нет никакого смысла в его реализации.
Ты очень сильно недооцениваешь количество сценариев, где мой подход будет работать.
Например, почти любой парсинг. После разбора мы получаем некую структуру, которая состоит из кучи гетерогенных объектов связанных между собой. Далее почти всегда мы эту структуру только читаем. И после окончания работы всю структуру разом грохаем.
Другой пример формирование запроса к БД. Сначала мы формируем АСТ запроса, оптимизируем его, потом формируем SQL для БД. После чего нам АСТ и ошмётки оптимизации этого АСТ не нужны. Их можно разом грохнуть.

А теперь ты покажи задачу, в которой нужно хранить объект с деструктором не на стеке.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Гарантия дедлоков эквивалентна проблеме останова со всеми вытекающими
Но, как и в случае с остановкой программы есть варианты, допускающие ложноположительные срабатывания и не допускающие ложноотрицательные.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

_>>В приведённой презентации (ты похоже её даже не посмотрел) вообще не было собственно GPU кода. Там речь шла о том, что если вдруг потребуется написать подобный код, то он отлично интегрируется в конвейер обработки данных на Ranges.
WH>Я всё посмотрел.
WH>Но ты подменяешь задачу одним из возможных решений.
WH>Если у нас встал вопрос с GPU значит изначальная задача: быстро перемолотить большую пачку данных.
WH>А это означает, что нужно сразу брать правильный инструмент.

Если говорить о правильных инструментах для вычислениях на GPU, то в случае требования максимальной производительности у меня будет выбор между CUDA и OpenCL (в зависимости от целевого железа). Если чуть снять требования на производительность, то можно использовать OpenCL на всём железе.

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

Это вот реальные инструменты для вычислений на GPU, хотя речь в данной дискуссии была совсем не о них.

WH>Ибо данная библиотека в самом лучшем для неё случае сыграет с Halide в ничью.
WH>Просто по тому, что Halide позволяет задавать план исполнения руками.

Какая библиотека то? )))

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

_>>Смотри, единственным недостатком классического подхода RAII в данном контексте является вроде как медленное освобождение памяти, из-за того, что для каждого объекта вызывается его деструктор. Но в реальности для большинства кода (при правильной современной архитектуре) это не так:
WH>И что это за правильная архитектура такая?

В которой динамический полиморфизм применяется только в тех случаях, когда он реально необходим (весьма редко на самом деле), а не по всякому чиху.

_>>В то же время предложенный тобой вариант будет эффективно работать только в том случае, если на уровне типов запретить выделять в данном пуле (или GC, не суть) память для объектов с деструкторами. Т.е. этот метод уже не будет работать для тех областей кода, в которых нам нужны объекты обоих типов (с RAII и без — ты же хотел поддерживать и тех и тех, правильно?), т.к. проверка на тип объекта будет даже медленнее чем обращение к пустому виртуальному деструктору.
WH>1)Все проверки в моём варианте исключительно статические. Соответственно скорость работы в самом худшем случае будет как у rust'а.

Всё верно, будет та же самая максимальная скорость, что в C++ или Rust'e. Соответственно возникает вопрос — а зачем нам какая-то более сложная система, если существующие и так уже работают точно так же?

WH>2)В моём варианте память это не ресурс. Соответственно объектов с деструктором становится примерно 0. Сколько я писал на .НЕТ IDisposable был реализован у ничтожного количества объектов.
WH>И я ни разу не хранил такие объекты. 100% случаев выглядело примерно так.
WH>

WH>      using (StreamReader sr = new StreamReader(filename))
WH>      {
WH>         txt = sr.ReadToEnd();
WH>      }
WH>

Ну видимо потому, что реального RAII в .Net нет, а его бледные подобия дико неудобны. )))

_>>По сумме этих двух пунктов, получаем что предложенный подход (с одновременным использованием объектов с RAII и без, разделяемых системой типов) будет иметь какие-то преимуществ в быстродействие на столько ничтожном проценте возможных задач, что нет никакого смысла в его реализации.
WH>Ты очень сильно недооцениваешь количество сценариев, где мой подход будет работать.

Ещё раз: работать он будет практически везде. Вопрос в том будет ли он хоть где-то превосходить существующие системы...

WH>Например, почти любой парсинг. После разбора мы получаем некую структуру, которая состоит из кучи гетерогенных объектов связанных между собой. Далее почти всегда мы эту структуру только читаем. И после окончания работы всю структуру разом грохаем.
WH>Другой пример формирование запроса к БД. Сначала мы формируем АСТ запроса, оптимизируем его, потом формируем SQL для БД. После чего нам АСТ и ошмётки оптимизации этого АСТ не нужны. Их можно разом грохнуть.
WH>А теперь ты покажи задачу, в которой нужно хранить объект с деструктором не на стеке.

Эм, ты похоже всё перепутал. Здесь у нас вообще то речь шла о другом твоём подходе (у тебя в изначальном сообщение было несколько предложений). С идеей о том, чтобы убивать разом некие кучи логически связанных между собой объектов, я никогда не спорил — она абсолютно верная. Более того, она прямо сейчас эффективно используется (только без всяких гарантий от компилятора) в некоторых C++ проектах. А здесь мы обсуждали твою идею с разделением (с помощью системы типов) всех объектов на имеющих и не имеющих деструкторы. Такая смесь подходов на мой взгляд не принесёт вообще никаких преимуществ.

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

WH>>И что это за правильная архитектура такая?
_>В которой динамический полиморфизм применяется только в тех случаях, когда он реально необходим (весьма редко на самом деле), а не по всякому чиху.
Простейший пример: Дерево разбора программы. Как ты собираешься его представлять в "правильной архитектуре"? Без выделения кучи отдельных объектов?

WH>>1)Все проверки в моём варианте исключительно статические. Соответственно скорость работы в самом худшем случае будет как у rust'а.
_>Всё верно, будет та же самая максимальная скорость, что в C++ или Rust'e. Соответственно возникает вопрос — а зачем нам какая-то более сложная система, если существующие и так уже работают точно так же?
Нет. Не верно. Ты вообще прочитал, что я написал?
В С++ ты можешь сделать то о чем я говорю. Но не будет никаких гарантий со стороны компилятора.
А вот в расте нет.
Там система типов обязывает удалять каждый объект.

_>Ну видимо потому, что реального RAII в .Net нет, а его бледные подобия дико неудобны. )))
Нет. По тому, что объекты с деструкторами нужны только на стеке.
Показать пример, когда это не так ты не можешь. Вот и юлишь.

_>Эм, ты похоже всё перепутал. Здесь у нас вообще то речь шла о другом твоём подходе (у тебя в изначальном сообщение было несколько предложений). С идеей о том, чтобы убивать разом некие кучи логически связанных между собой объектов, я никогда не спорил — она абсолютно верная. Более того, она прямо сейчас эффективно используется (только без всяких гарантий от компилятора) в некоторых C++ проектах. А здесь мы обсуждали твою идею с разделением (с помощью системы типов) всех объектов на имеющих и не имеющих деструкторы. Такая смесь подходов на мой взгляд не принесёт вообще никаких преимуществ.
Я ничего не перепутал.
Для того чтобы убивать объекты пачками нужна гарантия отсутствия там деструкторов.
Причём не только из-за производительности но главное из-за того что не понятно в каком порядке эти деструкторы вызывать.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

_>>Какая библиотека то? )))
WH>Та, про которую он говорил. Ибо просто взять и закинуть код в GPU может сработать только для наиболее примитивных случаев.

Так в том то и дело, что в презентации речь шла не про какую-то конкретную библиотеку, а про интерфейс к любым подобным библиотекам (в том числе возможно и на Halide написанным, хотя тут он мне кажется излишним и правильнее будет OpenCL).

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

_>Вообще то это как раз не простейший пример, а довольно редкий случай.
Да ладно. Почти все приложения что-то парсят.

_>Но возможно и в нём нет никаких проблем — надо смотреть. Я с данной областью плотно не работал, так что расскажи откуда там по твоему возникают основные проблемы эффективной работы с памятью.
Я уже говорил. Тут нужно выделить кучу объектов. А потом всю кучу грохнуть.

WH>>А вот в расте нет.
WH>>Там система типов обязывает удалять каждый объект.
_>В Rust'е есть режим C/C++ под названием unsafe. )))
Зачем в этом случае нам вообще rust?

_>Далее, я так понимаю, что тебя интересуют примеры объектов в куче, деструкторы которых используются не только для управления памятью? Ну вот тебе элементарный пример: пишем приложение, являющееся контейнером OLE-объектов (ну грубо говоря свой Word). В таком приложение у нас естественно где-то внутри должен быть динамический список неких обёрток вокруг COM-интерфейсов, обеспечивающих как удобный доступ к их функциональности, так и автоматическое освобождение...
Это суровое легаси. Вокруг которого можно поплясать с бубном.
В нормальном ГУИ будет просто память.

_> — усложнение системы типов (возможно приводящее к написанию большого количества лишнего кода, как в Rust'e).
Нет. Приводящее к значительно меньшим проблемам, чем система rust'а.
Например, вот этой проблемы вообще не будет.
http://smallcultfollowing.com/babysteps/blog/2018/11/10/after-nll-moving-from-borrowed-data-and-the-sentinel-pattern/

_>Не уверен, что плюсы тут перевешивают минусы. В особенности с учётом того, что сам подход с мгновенным убийством пула объектов нужен в небольшом проценте приложений (где можно "пострадать" и без гарантий).
Небольшом? Да они почти все такие, если посмотреть внимательно.
Все веб серверы и прочие запрос/ответ серверы и клиенты, все морды к базам данных,...

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

_>Так в том то и дело, что в презентации речь шла не про какую-то конкретную библиотеку, а про интерфейс к любым подобным библиотекам (в том числе возможно и на Halide написанным, хотя тут он мне кажется излишним и правильнее будет OpenCL).
То есть ты даже не посмотрел что такое Halide, а рассуждать лезешь.
Реалии современного железа таковы что для того чтобы получить высокопроизводительный алгоритм нужно выбрать правильный план исполнения.
В данный момент в общем случае оптимальный план исполнения можно подобрать только тупым перебором. Просто пробуя разные планы и замеряя время исполнения.
Halide позволяет разогнать этот процесс в сотню раз.
В Halide есть автопланировщик, но он далеко не всегда позволяет найти оптимальный план исполнения. Но для фазы прототипирования алгоритма сойдет.

А OpenCL этот как раз вариант руками на ассемблере. В теории самый быстрый, а на практике...

Ну и главное совершенно не понятно, что за библиотеку ты собрался писать на Halide или OpenCL?
В лекции говорится про возможность взять несколько фильтров и слепить из них один. После чего запустить его на ГПУ. Для этого придётся написать компилятор, который компилирует эти фильтры в Halide, OpenCL или что-то ещё.
И тут мы опять возвращаемся к плану исполнения. И если у Halide есть автопланировщик который что-то может, то в случае с OpenCL мы приплыли. Нам сначала придётся написать Halide с автопланировщиком.

И первые строки на сайте Halide:

Halide is a programming language designed to make it easier to write high-performance image and array processing code on modern machines. Halide currently targets:
• CPU architectures: X86, ARM, MIPS, Hexagon, PowerPC
• Operating systems: Linux, Windows, macOS, Android, iOS, Qualcomm QuRT
• GPU Compute APIs: CUDA, OpenCL, OpenGL, OpenGL Compute Shaders, Apple Metal, Microsoft Direct X 12

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

От:	D. Mon	http://thedeemon.livejournal.com
Дата:	07.12.18 10:36
Оценка:	1 (1) +2

	От:	alex_public
	Дата:	04.06.16 13:54
	Оценка:

	От:	AlexRK
	Дата:	05.06.16 08:37
	Оценка:	2 (2) +2

	От:	AlexRK
	Дата:	04.06.16 10:54
	Оценка:	+4

От:	Pzz	https://github.com/alexpevzner
Дата:	05.12.18 12:10
Оценка:	+3

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	11.12.18 20:43
Оценка:

От:	so5team	https://stiffstream.com
Дата:	11.12.18 05:55
Оценка:	3 (1)

От:	Anton Batenev	https://github.com/abbat
Дата:	05.06.16 18:04
Оценка:	1 (1)

	От:	Evgeny.Panasyuk
	Дата:	09.12.18 13:00
	Оценка:	1 (1)

	От:	Лось Чтостряслось
	Дата:	04.12.18 13:40
	Оценка:	+1

От:	MTD	https://github.com/mtrempoltsev
Дата:	04.06.16 10:37
Оценка:

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	10.12.18 23:50
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	12.12.18 18:03
Оценка:

	От:	Ночной Смотрящий
	Дата:	17.12.18 18:16
	Оценка:

	От:	WolfHound
	Дата:	19.12.18 01:26
	Оценка:	+1

	От:	Слава
	Дата:	05.01.19 20:12
	Оценка:	+1