Rust или C++/C?

Question

[Олег]

Стоит смотреть в сторону Rust, если хочется получить высокую производительность и при этом писать не слишком много кода?
Для каких целей предназначен Rust?

Comments

[beduin01]

Как вариант: forum.dlang.org/thread/vipsckjygxscytugezfg@forum....

Answer 1

[Sergey Lerg]

Не правильно поставлен вопрос. Вам для каких целей язык?
Я думаю вы можете смело выбирать между Go, Rust, Java и C#. Что больше понравится.

Comments

[Олег]

Цель: распределенная система с высокой производительностью.

[Sergey Lerg]

Олег: нуууу, посмотрите в сторону Go, он с сетью очень хорошо дружит.

[Владимир Мартьянов]

Sergey Lerg: Посмотрел реализацию MD5 в Go - используется Assembler, не думаю что это говорит о высокой производительности языка.

[Sergey Lerg]

vilgeforce: оценивать производительность всего языка только по реализации функции MD5? Замечательно, просто прекрасно.

[Владимир Мартьянов]

Sergey Lerg: MD5 - хороший пример кода с целочисленной арифметикой и битовыми операциями. И не использовать столь замечательный язык как Go в таком коде - наверное о чем-то да говорит...

[Sergey Lerg]

vilgeforce: всё, что говорит нам реализация md5 на asm это только то, что на asm эта реализация быстрее чем на Go, или вы наивно полагали, что Go окажется быстрее asm?

[Владимир Мартьянов]

Sergey Lerg: Я наивно полагал что она будет сопоставима по производительности, например как Си и Асм для того же MD5. А раз производительность столь сильно отличается, что используют асм - ни о какой высокой производительности речи не идет.

[Sergey Lerg]

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

[Владимир Мартьянов]

Sergey Lerg: Ссылочку на бенчмарки с проигрышем в 5-7 раз для Go по сравнению с сями я уже зопилил в качестве ответа. Найдете более свежие данные - пишите.

[Sergey Lerg]

vilgeforce: ну, вы, конечно и откопали бенчмарк 4 летней давности. Свежие бенчмарки всегда здесь. Имеет смысл сравнивать с C++, Java, C# и Rust.
benchmarksgame.alioth.debian.org/u64q/compare.php?...

[Владимир Мартьянов]

Sergey Lerg: в большинстве случаев Go все равно медленнее, причем в разы.

[Sergey Lerg]

vilgeforce: мне кажется вы мне упорно хотите доказать, что доказывать нет смысла, что C и C++ быстрее Go. Если для вас производительность это единственное, что важно в языке, то смело программируйте на C и ASM. Остальные же выбирают язык из компромисса производительности и удобства использования языка.

Answer 2

[Владимир Мартьянов]

readwrite.com/2011/06/06/cpp-go-java-scala-perform... - работа 2011 года, С/C++ выигрывает у Go в 5-7 раз по производительности даже на алгоритме с контейнерами.

Answer 3

[tzlom]

Если какие-то мелкие проекты - можно рисковать и пробовать Rust. Хоть язык и стабилизировался (хотя я не удивлюсь если будет ещё 2-3 минорных изменения не совместимых с 1.0) нет наработок по best practice, объективно документация страдает (подотстала от языка) и нет чёткого описания всех возможностей сложенного в одном месте. Концепция владения подставляет иногда ногу и привычные вещи делаются не так как обычно.
Это не Rust плохой, это пока малое сообщество, но допустим лично я заинтересован в этом языке, и начал писать минорный проект на нём - чтобы изучить язык и освоиться с новыми концепциями. Возможно реализация владения в Расте - не идеальна, но я думаю в ближайшие 5 лет мы увидим как новые языки подбирающиеся к этой идее, так и надстройки к существующим позволяющие перенять плюсы этой системы, поэтому для себя лично я выделил это как целевое направление изучения и потихонечку копаю.

Answer 4

[afiskon]

Разумеется C++!

Answer 5

[Михаил Потанин]

Код, по сравнению с C++, конечно, сократится, но в скорости разработки много выиграть не получится. "Владение" требует более тщательного продумывания, которое отнимает время.
Ключевая фишка Rust - надежность. Там сложно сделать ошибку, которая потребует сложной отладки и может пролезть в продакшен. Так что проекты с длительным жизненым циклом лучше начинать на нем, несмотря на нестабильность компилятора. Если программу не планируется длительное время поддерживать, то скорее всего выгоднее остаться на C++.