Вы откуда-то непонятно откуда берёте информацию. По ссылкам, приведённым вами, не написано, что Go — это системный язык и замена C++. Наоборот, он представляется там как типобезопасный статический язык, на котором так же легко писать, как на динамических языках. И это на самом деле так.
Кроме того, полноценным язык с неотключаемой (не в принципе, а на практике — когда отключение GC бессмысленно) сборкой мусора в принципе не может быть системным настолько же, насколько системными являются C/C++.
Я не имел в виду целиком весь объём фич (кстати, перегрузка операторов в Rust есть, как и разделяемые, причём безопасно, данные; что такое ranges в D, я не помню, но итераторы в Rust могут быть оптимизированы LLVM так, что собственно итератора как объекта там не останется), многие из которых спорны (вроде миксинов в виде строк). Я имел в виду вполне конкретный, самый основной поинт Rust — безопасное управление ресурсами без сборщика мусора.
Ни один из языков, успешных в вашем понимании, не развивался всего лишь три года и не стал успешным в статусе бета-версии. Повторюсь ещё раз, от Rust этого прямо сейчас ожидать очень странно.
Перегрузка функций (её отсутствие) — это один из самых спорных вопросов в дизайне Rust. Буквально на днях на эту тему поднимался разговор в списке рассылки. У разработчиков языка на эту тему очень жёсткая позиция, так что здесь вряд ли будут изменения.
Самые распространённые современные отладчики — gdb и lldb — работают и используются.
С IDE пока всё плохо. Но другого и ожидать трудно — IDE по сложности разработки и поддержки сравнима с самим языком, и поддерживать её в актуальном состоянии будет очень трудно.
Интеграция с C отменная. FFI в Rust, имхо, лучше только в самом C :)
Изначально у авторов действительно не было конкретных представлений о форме языка и его возможностях, кроме самых общих. Это на самом деле был эксперимент. Однако то, что версию 1.0 собираются выпускать уже в этом году, говорит о том, что в целом язык уже обрёл основной «хребет» функциональности и фич, и это на самом деле так — самые основные концепции и подходы меняться уже не будут. Сейчас радикальные breaking change'ы уже более-менее запланированы, и они больше технические, чем принципиальные (те самые unboxed-замыкания и DST).
7) Куча багов в компиляторе, постоянные креши с просьбой отправить багрепорт.
Да, баги есть, но их не куча. Гораздо меньше, чем могло бы быть, и при этом ICE обычно исправляются довольно быстро, если их отправить в багтрекер Rust.
1) Документации очень мало, существующая почти вся нерабочая (устарела).
Документации мало, да, но туториалы и стандартная библиотека обычно поддерживаются в более-менее актуальном состоянии. Никуда не денешься, язык всё ещё в бете.
2) Постоянные изменения в компиляторе/библиотеке. Ни дня без breaking change.
3) Не только постоянные изменения, но и неконсистентное состояние: одну часть изменили, другую еще нет.
4) Ни одного рабочего примера в интернете (видимо, из за (2)).
То же самое. Язык активно развивается, и уж лучше пусть пока будут breaking change-ы, чем зафиксированный неудобный дизайн.
5) Каждая строка кода — битва с компилятором насмерть. Пытались писать особо изощренную шаблонную магию в С++? Тут этот ад во всем коде.
6) Ошибки компилятора повергают в недоумение даже программистов под gcc с его жуткими сообщениями.
Очень спорно и субъективно. Достаточно на базовом уровне воспринять самые важные концепции языка (aliasing указателей и владение данными), и получится писать сразу почти без ошибок. Никаких сложных концепций, как в метапрограммировании, там нет в принципе. Говорю это по опыту.
Вы хотите сказать, что вот это (первое, что нашёл в гугле; это всего лишь ошибка о том, что в функцию передают лямбду, принимающую string, а надо, чтобы принимала wstring):
prog.cpp: In instantiation of ‘void fill_array(std::array<T, N>&, F&&) [with T = std::vector<std::basic_string<wchar_t> >; unsigned int N = 10u; F = main()::<lambda()>]’: prog.cpp:18:61: required from here prog.cpp:10:9: error: no match for ‘operator=’ in ‘v = main()::<lambda()>()’
prog.cpp:10:9: note: candidates are:
In file included from /usr/include/c++/4.7/vector:70:0,
from prog.cpp:4:
/usr/include/c++/4.7/bits/vector.tcc:161:5: note: std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = std::basic_string<wchar_t>; _Alloc = std::allocator<std::basic_string<wchar_t> >]
/usr/include/c++/4.7/bits/vector.tcc:161:5: note: no known conversion for argument 1 from ‘std::vector<std::basic_string<char> >’ to ‘const std::vector<std::basic_string<wchar_t> >&’
In file included from /usr/include/c++/4.7/vector:65:0,
from prog.cpp:4:
/usr/include/c++/4.7/bits/stl_vector.h:427:7: note: std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(std::vector<_Tp, _Alloc>&&) [with _Tp = std::basic_string<wchar_t>; _Alloc = std::allocator<std::basic_string<wchar_t> >; std::vector<_Tp, _Alloc> = std::vector<std::basic_string<wchar_t> >]
/usr/include/c++/4.7/bits/stl_vector.h:427:7: note: no known conversion for argument 1 from ‘std::vector<std::basic_string<char> >’ to ‘std::vector<std::basic_string<wchar_t> >&&’
/usr/include/c++/4.7/bits/stl_vector.h:449:7: note: std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(std::initializer_list<_Tp>) [with _Tp = std::basic_string<wchar_t>; _Alloc = std::allocator<std::basic_string<wchar_t> >; std::vector<_Tp, _Alloc> = std::vector<std::basic_string<wchar_t> >]
/usr/include/c++/4.7/bits/stl_vector.h:449:7: note: no known conversion for argument 1 from ‘std::vector<std::basic_string<char> >’ to ‘std::initializer_list<std::basic_string<wchar_t> >’
проще, чем вот это, где на чистом английском говорят, что за проблема и где, с подсветкой и чуть ли не тыканьем пальцем?
dangling.rs:3:12: 3:14 error: `i` does not live long enough
dangling.rs:3 return &i;
^~
dangling.rs:1:23: 4:2 note: reference must be valid for the anonymous lifetime #1 defined on the block at 1:22...
dangling.rs:1 fn dangling() -> &int {
dangling.rs:2 let i = 1234;
dangling.rs:3 return &i;
dangling.rs:4 }
dangling.rs:1:23: 4:2 note: ...but borrowed value is only valid for the block at 1:22
dangling.rs:1 fn dangling() -> &int {
dangling.rs:2 let i = 1234;
dangling.rs:3 return &i;
dangling.rs:4 }
error: aborting due to previous error
Это одна из наиболее часто встречающихся ошибок в Rust (когда ссылку передают за пределы её области жизни). У меня сейчас нет рядом компилятора Rust, но если написать аналог кода по ссылке наверху на Rust, то вы получите ясное и недвусмысленное сообщение о том, что типы несовместимы.
Обычно их постоянно переписывают. Изменения происходят всё-таки последовательно, поэтому если есть интерес и желание следить за развитием языка сейчас, то поддерживать библиотеки в адекватном состоянии не так трудно. Тут ничего не поделаешь, бета-версии — они такие :) кстати, для проверки совместимости библиотек многими используется travis-ci, так что обычно даже вручную не нужно проверять, что что-то сломалось.
Это действительно спорный вопрос, и некоторые вещи, которые там сделали, мне тоже не очень нравятся, но в целом, как мне кажется, направление верное. Язык становится более однородным и простым. Вырабатываются какие-то общие подходы и идиомы, которые находят отражение в самом языке. Например, избавление от managed-указателей в самом языке имеет гораздо больше преимуществ, чем недостатков.
Я, наверное, не совсем правильно выразился насчёт гибкости. Вполне возможно, что D за счёт своих шаблонов и миксинов уделает Rust по гибкости в применении (хотя в Rust есть макросы, подстановочные и процедурные), но в плане разработки самого языка Rust менялся очень сильно, и всё время происходил поиск каких-то новых путей и реализаций различных штук. За счёт этого Rust гораздо быстрее и эффективнее развивается. Под гибкостью я имел в виду это. Например, Rust стал вторым по активности проектом на Github за 2013 год, причём первым был Homebrew, в котором активность заключается не в правке кода, а в выкладывании новых описаний пакетов. Когда я писал на D, у меня сложилось совершенно противоположное впечатление о развитии языка.
А насчёт низкоуровневости — всё достаточно просто. Rust изначально разрабатывался как язык для системного программирования. Например, в D хоть и можно отключить сборщик мусора, но вся стандартная библиотека сразу станет неюзабельной. В Rust сборщик мусора не нужен в принципе, в том числе для стандартных библиотек. Также как только вы отказываетесь от сборки мусора в D, вы мгновенно получаете небезопасность C. Аналогов статического анализа, который проводит Rust для обеспечения правильной работы с ресурсами, сейчас, фактически, нет (за исключением совсем маргинальных языков вроде ATS или Cyclone).
Я писал на D довольно давно (года два назад) и уже прилично подзабыл, как там что, поэтому я не могу сравнить его с Rust полноценно. В целом мне D понравился, но Rust оставляет ощущение гораздо более практичного языка, ИМХО.
Пока большого количества библиотек нет, но над этим ведётся активная работа. Например, для работы с графикой в последнее время появилось несколько библиотек (rust-sdl2 и ещё несколько, я сейчас уже не помню точно). Для баз данных тоже есть биндинги (точно знаю, что есть для PostgreSQL и SQLite). Работа с сетью есть в стандартной библиотеке, и есть биндинги к сторонним библиотекам вроде ZeroMQ.
— стабильности проверенной годами
— обилии КАЧЕСТВЕННЫХ библиотек, вылизываемых годами
— обилии большого числа дешевых и качественных программистов
от языка, который в открытой разработке только три года, все эти три года очень сильно менялся и до сих пор ещё нестабилен, ожидать прямо сейчас как-то странно?
Кстати, Go вполне себе успешный язык и свою нишу потихоньку наращивает. И сложные проекты вроде Docker там уже есть.
От D он отличается гораздо более активным коммьюнити и большей гибкостью в разработке. Rust даже 1 год назад очень сильно отличался от сегодняшнего; Rust 2 года назад — это совершенно другой язык. Авторы языка с помощью сообщества постоянно экспериментируют и пытаются выделить лучшие способы реализации того или иного функционала. Кроме того, он не ставит своей целью быть похожим на C++ — в нём другие инструменты для абстракции, чем в D и C++.
Go же вообще никогда и не собирался быть «убийцей» C/C++. У него совершенно другая область применения, гораздо более близкая к Python/Ruby. Его в принципе нельзя рассматривать как язык для системного программирования, у него для просто нет нужных фич.
Те, кому была важна безопасность уже давно пересели на Java.
Тем не менее, есть очень много тех, кому важна безопасность, но нет возможности использовать что-то более высокоуровневое, чем C/C++. А важность безопасности на самом низком уровне переоценить нельзя — вспомните недавний Heartbleed. В Rust подобные вещи невозможны просто в силу устройства языка и его системы типов/borrow checker'а.
Язык пока ещё в состоянии бета-версии, он не готов для промышленного использования. Сам язык и библиотека очень сильно меняются. Например, в ближайшем будущем будет как минимум два очень серьёзных изменения — типы с динамическим размером и unboxed-замыкания. Поэтому пока что преждевременно говорить о «проектах уровня сложности KDE». И даже несмотря на это один проект похожего уровня сложности уже давно в разработке — это Servo. Да и сам компилятор Rust простым не назовёшь.
Кроме того, полноценным язык с неотключаемой (не в принципе, а на практике — когда отключение GC бессмысленно) сборкой мусора в принципе не может быть системным настолько же, насколько системными являются C/C++.
Это неправда.
&'static strвполне себе конвертируется автоматом в&str.С IDE пока всё плохо. Но другого и ожидать трудно — IDE по сложности разработки и поддержки сравнима с самим языком, и поддерживать её в актуальном состоянии будет очень трудно.
Интеграция с C отменная. FFI в Rust, имхо, лучше только в самом C :)
Да, баги есть, но их не куча. Гораздо меньше, чем могло бы быть, и при этом ICE обычно исправляются довольно быстро, если их отправить в багтрекер Rust.
Документации мало, да, но туториалы и стандартная библиотека обычно поддерживаются в более-менее актуальном состоянии. Никуда не денешься, язык всё ещё в бете.
То же самое. Язык активно развивается, и уж лучше пусть пока будут breaking change-ы, чем зафиксированный неудобный дизайн.
Очень спорно и субъективно. Достаточно на базовом уровне воспринять самые важные концепции языка (aliasing указателей и владение данными), и получится писать сразу почти без ошибок. Никаких сложных концепций, как в метапрограммировании, там нет в принципе. Говорю это по опыту.
Вы хотите сказать, что вот это (первое, что нашёл в гугле; это всего лишь ошибка о том, что в функцию передают лямбду, принимающую string, а надо, чтобы принимала wstring):
prog.cpp: In instantiation of ‘void fill_array(std::array<T, N>&, F&&) [with T = std::vector<std::basic_string<wchar_t> >; unsigned int N = 10u; F = main()::<lambda()>]’: prog.cpp:18:61: required from here prog.cpp:10:9: error: no match for ‘operator=’ in ‘v = main()::<lambda()>()’ prog.cpp:10:9: note: candidates are: In file included from /usr/include/c++/4.7/vector:70:0, from prog.cpp:4: /usr/include/c++/4.7/bits/vector.tcc:161:5: note: std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = std::basic_string<wchar_t>; _Alloc = std::allocator<std::basic_string<wchar_t> >] /usr/include/c++/4.7/bits/vector.tcc:161:5: note: no known conversion for argument 1 from ‘std::vector<std::basic_string<char> >’ to ‘const std::vector<std::basic_string<wchar_t> >&’ In file included from /usr/include/c++/4.7/vector:65:0, from prog.cpp:4: /usr/include/c++/4.7/bits/stl_vector.h:427:7: note: std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(std::vector<_Tp, _Alloc>&&) [with _Tp = std::basic_string<wchar_t>; _Alloc = std::allocator<std::basic_string<wchar_t> >; std::vector<_Tp, _Alloc> = std::vector<std::basic_string<wchar_t> >] /usr/include/c++/4.7/bits/stl_vector.h:427:7: note: no known conversion for argument 1 from ‘std::vector<std::basic_string<char> >’ to ‘std::vector<std::basic_string<wchar_t> >&&’ /usr/include/c++/4.7/bits/stl_vector.h:449:7: note: std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(std::initializer_list<_Tp>) [with _Tp = std::basic_string<wchar_t>; _Alloc = std::allocator<std::basic_string<wchar_t> >; std::vector<_Tp, _Alloc> = std::vector<std::basic_string<wchar_t> >] /usr/include/c++/4.7/bits/stl_vector.h:449:7: note: no known conversion for argument 1 from ‘std::vector<std::basic_string<char> >’ to ‘std::initializer_list<std::basic_string<wchar_t> >’проще, чем вот это, где на чистом английском говорят, что за проблема и где, с подсветкой и чуть ли не тыканьем пальцем?
dangling.rs:3:12: 3:14 error: `i` does not live long enough dangling.rs:3 return &i; ^~ dangling.rs:1:23: 4:2 note: reference must be valid for the anonymous lifetime #1 defined on the block at 1:22... dangling.rs:1 fn dangling() -> &int { dangling.rs:2 let i = 1234; dangling.rs:3 return &i; dangling.rs:4 } dangling.rs:1:23: 4:2 note: ...but borrowed value is only valid for the block at 1:22 dangling.rs:1 fn dangling() -> &int { dangling.rs:2 let i = 1234; dangling.rs:3 return &i; dangling.rs:4 } error: aborting due to previous errorЭто одна из наиболее часто встречающихся ошибок в Rust (когда ссылку передают за пределы её области жизни). У меня сейчас нет рядом компилятора Rust, но если написать аналог кода по ссылке наверху на Rust, то вы получите ясное и недвусмысленное сообщение о том, что типы несовместимы.
А насчёт низкоуровневости — всё достаточно просто. Rust изначально разрабатывался как язык для системного программирования. Например, в D хоть и можно отключить сборщик мусора, но вся стандартная библиотека сразу станет неюзабельной. В Rust сборщик мусора не нужен в принципе, в том числе для стандартных библиотек. Также как только вы отказываетесь от сборки мусора в D, вы мгновенно получаете небезопасность C. Аналогов статического анализа, который проводит Rust для обеспечения правильной работы с ресурсами, сейчас, фактически, нет (за исключением совсем маргинальных языков вроде ATS или Cyclone).
Я писал на D довольно давно (года два назад) и уже прилично подзабыл, как там что, поэтому я не могу сравнить его с Rust полноценно. В целом мне D понравился, но Rust оставляет ощущение гораздо более практичного языка, ИМХО.
от языка, который в открытой разработке только три года, все эти три года очень сильно менялся и до сих пор ещё нестабилен, ожидать прямо сейчас как-то странно?
Кстати, Go вполне себе успешный язык и свою нишу потихоньку наращивает. И сложные проекты вроде Docker там уже есть.
От D он отличается гораздо более активным коммьюнити и большей гибкостью в разработке. Rust даже 1 год назад очень сильно отличался от сегодняшнего; Rust 2 года назад — это совершенно другой язык. Авторы языка с помощью сообщества постоянно экспериментируют и пытаются выделить лучшие способы реализации того или иного функционала. Кроме того, он не ставит своей целью быть похожим на C++ — в нём другие инструменты для абстракции, чем в D и C++.
Go же вообще никогда и не собирался быть «убийцей» C/C++. У него совершенно другая область применения, гораздо более близкая к Python/Ruby. Его в принципе нельзя рассматривать как язык для системного программирования, у него для просто нет нужных фич.
Тем не менее, есть очень много тех, кому важна безопасность, но нет возможности использовать что-то более высокоуровневое, чем C/C++. А важность безопасности на самом низком уровне переоценить нельзя — вспомните недавний Heartbleed. В Rust подобные вещи невозможны просто в силу устройства языка и его системы типов/borrow checker'а.