Здравствуйте, Shmj, Вы писали:
S>Стоит ли обратить внимание на Rust?
Язык определенно того стоит, даже если ты не будешь никогда писать на нем.
Rust — это такая любопытная смесь языков С и Haskell. Одновременно системный язык без сборщика мусора, но где довольно много общих вещей с Haskell. Взять те же классы типов, которые в Rust более известны как трейты. Классы типов — это, вообще, один из трех основных столпов языка Haskell (наряду с ФП и очень простым базовым языком, к которому сводится сам Haskell). Классы типов красной чертой проходят по всему дизайну этих обоих языков. В то же время, в Rust нет сборщика мусора, и в текущей реализации довольно простое и эффективное представление объектов в памяти, т.е. уровень языка позволяет писать системные вещи.
Где Rust может быть эффективнее C++ при исполнении кода? В своих экспериментах я обнаружил прелюбопытную вещь. В Rust крайне эффективно реализовано перемещение объектов, которое обычно сводится к простому побитовому копированию небольшого заголовка (handle) объекта из стека, это часто всего несколько байт. Такое быстрое перемещение особенно становится важным, если вы начнете широко использовать комбинаторы, например, для асинхронного программирования. Комбинаторы — это по сути вложенные функции. И там как раз важно, чтобы быстро работало перемещение объектов при создании новых замыканий.
И меня, честно говоря, удивило, что в таких задачах Rust может по скорости исполнения кода дать фору такому маститому и титулованному жеребцу как C++. Это объясняется тем, что семантика перемещения в C++, мягко говоря, сложнее, и там есть нетривиальные моменты, связанные с тем, что код в C++ должен по возможности быть безопасным относительно исключений. Поэтому даже банальное перемещение объекта по конструктору, который не помечен как noexcept, будет много дороже, чем перемещение объекта в замыкание в языке Rust. Просто в Rust исключений, кроме паники, по сути больше и нет. И в Rust здесь не платят за то, что не используют. Более того, Rust не вызывает деструктор для уже перемещенного объекта, т.е. не выполняет лишнюю работу, которую делает C++, для которого еще нужно "обнулить" перемещенный объект, чтобы для такого объекта отработал деструктор.
Я привел лишь частный пример. Безусловно можно найти вещи, которые будут эффективнее и проще в С++, но далеко не все так однозначно, как обычно бывает в жизни.
S>Пророчат что это язык для написания безбажных ядер операционных систем и т.д.
Безбажных?! Идиллия. Такого не бывает, и никогда не будет. Главный источник ошибок в программе — это сам человек, его логические ошибки, взаимное недопонимание, незнание и прочие вещи, хотя от каких-то ошибок язык и может спасать.
Здравствуйте, Mamut, Вы писали:
M>На той странице нет интересных сравнений производительности. Как и на любых синтетических бенчмарках. M>Интересны сравнения типа https://github.com/ixy-languages/ixy-languages
Есть ещё более интересные сравнения, на реальных примерах. Например, есть компрессор Brotli, реализованный Гуглом на С. Есть его копия на Rust от Dropbox. Если верить статье, то реализация на Rust менее эффективна, но безопасней:
So given the safety, determinism and correctness, the final cornerstone is the speed of the Rust-based decompressor. Currently the decompressor runs at 72% of the speed of the vanilla -O3 optimized Brotli decompressor in gcc-4.9 for decompressing 4 megabyte blocks of data. This means it is able to safely decompress Brotli data at 217 MB/s on a Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz.
Здравствуйте, Kolesiki, Вы писали:
K>Я б не стал. Мне интуиция подсказывает! Первый взгляд на язык должен восхищать. А когда я взглянул на Ржавого, недоумённо почесал затылок и подумал — нафиг надо?...
А что не так с первым взглядом? Нормальная модульность и система сборки сразу, zero costs abstractions, автоматические проверки косяков при компиляции, отсутствие сборщика мусора и низкоуровневость, вменяемый синтаксис, пофикшен косяк с null. По мне — просто охрененный язык там, где нужна низкоуровневость, где максимальные требования к быстродействию, объему памяти и т.д.
На Раст сейчас валят хипстеры с Руби. Они пишут на Расте свои веб фреймвоки, потому что это единственное, что они умеют делать. Квалификация этих хипстеров, как известно, немногим выше ПХП и Джава скриптеров. Системщики на Раст не особо большое внимание обращают. Поэтому будущее у Раста в системном программировании под вопросом. Ну, а для веба он тоже на самом деле не годится. Сильно низкоуровневый. Ни в ту, ни в другую нишу он не вписывается.
Здравствуйте, Shmj, Вы писали:
S>Стоит ли обратить внимание на Rust?
Тут занятный отчет человека, что в embedded на голом железе писал и перешел с С++ на Раст, что получилось и как он доволен: http://cliffle.com/blog/m4vga-in-rust/
Здравствуйте, Shmj, Вы писали:
S>Стоит ли обратить внимание на Rust?
Отвечая на главный вопрос, заданный в теме, нет, лично для меня Rust заменить не может C++ по той простой причине, что Rust не поддерживается на Эльбрусах. Show stopper как он есть.
Здравствуйте, techgl, Вы писали:
T>Вот интересное сравнение производительности, где Rust обходит C++ на нескольких (не всех) задачах. Интересен он тем, что во-первых, используются неэквивалентные подходы (зачем в первой задаче OpenMP, например), во-вторых код на Rust использует unsafe, что как бы намекает. Думаю, если правильно переписать решения на C++, то порядок будет наведен.
Но давай уж тогда честно скажем, что в решении на C++ там плюсами и не пахнет, там какой-то Си-с-классами
Здравствуйте, Mamut, Вы писали:
M>В том, что файл — не модуль. И невозможно объявить, что вот этот конкретный файл — это модуль, который можно импортировать и т.п. Зачем-то вызывающий код должен объявить модуль, а затем его импортировать. Зачем? В чем смысл этого ненужного кода? Который вдобавок надо вручную повторять в каждом коде, который будет вызывать этот модуль.
Вручную повторять mod A; нужно только в одном месте крейта.
Фактически этим выражением мы просто вставляем в исходник содержимое файла A.rs
на псевдокоде mod A; можно выразить так:
mod A {
include!("A.rs");
}
Зато можно объявлять вложенные модули внутри любого файла, как пример тесты обычно
помещают в отдельный модуль:
fn div_s(a: i32, b: i32) -> Option<i32> {
if b == 0 {
None
} else {
Some(a / b)
}
}
#[cfg(test)]
mod test_main {
use super::*;
#[test]
fn test_1() {
assert_eq!(div_s(4, 2).unwrap(), 2);
}
}
Польза от таких модулей вполне заметная особенно при использовании условной компиляции,
ну и исключаем лишнюю сущность которая есть во многих языках namespace.
Вообще модули перекочевали в rust прямиком из OCaml и сохранили оттуда некоторые
странности, и к сожалению растеряли по пути свою первоклассность.
Нет во всех местах где нужно использовать используешь use.
А mod можно (и необходимо) использовать только в ограниченных местах, это файл main.rs (lib.rs)
и файлы определяющие модули в папках (по умолчанию mod.rs).
В остальных местах будет ошибка компиляции.
Логика обязательного и не автоматического указания mod A; от меня тоже ускользает, но что есть
то есть.
FR>>Фактически этим выражением мы просто вставляем в исходник содержимое файла A.rs FR>>Польза от таких модулей вполне заметная особенно при использовании условной компиляции, FR>>ну и исключаем лишнюю сущность которая есть во многих языках namespace.
M>Так в том-то и дело, что исходник не вставляем и namespace остается. Потому что нам нужно все равно делать потом use module::что-то-там (вот и namespace). Если бы действительно вставляли (аналог ОКамловского open), то можно было бы пользоваться функциями из модуля безо всякого use.
open в OCaml это скорее аналог use. Там есть и include, который ближе к mod.
M>Условная компиляция к модулям, имхо, вообще не имеет отношения
Ну как раз с модулями ее и удобно использовать как замену для бедных параметризируемых
модулей.
FR>>Вообще модули перекочевали в rust прямиком из OCaml и сохранили оттуда некоторые FR>>странности, и к сожалению растеряли по пути свою первоклассность.
M>Похоже, что авторы Rust'а не поняли, что такое модулив ОКамле, и перетянули часть синтаксических особенностей без единой полезности.
Ну да потеряли много.
Но в общем то логичность модулей раста ничем ни хуже и не лучше чем в большинстве других
языков. Мелкие кривости есть практически у всех.
когда доводов не хватает тогда начинаются сливы по типу — а хочу что бы из каробки аля std::
если же смотреть на процесс разработки с самого начала
то в нем есть один два синьора, которые уже все знают и умеют
и проблем ни с векторами ни с ртти итд нет
когда же процесс разработки построен так что вместо синьоров сидят и варятся десяток джунов
тогда все именно так как вы описываете
Здравствуйте, Shmj, Вы писали:
S>Стоит ли обратить внимание на Rust?
S>Пророчат что это язык для написания безбажных ядер операционных систем и т.д.
Имхо, в ближайшие лет 5-10 все как было на C/C++, так и останется. Пока какие-то компании не начнут вливать деньги в популяризацию (как эппл делает со свифтом и гугл с котлином, например).
Кстати, любопытно, есть ли в природе серьезные low level проекты на расте? Встречал его только в файрфоксе.
Здравствуйте, Shmj, Вы писали:
S>Стоит ли обратить внимание на Rust?
А ты с какой целью интересуешься? Чего хочешь получить в итоге, обратив внимание на Rust?
S>Пророчат что это язык для написания безбажных ядер операционных систем и т.д.
Здравствуйте, Shmj, Вы писали:
S>Стоит ли обратить внимание на Rust?
S>Пророчат что это язык для написания безбажных ядер операционных систем и т.д.
Пока (уже два года) наблюдаю мелкие баги в ФФ. Не боги баги дебажат.
Что принципиально нового в расте? усложнение синтакса в надежде защититься от случайного кирпича на голову?
Здравствуйте, dsorokin, Вы писали:
D>Язык определенно того стоит, даже если ты не будешь никогда писать на нем. D>Rust — это такая любопытная смесь языков С и Haskell.
Может лучше с Haskell разобраться в таком разе? Вот уж где новый дивный мир с кучей интересных концептов.
D>И меня, честно говоря, удивило, что в таких задачах Rust может по скорости исполнения кода дать фору такому маститому и титулованному жеребцу как C++.
Здравствуйте, Shmj, Вы писали:
S>Стоит ли обратить внимание на Rust?
Я б не стал. Мне интуиция подсказывает! Первый взгляд на язык должен восхищать. А когда я взглянул на Ржавого, недоумённо почесал затылок и подумал — нафиг надо?...
S>Пророчат что это язык для написания безбажных ядер операционных систем и т.д.
Так пророчит кто — промоутеры? Из тех, кто реально пишет "безбажные ОС", хочет кто-нть эту Ржу?
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, dsorokin, Вы писали:
D>>И меня, честно говоря, удивило, что в таких задачах Rust может по скорости исполнения кода дать фору такому маститому и титулованному жеребцу как C++.
KP>Разве что на синтетических примерах, но на "фору" это никак не тянет
Я имел в виду вполне конкретный тип задач. Среднестатистическому программисту они известны больше под видом асинхронных вычислений, но далеко ими не исчерпываются. Скажем, вычисление std::future из C++ и вычисление Future из Rust. Пример комбинатора в C++: then. Его более близкая к первоосновам форма в Rust: and_then.
Это все вокруг монад. Вот, на этих вполне конкретных вещах Rust имеет преимущество.
В 2009 году, когда бравые ребята из мозиллы начали переписывать свой браузер на раст, их браузер занимал >20% рынка. Сегодня firefox занимает <10% рынка.
Кстати, тот же маневр они проворачивают уже не в первый раз: в 90е точно так же решили переписать нетскейп навигатов заново, но при этом вообще потеряли рынок. С 80% процентов упали до нескольких процентов.
Здравствуйте, Shmj, Вы писали:
S>Пророчат что это язык для написания безбажных ядер операционных систем и т.д.
Переписывать всё с нуля очень дорого, а смысла никакого. Я точно так же могу утверждать, что в ближайшем будущем все ядра ОС, драйвера, прикладные приложения будут переписаны на Brainfuck, у него великое будущее. Но в реальности лидеров вряд ли удастся потеснить, они будут пребывать на вершине в течении десятилетий.
Здравствуйте, Mamut, Вы писали:
M>Вместо того, чтобы определять модуль в самом файле, модуль определяется, а потом импортируется в вызывающем файле.
Если бы файл требовалось начинать чем-то вроде Module name, то было бы лучше?
Я всё-таки считаю, что модуль определяется в файле, просто неявно. А mod name этот модуль импортирует, но не определяет.
Здравствуйте, Shmj, Вы писали:
S>Стоит ли обратить внимание на Rust?
S>Пророчат что это язык для написания безбажных ядер операционных систем и т.д.
Вот интересное сравнение производительности, где Rust обходит C++ на нескольких (не всех) задачах. Интересен он тем, что во-первых, используются неэквивалентные подходы (зачем в первой задаче OpenMP, например), во-вторых код на Rust использует unsafe, что как бы намекает. Думаю, если правильно переписать решения на C++, то порядок будет наведен.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, techgl, Вы писали:
T>>Вот интересное сравнение производительности, где Rust обходит C++ на нескольких (не всех) задачах. Интересен он тем, что во-первых, используются неэквивалентные подходы (зачем в первой задаче OpenMP, например), во-вторых код на Rust использует unsafe, что как бы намекает. Думаю, если правильно переписать решения на C++, то порядок будет наведен.
KP>Но давай уж тогда честно скажем, что в решении на C++ там плюсами и не пахнет, там какой-то Си-с-классами
M>>Зачем нужен mod name тогда? import "название файла" и вперед.
DE>А в чём принципиальная разница между этими вариантами?
В том, что файл — не модуль. И невозможно объявить, что вот этот конкретный файл — это модуль, который можно импортировать и т.п. Зачем-то вызывающий код должен объявить модуль, а затем его импортировать. Зачем? В чем смысл этого ненужного кода? Который вдобавок надо вручную повторять в каждом коде, который будет вызывать этот модуль.
A.rs
... какой-то код ...
B.rs
mod A
use A::что-то-там
C.rs
mod A
use A::что-то--там
Здравствуйте, dsorokin, Вы писали:
D>Отвечая на главный вопрос, заданный в теме, нет, лично для меня Rust заменить не может C++ по той простой причине, что Rust не поддерживается на Эльбрусах. Show stopper как он есть.
Тут человек работающий над компилятором си для эльбруса пишет что портируют.
FR>Вручную повторять mod A; нужно только в одном месте крейта.
Во всех местах, где надо использовать mod.
FR>Фактически этим выражением мы просто вставляем в исходник содержимое файла A.rs FR>Польза от таких модулей вполне заметная особенно при использовании условной компиляции, FR>ну и исключаем лишнюю сущность которая есть во многих языках namespace.
Так в том-то и дело, что исходник не вставляем и namespace остается. Потому что нам нужно все равно делать потом use module::что-то-там (вот и namespace). Если бы действительно вставляли (аналог ОКамловского open), то можно было бы пользоваться функциями из модуля безо всякого use.
Условная компиляция к модулям, имхо, вообще не имеет отношения
FR>Вообще модули перекочевали в rust прямиком из OCaml и сохранили оттуда некоторые FR>странности, и к сожалению растеряли по пути свою первоклассность.
Похоже, что авторы Rust'а не поняли, что такое модулив ОКамле, и перетянули часть синтаксических особенностей без единой полезности.
FR>Логика обязательного и не автоматического указания mod A; от меня тоже ускользает, но что есть FR>то есть.
Вот я про это и говорю. По какой-то непонятной причине модуль указывается не в модуле, а в коде, которые его вызывает.
FR>Но в общем то логичность модулей раста ничем ни хуже и не лучше чем в большинстве других FR>языков. Мелкие кривости есть практически у всех.
Имхо, Java с ее import x.y.z впереди планеты всей по удобству использования
Здравствуйте, Mamut, Вы писали:
M>Имхо, Java с ее import x.y.z впереди планеты всей по удобству использования
Это уже не совсем про модули, но в джаве ведь нет переименования при импорте? Я бы не назвал это удобным.
Здравствуйте, Mamut, Вы писали:
M>В том, что файл — не модуль. И невозможно объявить, что вот этот конкретный файл — это модуль, который можно импортировать и т.п. Зачем-то вызывающий код должен объявить модуль, а затем его импортировать. Зачем? В чем смысл этого ненужного кода? Который вдобавок надо вручную повторять в каждом коде, который будет вызывать этот модуль.
M>
M>A.rs
M>... какой-то код ...
M>B.rs
M> mod A
M> use A::что-то-там
M>C.rs
M> mod A
M> use A::что-то--там
M>
Непонятная проблема. Хорошим стилем было бы объявить модуль A единожды в соответствующем файле mod.rs, а дальше без проблем импортировать его через use в других модулях без лишнего объявления mod. Если объявить как положено, то компилятор Rust без проблем находит модуль.
К модулям это имеет нулевое отношение
DE>Ну и можно притянуть за уши облегчение рефакторинга, когда мы временно комментируем mod a вместо удаления/перемещения/переименования файла.
D>Непонятная проблема. Хорошим стилем было бы объявить модуль A единожды в соответствующем файле mod.rs, а дальше без проблем импортировать его через use в других модулях без лишнего объявления mod.
Сначала придумаем соверщенно неэргонмический способ объявления модулей. А потом вместо того, чтобы это починить, прилепим сверху костыль в виде mod.rs
D>Если объявить как положено, то компилятор Rust без проблем находит модуль.
M>>Имхо, Java с ее import x.y.z впереди планеты всей по удобству использования DE>Это уже не совсем про модули, но в джаве ведь нет переименования при импорте? Я бы не назвал это удобным.
Нет, переименования нет, но я бы не сказал, что это огромная проблема.
Здравствуйте, Михaил, Вы писали:
М>Кстати, любопытно, есть ли в природе серьезные low level проекты на расте? Встречал его только в файрфоксе.
Firecracker VM ( https://firecracker-microvm.github.io/ ).
Честно говоря, не понял. Возможно, потому что представляю, в первую очередь, то как растовые модули сейчас устроены и не понимаю как приведённый пример их чинит.
M>Што? Зачем удалять и т.п. файл?
Сейчас в расте модули в проекте (crate в терминах раста) представляют древовидную структуру, где корнем являет lib.rs/main.rs. Конструкция mod <имя_модуля> добавляет модуль в проект. Я отвечал на комментарий (если правильно его понял) о том, что это можно было бы делать автоматически, просто при наличии файла.
Вообще мне кажется, что мы несколько о разном говорим. Я всё-таки считаю, что mod — это не про импорт, а про построение структуры проекта. Импорт (из библиотек) или других модулей проекта делается вполне очевидно (через use).
M>>К модулям это имеет нулевое отношение
DE>Честно говоря, не понял. Возможно, потому что представляю, в первую очередь, то как растовые модули сейчас устроены и не понимаю как приведённый пример их чинит.
Он их не чинит. Он показывает, что модули и условная компиляция ортогональны друг другу.
M>>Што? Зачем удалять и т.п. файл? DE>Сейчас в расте модули в проекте (crate в терминах раста) представляют древовидную структуру, где корнем являет lib.rs/main.rs.
Модули почти везде представляют собой древовидную структуру. Но никто, кроме раста, не требует объявлять модуль не в модуле, а в коде, который вызывает этот модуль.
DE>Конструкция mod <имя_модуля> добавляет модуль в проект.
Что значит «добавляет в проект». Вот он модуль. Уже лежит в проекте. Почему модуль объявляется не в модуле, а в файле, который вызывает этот модуль?
DE>Вообще мне кажется, что мы несколько о разном говорим. Я всё-таки считаю, что mod — это не про импорт, а про построение структуры проекта. Импорт (из библиотек) или других модулей проекта делается вполне очевидно (через use).
mod — это как раз и про импорт и про построение структуры. Ты не можешь сделать use пока не объявишь mod. Но при этом mod по какой-то никому не понятной причине объявляется не в коде, который и есть модуль, а в каком-то левом файле, который к нему вообще не имеет отношения.
Здравствуйте, Mamut, Вы писали:
M>mod — это как раз и про импорт и про построение структуры. Ты не можешь сделать use пока не объявишь mod. Но при этом mod по какой-то никому не понятной причине объявляется не в коде, который и есть модуль, а в каком-то левом файле, который к нему вообще не имеет отношения.
Файл mod.rs позволяет делать реэкспорт модулей и прочих сущностей из других модулей. Они тут, возможно, сымпровизировали по мотивам того, что похожий реэкспорт модулей умеет делать Haskell.
D>Файл mod.rs позволяет делать реэкспорт модулей и прочих сущностей из других модулей. Они тут, возможно, сымпровизировали по мотивам того, что похожий реэкспорт модулей умеет делать Haskell.
Здравствуйте, Mamut, Вы писали:
M>Он их не чинит. Он показывает, что модули и условная компиляция ортогональны друг другу.
Не понимаю как в приведённом примере взаимодействует указание пути и "что.угодно.где.угодно". Цель как раз в том чтобы в зависимости от настроек компиляции можно было сделать use/import только на один из нескольких взаимоисключающих модулей.
M>Что значит «добавляет в проект». Вот он модуль. Уже лежит в проекте. Почему модуль объявляется не в модуле, а в файле, который вызывает этот модуль?
Хорошо, что такое проект? Все файлы, которые лежат в определённой директории?
Как должна выглядеть иерархия модулей в таком случае? Соответствовать один к одному файловой структуре?
Как запретить лезть в подмодули из других частей проекта?
M>mod — это как раз и про импорт и про построение структуры. Ты не можешь сделать use пока не объявишь mod. Но при этом mod по какой-то никому не понятной причине объявляется не в коде, который и есть модуль, а в каком-то левом файле, который к нему вообще не имеет отношения.
Нет, отношение как раз прямое. Можно посмотреть на внешние подмодули как на частный случай объявленных внутри файла — они не самостоятельны и модуль верхнего уровня решает что будет видно снаружи.
M>>mod — это как раз и про импорт и про построение структуры. Ты не можешь сделать use пока не объявишь mod. Но при этом mod по какой-то никому не понятной причине объявляется не в коде, который и есть модуль, а в каком-то левом файле, который к нему вообще не имеет отношения.
DE>Нет, отношение как раз прямое. Можно посмотреть на внешние подмодули как на частный случай объявленных внутри файла — они не самостоятельны и модуль верхнего уровня решает что будет видно снаружи.
//a.rs
mod c
use c::...
-----------
//b.rs
mod c
use c::...
-----------
c.rs
этот файл и есть модуль. Но объявить его модулем
невозможно. Почему? Потому что.
Вместо этого его надо объявлять модулем по месту
вызова. Што?
Здравствуйте, D. Mon, Вы писали: DM>Тут занятный отчет человека, что в embedded на голом железе писал и перешел с С++ на Раст, что получилось и как он доволен: DM>http://cliffle.com/blog/m4vga-in-rust/
Я так понял, что у него система хард-реалтайм со статической памятью. Довольно важная и критичная к багам ниша, но там скорее с C конкурировать надо, чем с C++. Aргумент "std::vector::push_pack" не работает полноценно без динамики и RTTI как-то странен в контексте статической памяти. Нужна статика — не используй std::vector, ведь последний вовсе не затачивался под подобное использование, а один контейнер не может удовлеторить нужды всех приложений. Статический вектор довольно просто изобразить на std::aligned_storage. Вот и он тоже написал, что в реализации на плюсах переписал все зависимости на "безопасные". Это также (помимо камня в огород слабой предсказуемости ран-тайм поведения стандартной библиотеки и реверанса в сторону растовского no_std) говорит о том, что сама система маленькая, раз один человек осилил переписать все зависимости, не важно, на каком языке.
__>а один контейнер не может удовлеторить нужды всех приложений.
А хорошо бы, чтобы мог Ну ладно, не всех приложений, но хотя бы более-менее разумного их спектра. Микроскопический embedded на каких-нибудь уже мало кому нужных восьмибитных AVR, или вполне еще живых и любимых китайцами STM8, так уж и быть, отбросим. Но неприспособленность std::vector к вполне мощным в своей весовой категории STM32 в сценарии bare metal, realtime, no exceptions, no RTTI firmware – это провал ортогональности по Степанову. Понятно, что есть кастомные аллокаторы, но спасут ли они от прибитости гвоздями к RTTI?
__>говорит о том, что сама система маленькая, раз один человек осилил переписать все зависимости, не важно, на каком языке.
Или же говорит о том, что рантайм привычных систем неоправданно сложен (или монолитен, или лапшеобразен), т.к. требует более одного человека на перепиливание столь базовых вещей.
Microsoft recently created a stir after revealing it was taking some ideas from the popular Rust programming language to create a new language for 'safe infrastructure programming' under the banner Project Verona.
R>когда доводов не хватает тогда начинаются сливы по типу — а хочу что бы из каробки аля std::
Сливы в саду у дяди Вани В ржавом же, по утверждению джентльмена из статьи, core портируется легче, чем даже сишный newlib. Что говорить — Rust и на 8-ми битах уже успешно гоняют. Большой плюс в "системность". Что, впрочем, не отменяет его слабых сторон: например, аллес с полнотой и актуальностью документации, многие фичи только в nightly, непонятное будущее Mozilla, странное community, метапрограммирование так себе (в отличие от D и Nim).
R>то в нем есть один два синьора, которые уже все знают и умеют R>и проблем ни с векторами ни с ртти И так далее нет
Понятно, что нет. Т.к. std:: вменяемые люди изначально обходят десятой дорогой. У EA – EASTL, у Блумберга – BSL, у WebKit и Blink – WTF, у Qt – свой Qt Core и т.д. Ничего, в принципе, плохого в этом нет, но если у Rust получится успешно таскать стандартную библиотеку от мелкоконтроллеров до мейнфреймов — будет круто.
R>когда же процесс разработки построен так что вместо синьоров сидят и варятся десяток джунов
То изначально понятно, что вообще ничего не получится.
