Не вижу, как это противоречит lifetimes. В Rust, кстати, для POD-типов copy by default тоже бывает, и lifetimes в нём работают.
> Во-вторых, значения «после перемещения» — т.е. значения, из которых полезную информацию переместили. Но какой-то мусор остался. И этот мусор должен быть корректно обработан деструктором.
Не вижу, как это противоречит lifetimes.
> В-третьих, тот самый borrowing. А конкретно его сложные случаи, когда заимствованная ссылка попадает внутрь структуры. В Rust в таком случае лайфтайм должен быть явно указан в типе структуры. В С++ как разрешать подобный случай — непонятно.
Очевидно, ввести новый синтаксис. Можно прямо синтаксис из rust заимствовать.
> В-четвёртых, тонны старого кода, который про такие штуки ничего не знает. Считать отсутствие аннотаций ошибкой? Пропускать? Сделать аннотацию «не проверять аннотации»?
Всё, что написано в текущем синтаксисе, не проверять. Если lifetimes присутствуют, то проверять. Сделать warning в компиляторе — указатели без lifetime. Сделать опцию сделать такой warning ошибкой.
> Просто потому, что система типов С++ проектировалась на максимальную совместимость с С, а значит значения (как я писал выше) там рассматриваются скорее как пачки байт… Как результат — низкоуровневые уши торчат наружу
Что следует из того, что «низкоуровневые уши торчат наружу»? Всё, что вы пишете, это то, что вам кажется, что lifetimes в C++ добавить нельзя. Здесь отсутствуют аргументы по существу, простите.
> Макро-константы. Их валом до сих пор.
Ну придумают что-нибудь. Если уж даже из Python можно эти константы использовать, то и из C++ можно будет.
> Но почему тогда C++ — фактически единственный язык без вменяемого тулчейна для сборки и доставки зависимостей? Хотя бы как стандарта де-факто?
Я думаю, отсутствие Cargo — это следствие того, что на C++ неудобно писать. Не хотят хипстеры писать на C++, вот и нет единой популярной системы сборки и доставки зависимостей.
> Не совсем. Если не нужно жёсткое «байтоложество», то тот же Golang вполне подходит, несмотря на свой минимализм.
Это common misconception. В Go есть GC, что делает его непригодным для большого числа задач.
Я не могу говорить за всю компанию, моё мнение такое: Rust можно будет использовать в продакшне сразу после того, как в Rust сделают IDE и доделают инкрементальную компиляцию. Это случится, я думаю, приблизительно в течение года-двух. До того, как эти фичи будут реализованы, Rust проблематично использовать в больших долгоживущих проектах. После того, как эти фичи будут реализованы, C++ можно будет постепенно закапывать.
Впрочем, есть небольшой шанс, что в C++ добавят основные фичи Rust (в первую очередь borrowed pointers; сделают модули вместо препроцессора и доделают «концепты»), и Rust станет не нужен.
Тот, кто не подумает, зачем компилятор требует написать unsafe, пусть продолжает писать на Java. Остальным людям разделение на safe/unsafe очень помогает писать надёжный код.
Additional specific influences can be seen from the following languages:… The memory region systems of the ML Kit and Cyclone.
Идея я Mutex[T] очень хорошая. Но ее и на C++ не сложно реализовать.
Как и каналы, и всё остальное, что есть в стандартной библиотеке Rust.
Кстати, проверка границы массивов делается только при обращении по индексу, а при использовании чего-нибудь типа map не делается, так как не нужна? Это было бы очень приятно.
При использовании map проверка границы, конечно же, делается. Чтобы понять, где заканчивать итерирование. При этом проверка делается ровно такое же количество раз, как и в C++, т. е. оверхед нулевой.
Прямо сейчас я бы не стал на Rust писать ничего серьёзного. Rust пока не готов к промышленному использованию.
В будущем, подозреваю, на Rust не надо будет писать программы, которые нетребовательны к ресурсам, и которые возможно написать на Java. Проще программировать, когда есть сборщик мусора, и не надо знать обо всех этих тонкостях.
Вы всерьёз предлагаете разработчикам Rust почти в 14 раз увеличить объем выполняемой работы? Так мы релиза собственно языка не дождёмся никогда.
Не обязательно в первой версии IDE делать все эти прекрасные фичи, которые есть в IDE для Java. Можно начать с навигации и простенького комплишена, а поддержку рефакторинга, отладчика и всяких интеншнов сделать потом.
Длинный текст напишу как-нибудь, а если краткто, то многие вещи в Rust мне действительно не нравятся. Например, мне далеко не всегда нравится направление, в котором развивается язык, часто делают хуже, чем было. Вот, например, недавно в Rust реализовали фичу, которая называется lifetime elision (лайфтаймы остаются, но писать их теперь можно в пять раз реже). КМК, это вредная фича, которая ухудшает читаемость кода.
Однако все эти вещи, которые мне не нравятся, незначительны по сравнению с хорошими фичами языка.
Если сделают IDE server, который делает 80% работы, то достаточно хорошая IDE появится быстро.
> Без коммерческой поддержки компаний, заинтересованных в языке, не появится. JetBrains, на сколько я знаю, ничего такого пока не планируют.
Сегодня не планируют, завтра запланируют. Для typescript сделали, для groovy сделали, и для rust сделают.
Сделать указание lifetimes опциональным.
Не вижу, как это противоречит lifetimes. В Rust, кстати, для POD-типов copy by default тоже бывает, и lifetimes в нём работают.
> Во-вторых, значения «после перемещения» — т.е. значения, из которых полезную информацию переместили. Но какой-то мусор остался. И этот мусор должен быть корректно обработан деструктором.
Не вижу, как это противоречит lifetimes.
> В-третьих, тот самый borrowing. А конкретно его сложные случаи, когда заимствованная ссылка попадает внутрь структуры. В Rust в таком случае лайфтайм должен быть явно указан в типе структуры. В С++ как разрешать подобный случай — непонятно.
Очевидно, ввести новый синтаксис. Можно прямо синтаксис из rust заимствовать.
> В-четвёртых, тонны старого кода, который про такие штуки ничего не знает. Считать отсутствие аннотаций ошибкой? Пропускать? Сделать аннотацию «не проверять аннотации»?
Всё, что написано в текущем синтаксисе, не проверять. Если lifetimes присутствуют, то проверять. Сделать warning в компиляторе — указатели без lifetime. Сделать опцию сделать такой warning ошибкой.
> Просто потому, что система типов С++ проектировалась на максимальную совместимость с С, а значит значения (как я писал выше) там рассматриваются скорее как пачки байт… Как результат — низкоуровневые уши торчат наружу
Что следует из того, что «низкоуровневые уши торчат наружу»? Всё, что вы пишете, это то, что вам кажется, что lifetimes в C++ добавить нельзя. Здесь отсутствуют аргументы по существу, простите.
> Макро-константы. Их валом до сих пор.
Ну придумают что-нибудь. Если уж даже из Python можно эти константы использовать, то и из C++ можно будет.
> Но почему тогда C++ — фактически единственный язык без вменяемого тулчейна для сборки и доставки зависимостей? Хотя бы как стандарта де-факто?
Я думаю, отсутствие Cargo — это следствие того, что на C++ неудобно писать. Не хотят хипстеры писать на C++, вот и нет единой популярной системы сборки и доставки зависимостей.
> Не совсем. Если не нужно жёсткое «байтоложество», то тот же Golang вполне подходит, несмотря на свой минимализм.
Это common misconception. В Go есть GC, что делает его непригодным для большого числа задач.
Не вижу противоречий. Поясни?
> к тому же придётся мучительно аннотировать весь код чтобы это работало
Не мучительнее, чем в Rust.
> Препроцессор останется с нами навсегда во имя совместимости.
Пусть остаётся. Но пользоваться им будет не обязательно.
> Аналога же Cargo вообще не предвидится в обозримом будущем.
Вот уж совсем не проблема языка C++. Cargo не требует стандартизации даже.
> несоместимость С++ ни с кем кроме С++. Такой себе Language lock-in.
Это утверждение справедливо для любого другого языка программирования.
> единственное КМК что держит С++ на плаву — огромное сообщество и гигатонны уже написанного кода
C++ на данный момент — единственный инструмент, который позволяет эффективно писать производительный код, и причина вовсе не в legacy.
Эти «IDEшки» пока больше похожи на редакторы с подсветкой синтаксиса, чем на полноценные инструменты для работы с большой кодовой базой.
> Главная проблема тут в отсутствии дебага
Нет, главная проблема в том, что в этих «IDEшках» отсутствуют примерно 99% фич, которые присутствуют в современных IDE типа JetBrains IDEA.
А дебаг редко нужен, только в очень специфичных случаях. Тесты надо писать.
> Насчет компиляции, то можно и нужно разделять большие проекты на маленькие модули, тогда и компилируется быстро и архитектура лучше
Сомнительный совет — переписать код, чтобы исправить тормоза компилятора.
В любом случае, этот совет в общем случае не работает. Далеко не все проекты распиливаются на осмысленные маленькие модули.
Впрочем, есть небольшой шанс, что в C++ добавят основные фичи Rust (в первую очередь borrowed pointers; сделают модули вместо препроцессора и доделают «концепты»), и Rust станет не нужен.
to_string и as_slice, действительно, доставляют проблемы, но ссылаться на подход C++ как на истину и добро, точно не нужно.
Как и каналы, и всё остальное, что есть в стандартной библиотеке Rust.
При использовании map проверка границы, конечно же, делается. Чтобы понять, где заканчивать итерирование. При этом проверка делается ровно такое же количество раз, как и в C++, т. е. оверхед нулевой.
В будущем, подозреваю, на Rust не надо будет писать программы, которые нетребовательны к ресурсам, и которые возможно написать на Java. Проще программировать, когда есть сборщик мусора, и не надо знать обо всех этих тонкостях.
Не обязательно в первой версии IDE делать все эти прекрасные фичи, которые есть в IDE для Java. Можно начать с навигации и простенького комплишена, а поддержку рефакторинга, отладчика и всяких интеншнов сделать потом.
Однако все эти вещи, которые мне не нравятся, незначительны по сравнению с хорошими фичами языка.