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

И где там уязвимости языка Java?

Теперь под Java принято подразумевать только язык, а не всю платформу?

Ну OK.

Всякие баги в апплетах это не уязвимости языка.

Из-за багов в апплетах рекомендуется обновить JRE, это нормально.

А где там сказано, в чем ошибка? Может, она в JIT. Или в родном коде. И Java-код тупо не проверяет что-то.

Замени JIT и Java на Rust и стандартную библиотеку Rust. Может они тоже чего-то не проверяют или там где-то ошибка.

Как это поможет человеку, который пишет приложение на Rust-е в предположении о том, что у него в коде будет меньше уязвимостей?

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

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

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

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

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

дальше уж как-нибудь самостоятельно давайте

ну и хотя бы по глагне rust-lang.org можно пробежаться глазами

дальше уж как-нибудь самостоятельно давайте

Те свойства языка, которые декларируются как достоинства Rust-а, я и сам без вас могу посмотреть.

Вы мне без лозунгов скажите зачем Rust лично вам. Вы на нем какие-то утилиты собираетесь делать? Или какой-то фреймворк? Или какую-то прикладную систему для решения какой-то специфической задачи?

Просто мне реально интересно, какой смысл ждать появления стабильной версии Rust, если на том же С++11 уже несколько лет как можно писать продакшен код пользуясь при этом всем многообразием библиотек и инструментов?

Замени JIT и Java на Rust и стандартную библиотеку Rust.

Почему я должен менять JIT на что-то? В Rust просто нет JIT.

Может они тоже чего-то не проверяют или там где-то ошибка.

Наверняка. Но они уже проверяют гораздо больше, чем Си и Си++.

Как это поможет человеку, который пишет приложение на Rust-е в предположении о том, что у него в коде будет меньше уязвимостей?

Что"это" - ошибки? Никак не помогут. А проверки - помогут.

Вы на нем какие-то утилиты собираетесь делать?

да

Или какой-то фреймворк?

нет. разве что, понадобится для предыдущего пункта или следующего

Или какую-то прикладную систему для решения какой-то специфической задачи?

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

какой смысл ждать появления стабильной версии Rust

уже фактически есть. начинать осваивать точно можно

на том же С++11 уже несколько лет как можно писать продакшен код

ну не переваривают некоторые С++, и я из их числа

Просто мне реально интересно, какой смысл ждать появления стабильной версии Rust, если на том же С++11 уже несколько лет как можно писать продакшен код

Ничто не мешает писать «продакшен код» на имеющихся инструментах и при этом интересоваться новыми.

ну не переваривают некоторые С++, и я из их числа

Спасибо!

Типичное мнение школьника, который считает, что уже перестал делать детские ошибки.

Мнения ниасилятора всегоподряд очень важно, держи меня вкурсе.

только по факту С/С++ программы текут и падают.

Чо, прям все? Чота ты как-то пропустил основной посыл сообщения.

Что коряво написаный трейт на супер-пупер русте не грозит порчей данных? Когда тебе нужно в одном порядке байт, а ты читаешь и пишешь в другом, когда данные по смещению 'x', а ты читаешь по смещению (вполне валидному) 'y'. А потом пишешь это в базу, например. От этого тебя руст спасет?

Что"это" - ошибки? Никак не помогут

Походу, какое-то недопонимание.

Есть Java как платформа для разработки ПО. Типа безопасная. По факту оказывается, что в ней находят уязвимости.

Будет Rust. Типа безопасный. По факту в приложениях на Rust-е так же будут находить уязвимости.

И когда приложение на Rust-е окажется «дырявым» из-за проблем в стандартной библиотеке Rust-а, то для разработчика приложения это не будет утешением. Точно так же, как и для разработчика на Java, если уязвимость находят где-то в JRE.

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

Ничто не мешает писать «продакшен код» на имеющихся инструментах и при этом интересоваться новыми.

Вопрос в том, для чего именно интересоваться. Потрындеть на форуме — это одно. Втащить затем в очередной продакшен проект — совсем другое. Хотя бы потому, что пока новый инструмент достигнет стадии стабильности, на старом можно столько всего сделать, что проще будет продолжать пользоваться старым инструментом, чем портировать под новый.

Есть Java как платформа для разработки ПО. Типа безопасная. По факту оказывается, что в ней находят уязвимости.

Будет Rust. Типа безопасный. По факту в приложениях на Rust-е так же будут находить уязвимости.

Адекватный регистрант на ЛОР? да ну нафик! Наверняка лиспом по ночам балуешься?

ну не переваривают некоторые С++, и я из их числа

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

Потому что проблема в тебе, а не в инструменте.

There will always be things we wish to say in our programs that in all known languages can only be said poorly
-- Alan Perlis

:)

Есть Java как платформа для разработки ПО. Типа безопасная.

«Безопасной является система, выключенная и помещенная в сейф. Хотя даже в этом случае меня терзают сомнения» (ц)

Безопасность (любая) - не абсолютный показатель, а относительный. Java гораздо безопаснее Си++. Будешь с этим спорить?

По факту оказывается, что в ней находят уязвимости.

Да. И какой вывод ты из этого делаешь?

И когда приложение на Rust-е окажется «дырявым» из-за проблем в стандартной библиотеке Rust-а, то для разработчика приложения это не будет утешением. Точно так же, как и для разработчика на Java, если уязвимость находят где-то в JRE.

Задача Rust - не утешать разработчиков, а снизить количество уязвимостей.

разработка защищенного приложения — это несколько больший труд, нежели написание кода, который компилируется без ошибок и предупреждений.

А с этим никто и не спорит. Но если компилятор помогает в этой работе, это большой плюс.

Вопрос в том, для чего именно интересоваться.

Научиться чему-нибудь. Получить удовольствие от работы с новым инструментом. Быть готовым, если кто-то предложит писать продакшен на нем. И да, естественно, потрындеть на форумах.

Java гораздо безопаснее Си++. Будешь с этим спорить?

Нет. Но эта безопасность не обходится бесплатно, поэтому C++ еще и существует в тех нишах, где не хотят платить за безопасность такую цену, как в Java. В частности, скоростью и ресурсоемкостью.

И какой вывод ты из этого делаешь?

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

Нужно говорить о конкретных приложениях.

Java гораздо безопаснее Си++. Будешь с этим спорить?

Нет.

О чем и речь. Эту цель Java вполне достигла.

Но эта безопасность не обходится бесплатно

За всё нужно платить. Java платит толстым рантаймом, Rust пытается заплатить хитрой системой типов.

Нужно говорить о конкретных приложениях.

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

Вот это и есть истинная причина =)

это верно, подловил =)

Но скоро ты точно так же начнешь непереваривать Rust

это уже твои влажные фантазии

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

программы на любом языке будут тормозить, течь и падать, до определенного момента. вопрос только в длительности цикла разработка-тестирование, и rust тут выиграет.

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

Потому что проблема в тебе, а не в инструменте

проблема в олдфагах, которые боятся попробовать что-то новое, потому что их многолетний бесценный опыт наступания на грабли вдруг окажется бесполезен

программы на любом языке будут тормозить, течь и падать, до определенного момента.

Именно. Без всяких там «моментов».

вопрос только в длительности цикла разработка-тестирование, и rust тут выиграет.

Какие ваши доказательства? Даже java у c++ тут не всегда выигрывает. Вот питон, например, - да.

проблема в олдфагах

Как они тебе мешают?

боятся попробовать что-то новое

Что в расте нового? Боятся. Только не нового, а сырого. И не попробовать, а в продакшене. И не олдфаги, а прогматики.

их многолетний бесценный опыт наступания на грабли вдруг окажется бесполезен

Глупости. От языка тут мало что зависит.

Прагматики*

Теперь под Java принято подразумевать только язык, а не всю платформу?

Ну если мы про языки говорим, то да, Java это язык + минимальная обвязка, необходимая для функционирования языка. Я думаю в каком-нибудь Swing-е полно багов. Как и в Qt. Баги в апплетах это уязвимости песочницы. И я буду первый, кто бросит в Java-песочницу камень. Она там сделана ужасно.

Из-за багов в апплетах рекомендуется обновить JRE, это нормально.

Смотря где рекомендуется. Если пользователь пользуется апплетами, то рекомендуется. Если пользователь использует Java на сервере или чтобы запускать какой-нибудь Eclipse, то обновлять, конечно, рекомендуется, но не потому, что это может повысить безопасность.

Чо, прям все?

По-моему все достаточно большие.

Что коряво написаный трейт на супер-пупер русте не грозит порчей данных? Когда тебе нужно в одном порядке байт, а ты читаешь и пишешь в другом, когда данные по смещению 'x', а ты читаешь по смещению (вполне валидному) 'y'. А потом пишешь это в базу, например. От этого тебя руст спасет?

Я твой посыл не понимаю. Rust защищает от ряда ошибок, относящихся к определённым классам. Не от всех. И ни один язык не спасёт от всех ошибок. От всех ошибок спасёт только искусственный интеллект, и то не факт. Ты приводишь логическую ошибку, что программист неправильно реализовал протокол. Такое бывает. Для этого принято использовать юнит-тесты (которые, кстати, в Rust очень удобно писать, в отличие от C и в Rust-овых библиотеках обычно довольно много юнит-тестов).

Смотря где рекомендуется.

Вот, вроде бы, полный список уязвимостей.

Там не все касается песочниц. Например, CVE-2015-0488: Applies to client and server deployment of JSSE.

Ты приводишь логическую ошибку, что программист неправильно реализовал протокол.

Внезапно 90% (если не больше) всех ошибок, связанных с памятью это из-за того, что «программист неправильно реализовал протокол», не правильно высчитал смещение, не правильно сконвертил строчку, не правильно ...

Для этого принято использовать юнит-тесты

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

автор треда, зачем писать комментарии будучи анонимом? :D

A flaw was found in the way the JSSE component in OpenJDK parsed X.509 certificate options. A specially crafted certificate could cause JSSE to raise an exception, possibly causing an application using JSSE to exit unexpectedly.

Вылетит неожидаемое приложением исключение. Память не портится, программа не падает (если обработает исключение). Формально, конечно, уязвимость, но ничего страшного от этой уязвимости не будет.

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

Какие ваши доказательства?

Именно. Без всяких там «моментов».

а ваши какие доказательства?

Как они тебе мешают?

кто сказал, что мне? себе разве что.

Только не нового, а сырого. И не попробовать, а в продакшене

дык никто и не заставляет в сурьезный бизнес rust.

Глупости. От языка тут мало что зависит.

от языка зависит количество граблей

Если мудак неосилил сделать, чтоб не текло, ни один инструмент ему кривые руки не выправит.

это женская логика или проявление юношеского максимализма? ты не поверишь, оказывается, ЯВУ предназначены в том числе для избавления головы программиста от деталей, не относящихся к предметной области.

если тебе нравится кушать кактус - это говорит только о тебе. заставляют на работе использовать кактус? соболезную, меня тоже. но этот не повод его нахваливать

верить я уже в него перестал

Почему? Он ещё даже не родился, формально.

Тем временем, в firefox пытаются включить компонент на rust: https://bugzilla.mozilla.org/show_bug.cgi?id=1151899

про отсутствие нормальной IDE

причина для лентяев?

9 страниц о том что очередной убийца с++ вот вот таки сделает то о чём пророчили админы из подвала. Но увы раст будет там где сейчас все остальные убийцы, в выгребной яме где ковыряются одни фрики.

то о чём пророчили админы из подвала.
Избранные теги: Избранные теги: c, pure c, python, syncthing

окай

Нет, нуАЧо? Единственное что не хватает крестам это анализаторов. Да и никто не заставляет использовать всю «мощЪ» крестов.

Единственное что не хватает крестам это анализаторов.

Зато легаси и д'Артагнанов в избытке.

никто не заставляет использовать всю «мощЪ» крестов

Никто не заставляет обезьяну вытягивать чеку - но тем не менее, гранаты им стараются не давать.

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

чего там ублюдочного? Объявление шаблонной функции, потом ограничение шаблонных параметров по соответствию интерфейсам. Сомневаюсь, что можно как-то кардинально сократить объём кода. Точнее, объём сократить можно (как в Хаскел), но затем будут многостраничные непонятные ошибки. А здесь требование обязательного задания типа параметров сильно облегчает задачу генерации понятных сообщений об ошибках.

Главный недостаток - отсутствие нормального компилятора в составе gcc, остальное преодолимо.

Имплементация UNIX-подобной ОС на Rust: http://scialex.github.io/reenix.pdf

Пост автора на Reddit: http://www.reddit.com/r/rust/comments/341v3n/cs_honors_thesis_reenix_implemen...

В статье автор утверждает что Rust в 2-3 раза медленнее C. :(

Ну и? Автор сам написал, что проблема, собственно, в аллокаторах (и их прибитости гвоздями). Так что, да:

It seem to me that using libstd for kernel work in Rust is a bad idea

что, конечно, не очень хорошо - но и не так уж критично.

Кстати, http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go vs http://archive.is/6ipZG (архивированный benchmarksgame за 23.12.14) - т.е. бета довольно таки ощутимо замедлилась.

бета довольно таки ощутимо замедлилась.

Просто часть бенчмарков сломалась.

всё равно будут некоторые runtime проверки, например индексов массива

Автор тоже говорит про «постоянные проверки на выход за границы массива», но это на мой взгляд, не совсем правда. Если мы проходим по массиву, то проверка будет ровно одна, как и в С++. Если хотим по рандомному индексу обратиться, то да придётся проверять, хотя и этого можно избежать, использовав небезопасный код, если уж очень хочется.

Но найдёт куда больше.

Я бы даже сказал иначе: статические анализаторы - это просто набор правил и хитрым кодом их можно «поломать». Да и к «стандарту языка» они прямого отношения не имеют - проверки пишут другие люди и зачастую эмпирически.

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

Переносите все проверки во время компиляции(через зависимые типы, через что угодно). Иначе вы никогда не замените C/C++.

Ну перенеси мне на этап компиляции следующую проверку:

std::vector<не_важно> v;
v[stoi(<строку читаем из файла>)];

А насчёт зависимых типов и т.д. - если слишком сложную систему нагородить, то не захотят ей пользоваться. На сложность С++ жалуются, сколько тут про синтаксис раста ныли, про хаскель и не говорю.

Тогда зачем пилить Rust, если можно запилить статический анализатор?

У нового языка есть большое преимущество: можно учесть ошибки, которые делали другие. С++ не может отказаться от совместимости и местами там всё довольно криво и это уже никогда не исправить. Более того, с добавлением новых фич С++ становится сложнее вы учить - ведь старые возможности никуда не деваются и о них надо знать. Разумеется, это идёт вместе с кучей недостатков: отсутствия библиотек, инструментов и готовых специалистов.

Лично мне раст нравится: borrow checker, семантика владения и всякие приятности типа паттерн матчинга и «всё - выражение». Опять же, «из коробки» идёт много всякого, чего у С++ «не хватает». Например, одна система сборки вместо зоопарка плюсовых. Заодно и «менеджер библиотек» - для С++ такого вообще нет.

И по-моему его пофиксили/пофиксят.

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

если на том же С++11 уже несколько лет как можно писать продакшен код пользуясь при этом всем многообразием библиотек и инструментов?

Я и пишу. Но за прогрессом следить интересно. Опять же, помогает мозги разминать. И из новых вариантов лично мне больше всего раст подходит. Если взлетит «хотя бы» на уровне скалы/Gо - уже хорошо.

хотя верить я уже в него перестал.

Что-нибудь другое «из нового» заинтересовало или вернулся к «проверенным временем» инструментам?

Ну перенеси мне на этап компиляции следующую проверку:
std::vector<не_важно> v;
v[stoi(<строку читаем из файла>)];

Немного оффтопа от другого анонимуса, оказывается clang вместе с libc++ таки умеет оптимизировать при компиляции работу с vector:

~$ cat ./test.cpp 
#include <cstdio>
#include <vector>
using namespace std;

int main()
{
    vector<int> v( 2 );
    v[ 0 ] = 1;
    v[ 1 ] = 2;
    
    int s = 0;
    for( int n : v )
        s += n;
    
    printf( "%d\n", s );
}
~$ clang++-libc++ -std=c++11 -Ofast -S ./test.cpp 
~$ cat ./test.s
	.text
	.file	"./test.cpp"
	.globl	main
	.align	16, 0x90
	.type	main,@function
main:                                   # @main
	.cfi_startproc
# BB#0:                                 # %_ZNSt3__16vectorIiNS_9allocatorIiEEEC2Em.exit
	pushq	%rax
.Ltmp0:
	.cfi_def_cfa_offset 16
	movl	$.L.str, %edi
	movl	$3, %esi
	xorl	%eax, %eax
	callq	printf
	xorl	%eax, %eax
	popq	%rdx
	retq
.Lfunc_end0:
	.size	main, .Lfunc_end0-main
	.cfi_endproc

	.type	.L.str,@object          # @.str
	.section	.rodata.str1.1,"aMS",@progbits,1
.L.str:
	.asciz	"%d\n"
	.size	.L.str, 4


	.ident	"Ubuntu clang version 3.7.0-svn235834-1~exp1 (trunk) (based on LLVM 3.7.0)"
	.section	".note.GNU-stack","",@progbits
~$ 

И сразу выдавать результат, в том числе вообще выкидывая вектор. Это таки круто, скажу я вам. GCC такое не смог, rust тоже.

Это таки круто, скажу я вам. GCC такое не смог, rust тоже.

Это, конечно, круто, но не вижу причин почему бы раст так не смог.

И разумеется, никак не относится к проверки индексов во время компиляции.