LINUX.ORG.RU

Чисто технические причины НЕ любить Rust [holywar mode activated]

 , ,


3

9

Я тут на досуге посидел с ручкой-бумажкой и выписал штук 10 чисто технических причин, почему Rust, как язык, совершенно ни на что не годится и не нужно тратить время на его изучение. Чисто технических - в смысле, не включающих в себя пункты про отсутствие нормальной IDE, малый размер сообщества, и тому подобные. Не знаю, насколько это кому-то интересно, но предлагаю провести эксперимент. Напишите в комментариях свою версию этих пунктов, а потом сравним. Есть серьезные подозрения, что в Rust намного больше недостатков чисто с точки зрения дизайна языка, чем мне сейчас приходит на ум. Но как с любой другой новой технологией, евангелисты сосредоточены исключительно на преимуществах, закрывая глаза на недостатки.


Напишите в комментариях свою версию этих пунктов

Нет, ты.

LongLiveUbuntu ★★★★★
()

Попытался написать более или менее серьезный проект на rust, но быстро понял, что со всеми этими borrowing и лайфтаймами, я лучше сам за памятью послежу в С++

anonymous
()

Макросы хотелось бы видеть более интегрированные с языком. Например размещение их в namespace-ах, произвольное место вызова, независимость от порядка объявления и т.д. Для самых сложных макросов есть compiler plugins, а вот пользовательские макросы должны быть попроще.

А вообще в Rust мне сложно найти недостатки. Один из немногих ЯП, который практически идеален (в рамках своей применимости). Очень надеюсь, что он выстрелит.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 2)

Я на нём ничего не писал, сам язык не видел, поэтому не люблю. Вы не против, если я тут похоливарю?

crutch_master ★★★★★
()

Унесите в толксы. А лучше, сразу в бложек.

Weres ★★★
()

Я тут на досуге посидел с ручкой-бумажкой и выписал штук 10

врёшь ты всё

Debasher ★★★★★
()

и выписал

Ну и где они?

S-Mage ★★
()

Пока не совсем понятно, смогут ли Result<> и паники полноценно заменить исключения, и будет ли от этого какой-нибудь профит. Borrow checker требует времени, чтобы к нему привыкнуть, но так с любой новой технологией. Синтаксис, кажется, есть дублирующий: struct S<T:Debug> vs struct S<T> where T:Debug.

В остальном особых претензий нет, «совершенно ни на что не годится» - явное преувеличение неосилятора/фанбоя другого «убийцы С++». Но я бы хотел посмотреть на твои 10 пунктов: подозреваю, что «отсутствие GC» будет на первом месте.

anonymous
()

rust хоть и говнецо, но есть мнение что ты тоже с дурнотой

anonymous
()
Ответ на: комментарий от MyTrooName

Да, я как раз и хотел понять, что это за мощный специалист там кукарекает, но, вижу, ты заранее начал оправдываться

anonymous
()
Ответ на: комментарий от MyTrooName

когда будешь считать строчки, учти, что я за rust взялся недели две назад

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

cyanide_regime
()
Ответ на: комментарий от cyanide_regime

рассказывай о его плюсах

где это я о его плюсах рассказываю?

то что лежит по линку назвать либой язык не поворачивается

где это я называю то, что по линку, либой?

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

MyTrooName ★★★★★
()
Ответ на: комментарий от deterok

А он ведь ничего не показал, kokino :)

он сказал, что более-менее серьезный проект забросил на стадии «не осилил borrow check и lifetimes»

MyTrooName ★★★★★
()
Ответ на: комментарий от anonymous

Синтаксис, кажется, есть дублирующий: struct S<T:Debug> vs struct S<T> where T:Debug.

Второй вариант для случаев, когда у типа много сложных ограничений и типов много. И скорее для функций, а не для структур. Сравни

pub fn check_read_write<T, R, W>(value: &T, bytes_hex: &[u8], read: R, write: W)
    where T: PartialEq + fmt::Debug,
          R: Fn(&mut &[u8]) -> s11n::Result<T>,
          W: Fn(&mut Vec<u8>, &T)

и

pub fn check_read_write<
    T: PartialEq + fmt::Debug,
    R: Fn(&mut &[u8]) -> s11n::Result<T>,
    W: Fn(&mut Vec<u8>, &T)
>(value: &T, bytes_hex: &[u8], read: R, write: W)

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 2)
Ответ на: комментарий от Legioner

еще ублюдочнее выглядит, чем многоэтажные шаблоны Александреску.

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

anonymous
()
Ответ на: комментарий от Legioner

блевотненько, даже perl выглядит приятней

anonymous
()
Ответ на: комментарий от anonymous

Попытался написать более или менее серьезный проект на rust, но быстро понял, что со всеми этими borrowing и лайфтаймами, я лучше сам за памятью послежу в С++

Но ведь в C++ всё абсолютно то же самое. Просто в C++ все эти правила применяются неявно, а в Rust-е их контролирует компилятор, не давая шанса проскользнуть ошибке. Все те же техники управления памятью — указатель на стеке; указатель в локальном скопе; указатель передаёт владение кому-то; указатель со счётчиком. Чего не хватает?

Legioner ★★★★★
()
Ответ на: комментарий от MyTrooName

Лол, ты там выше критикуешь кого-то насчет «привиделось» и тут же приписываешь мне слова, которые я не говорил. Люблю такое

anonymous
()

Плохой, негодный вброс.

ymn ★★★★★
()
Ответ на: комментарий от Legioner

Я понимаю, зачем добавили where, особенно в свете associated types. Мне не понятно, зачем оставили старый синтаксис.

anonymous
()
Ответ на: комментарий от Legioner

всего хватает в плюсах. захером еще и руст нужен - сие тайна покрытая мраком мозиловцев

anonymous
()
Ответ на: комментарий от anonymous

ну так залей уже то, что там у тебя было, и померяемся как мужыки

MyTrooName ★★★★★
()
Ответ на: комментарий от Legioner

Простой trade-off. Сложность и проблемы управления памятью в C++ хоть и присутствуют, но сильно преувеличены в массовом сознании, тем более, если говорить о C++11. Поэтому, мне лично проще написать какие-то критичные по производительности куски на C++, а критичные к надежности - оставить на языке с GC. Rust, безусловно, подает надежды, как язык, решающий обе эти задачи, но вот скорость разработки как надежного, так и производительного кода пока хромает в сравнении с комбинацией C++ и Java/Scala/etc. Такое мнение

anonymous
()

Меня больше всего убило когда они выбросили green threads по дефолту и засунули все в библиотеку. Теперь другие библиотеки будут писать в первую очередь для дедовских тредов и это проблема

vertexua ★★★★★
()
Ответ на: комментарий от anonymous

но вот скорость разработки как надежного, так и производительного кода пока хромает в сравнении с комбинацией C++ и Java/Scala/etc

ты сравниваешь скорость разработки на rust без опыта со скоростью разработки на C++ при наличии опыта?

MyTrooName ★★★★★
()
Ответ на: комментарий от MyTrooName

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

anonymous
()
Ответ на: комментарий от MyTrooName

Я не пытаюсь спорить. Я тут свое личное мнение выражаю

anonymous
()

штук 10 чисто технических причин, почему Rust, как язык, совершенно ни на что не годится

1. Высокий порог вхождения - былокодеры ниасиливают и ропщут...

2. плюсовикам кто-то сказал, что rust - замена плюсов, от чего у них дикий батхерт

3. простым сишникам-олдфагам любые новинки как ведро скипидара с патефонными иголками в задницу...

4. го-кодерам rust стал на пути к написанию системного софта

5. d-кодерам перед любым новым языком обидно за развитие своего любимца

ну и т.д.

Это такие-же годные «технические причины», как и весь вброс ТС ))

yyk ★★★★★
()
Ответ на: комментарий от anonymous

не вижу весомых причин отвлекаться на borrow checker

имхо весомая причина - безопасность памяти без runtime оверхеда

если умеешь C++ и, например, Scala

ну да, если умеешь Delphi и, например, Firebird, то тоже нет причин учить C++

MyTrooName ★★★★★
()
Ответ на: комментарий от vertexua

А потом убрали libgreen вообще, теперь в Rust нет зеленых потоков ни в каком виде. Мотивировались, в частности, не очень удачным опытом Go: https://www.reddit.com/r/rust/comments/2l0a4b/do_rust_web_servers_use_libuv_t...

Go's inability to scale is a nice indictment of green threads too. It's a far better green thread implementation than Rust will ever have, because the language is designed around them. It even has a calling convention tuned for fast context switches at the expense of general performance.

anonymous
()
Ответ на: комментарий от MyTrooName

имхо весомая причина - безопасность памяти без runtime оверхеда

ну да, если умеешь Delphi и, например, Firebird, то тоже нет причин учить C++

Опять эти мантры про опасность памяти и сравнения жопы с пальцем

anonymous
()
Ответ на: комментарий от anonymous

Учиться лучше на чужих ошибках, очевидно же.

anonymous
()
Ответ на: комментарий от anonymous

мантры про опасность памяти

опасность памяти - миф, кококо

если умеешь C++ и, например, Scala

сравнения жопы с пальцем

ППКС

MyTrooName ★★★★★
()
Ответ на: комментарий от anonymous

Ну это в 90% случаев балабол...

Мне не нравится, т.к. я этого не пробовал, т.к. мне это не нравится и никто не должен юзать, а те кто юзают - маргиналы и `казлы`.

deterok ★★★★★
()

выписал штук 10 чисто технических причин

Хотелось бы их увидеть.

Unicode4all ★★★★★
()
Ответ на: комментарий от anonymous

Для одного параметра с одним ограничением where как то избыточно смотрится. По-моему сейчас нормально получилось.

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

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

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

Legioner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.