Меня смущают нестандартизованные и популярные языки.

Даже джава или питон? Ну если под стандартами понимать ISO.

Что там может быть такого ужасного?

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

либо там это «криво спроектированное говно» не нужно.

Подозреваю, что он о наследовании.

А то ведь Rust-овский drop не тянет на C++ные деструкторы по обозначенными выше причинам.

По каким?

А чего сразу джава? Для плюсов такое есть? Чтобы надёжно и быстро? У меня не всегда даже автодополнение нормально работает в QtCreator.

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

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

go разрабы вот до сих пор в виме кодят и ничего.

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

Строительство зданий и сооружений :)

Или где оно, хотя бы, переписывается понемногу.

В .Net. При каждом обновлении фреймворка. С remotingа на WCF, с WCF на REST... Ну и да, с делегатов на лямбды... Но конкатенацию строк плюсиками в цикле никто из гениев переписывания не тронет аж с 2.0 :)

Особенно, когда тебя забрасывают деньгами и есть возможность нанимать разрабов.

Издеваешься? У мозиллы нет кучи денег и я очень сомневаюсь, что они много ресурсов на раст выделяют. Хоть что-то дают и то хорошо.

Если бы они параллельно с языком «мега ИДЕ» делали, то сейчас были бы по прогрессу на несколько лет назад. Тоже плохой вариант. Опять же, плагины к разным ИДЕ имеются. Да, не идеальные, но пилятся понемногу.

И ты пропустил вопрос про С++. Язык до 21 века дожил, замену ему, в определённых сферах, сложно найти. Тем не менее, возможности ИДЕ отстают от той же джавы. И ничего, как-то живут люди.

Она требует существенных затрат и вложенных усилий

Это не rocket science, технологии построения таких инструментов известны и отлажены. Нужно тупо посмотреть и скопировать готовые решения, не выдумывая ничего нового.

Строительство зданий и сооружений :)

Ты о чём? Вот у нас на работе С++11 применяется. Со временем и на С++14 перейдём, пока что винда назад тянет. То есть это совсем не редкость.

В .Net.

Как там в .Net не знаю, но для плюсов есть инструменты типа clang modernize, которые помогают обновлять код.

пока что винда назад тянет.

Везетвамнах. У нас кровавый ынтерпрайз и студия 2008 (стандарт матьего). И чтоб на серверах 2000 оффтопика все работало и чтоб на древней солярке и какой-то древнем редхате, где еще gcc не поддерживает с++11. Как-то ifdef выручает, но реально забодало.

Издеваешься? У мозиллы нет кучи денег и я очень сомневаюсь, что они много ресурсов на раст выделяют. Хоть что-то дают и то хорошо.

Что же вас каждого носом, что ли тыкать? Изучай https://www.opennet.ru/opennews/art.shtml?num=43192 К тому же, там лоби педерастов, а они то умеют деньги раздобыть среди своей братии. Так что перестань думать о бедственном положении мозилы.

Язык до 21 века дожил, замену ему, в определённых сферах, сложно найти

Потому что в ИТ, как и везде, большинство разрабов жрут, что дают, не задумываясь, что текущие возможности техники позволяют сделать более качественые инструменты, чем то, что делали в 70-90-х.

go разрабы вот до сих пор в виме кодят и ничего.

Тем не менее, возможности ИДЕ отстают от той же джавы. И ничего, как-то живут люди.

В джунглях папуасы тоже как-то живут, но я не хотел бы так жить.

Ну и где же эти инструменты? Кроме как для Java никаких вменяемых IDE нет.

Некуда валить-то. Языки со сборкой мусора и прочим jit — не канают.

А раз «не канают» и другой альтернативы нет, то значит объективно не мешает.

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

Даже Go от языка «системного программирования» сдулся до языка «сетевых служб», ага. А уж как старались, как старались...

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

А вот кого полным-полно — так это нытиков, хипстеров, маргиналов и прочей розовосопливой части человечества.

Не, эскобар.жпег уместен в дихотомии rust — c++.

Не взлетел даже D. D!!! Даже Go

Долбаная. Сборка. Долбаного. Мусора.

А раз «не канают» и другой альтернативы нет, то значит объективно не мешает.

Реальная альтернатива называется «Rust».

Не взлетел даже D. D!!!

D только в этом году научился сам себя компилировать. Спустя почти 15 лет разработки. Если это не убожество, то что тогда убожество?

Надеюсь, что взлетит.

И я — надеюсь. Но уже давным-давно не верю.

Ну и где же эти инструменты? Кроме как для Java никаких вменяемых IDE нет.

А для кого делать эти инструменты? Для скриптоты? Так это невозможно из-за ущербности скриптоты изначально. Кто остается популярным еще, кроме Java? Си? Так для него так же сложно написать подобный инструмент, ибо в 70-х, когда закладывался его дизайн, о таких инструментах не думали. Что там еще? С++/C#? Так для них есть необходимые интеллектуальные инструменты разработки. Для первого сделали сколько смогли, ибо дизайн ЯП также ущербен, если брать современные мерки. А больше то и нет никого на радарах.

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

А вот GHC как не умел, так и не умеет... Рантайм-то на C. И никто не парится. Почти за 25 лет.

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

И кто это должен сделать?

Что же вас каждого носом, что ли тыкать?

Один миллион - не куча денег. Ты серьёзно ставишь мозиллу в один ряд, скажем, с ораклом или майкрософтом? И вообще кончай придумывать. Про бедственное положение я ничего не говорил.

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

Это уже предлогали? Rust for C++ Programmers — коротко, сжато, понятно.

А вообще, на такие запросы всегда полезно погуглить «X for Y programmers». ;)

Даже Java и Python. Python переболел той же болезнью, что и D: большие проблемы с обратной совместимостью. Java тоже болеет, время от времени.

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

А новое - в новый язык. Чтобы поисковые запросы не выкидывали на старое api по сути уже другого языка.

По каким?

Отсутствие наследование в языке. Да и вообще Rust-овский drop больше напоминает .NET-овский IDisposable.Dispose(), нежели C++ные деструкторы.

У раста серьезная проблема с целевой аудиторией. Как ЯВУ для тырпрайза он совершенно не годится из-за своей параноидальной модели работы с памятью. У типичных индусов даже примеры скомпилировать не получится, не то что бы все это понять. Для стстемного программирования раст тоже выглядит переусложненным. Не представляю себе системщика, который бы променял свою «сишку» на такое чудо-юдо. Остается только сложная прикладуха, где нужно бодаться с C++. Ни у кого пока на этом поле не получилось. Тем более с новыми стандартами вообще не понятно нафига козе боян. Вот и выходит, что язык вроде неплохой, да только негде его применять по большому счету.

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

Один миллион - не куча денег.

Это 100 разрабов-месяцов или команда из 4 хороших разрабов на 2 года. Вполне хватит, чтобы запилить хорошую IDE. И конечно это не куча денег, но как я понимаю, Servo для них стратегический проект. А если они могут кинуть столько денег just for fun, то логически можно заключить, что для стратегических проектов могут бросить больше.

Но в итоге, стратегический проект пилится на коленке, чуть ли не в блокноте. И ладно, если это был бы какой-нибудь docker, но пилят то проект по сложности на уровне современных ОС... И делать это без качественых инструментов, просто не укладывается в моей голове. Ну либо, Servo это просто игрушка, чтобы попилить бабосы или умерить скуку особо отличившихся программеров.

И кто это должен сделать?

Разве не очевидно? Тот кто заворил всю эту кашу.

Эта задача тривиальна если из компилятора сразу нужные API торчат

Тривиальна, ага. Сколько там лет прошло от появления нужных API в LLVM до основанных на нем «мощных инструментов рефакторинга»? Много ли таких инструментов?

Java тоже болеет, время от времени.

Да ладно? Хочешь сказать, что джава нестабильнее стандартизованных плюсов?

Лучше бы язык сознательно стабилизировали и только багофиксом занимались

По сути, во всех версиях после 1.0 этим и занимаются.

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

Да и вообще Rust-овский drop больше напоминает .NET-овский IDisposable.Dispose(), нежели C++ные деструкторы.

Это ещё почему? Drop, точно так же, как и деструктор, вызывается при выходе из скоупа. Вручную звать необходимости нет, в отличии от Dispose, хотя возможность и имеется (как и в С++).

Отсутствие наследования, как по мне, к деструкторам не особо относится.

но как я понимаю, Servo для них стратегический проект

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

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

Это серьезный вопрос, ответ на который Rust-овский drop не дает.

Ну и похожесть на IDisposable проистекает прямо из примеров из штатной доки по Rust-у:

impl<T> Drop for Box<T> {
    fn drop(&mut self) {
    ...
    }
}

Ну и, кстати говоря, IDisposable в C# ориентирован на плотное использование в сочетании с конструкцией using. А на using можно смотреть как на один из частных случаев лайфтаймов Rust-а.

Так что для меня лично Rust-овский Drop — это больше IDisposable, нежели C++ные деструкторы.

пилят то проект по сложности на уровне современных ОС

Которые точно так же пилятся на коленке в блокноте. Понимаешь, умные IDE в первую очередь нужны для ворочания миллионов строк быдлокода. Со сложностью это не имеет ничего общего, точнее это тоде сложность конечно, но совсем иного рода.

Тогда надо что-то делать с поисковой системой. Например, поисковый запрос python до сих пор в большинстве результатов - python 2.

А поисковый запрос python 3 может найти библиотеки 3-ей версии для python 2.

А деструкторы в C++ вынуждены жить с такой вещью, как наследование.

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

исключение выбрасывается из деструктора производного класса, когда до деструктора базового класса дело еще не дошло.

Этот вопрос эквивалентен тому, что делать, если исключение вылетает во время исполнения деструктора, вызванного другим исключением. Java ответ на этот вопрос даёт в виде suppressed-исключений. C++ и Rust просто делают abort().

Ну и похожесть на IDisposable проистекает прямо из примеров из штатной доки по Rust-у

Просто в Rust нет «особенных» методов вроде конструкторов и деструкторов, которые по сути интерфейсы, обязательные для реализации всеми типами. Здесь это просто ещё один трейт (пусть и с особенной поддержкой от компилятора).

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

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

Как по мне, как такое же подмешивание интерфейса/трайта к типу, как и имплементация интерфейса в C#.

Я бы не сказал. Просто в расте методы реализуются «извне» класса. Ну и для популярных вещей сделаны трейты.

А на using можно смотреть как на один из частных случаев лайфтаймов Rust-а.

На это тоже можно смотреть как на «частный случай лайфтаймов»:

{
    ObjectWithDestructor o;
}

нормальные шаблоны

У них же дженерики.

This

Rust - говно, учи Go брачо!

Такая же скорость кода, но при этом гарантии безопасности.

А точно такая же? Был медленнее.

Go тоже говно, вот аргументированый список https://github.com/ksimka/go-is-not-good почему все так плохо.

Какие-то придуманные на ровном месте проблемы с исключениями в деструкторе.

Как раз все круто в крестах сделано. Мне не хватает деструкторов и RAII в других языках...

Наследования (данных) - нет, поэтому и нет связанных с этим возможностей.

Собственно, об этом и речь: нет наследования, поэтому Drop в Rust не есть полный эквивалент деструкторов в C++.

Для меня важно другой аспект взаимосвязи деструкторов и наследования: допустим, у нас был базовый класс A, от него отнаследовали B, от него отнаследовали C. Изначально явно определенный деструктор был у A и у C, а у B его не было. Потом в B реализовали деструктор. Но ни для кого ничего не изменилось. Потому, что для B деструктор таки был, просто он генерировался полностью компилятором.

А вот подмешивание внешних интерфейсов/трейтов для того, чтобы явно что-то почистить в обновленной версии B, как раз таки и делает механизмы IDisposable и Drop сильно непохожими на деструкторы.

Тогда что брать? D?

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

Покажите как сделать RAII в CL.

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

Читайте D&E. Модель с рестартами и сигналами была отброшена, как требующая больших ресурсов и как бесполезная на практике.

Выгода деструкторов, как и дропа как раз в том, что не надо их руками звать. Даже через «частичную автоматизацию» через using.

Вот кстати да. Деструкторы и Drop определяются автором объекта. Использование using — пользователем объекта. Если Drop можно дописать постфактум и после этого он автоматически станет вызываться везде, где его следует вызывать, то после реализации IDisposable ещё следует везде руками расставлять using.

Зато должны юзать везде try-with-resource, чтобы что-то нормально закрывалось. Жесть.

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