Почему вы так фапаете на этот Rust?

Святый боже! Да это же

foo a b = (a, b)

...только тормознее, ибо иммутабельность.

только тормознее, ибо иммутабельность.

а еще strlen

Go

1. Go от гонок не страхует, в отличие от Rust.
2. Мусор.

С нормальной квалификацией у тебя все будет надежно и в C++ в современном его состоянии, с ситуацией в отрасли и пр. А если у тебя с квалификацией проблемы, то никакой Rust не спасёт.

В этом вообще проблема всех убийц C++.

Хотя в целом rust неплох(лучше Go и D)

С нормальной квалификацией у тебя все будет надежно и в C++ в современном его состоянии, с ситуацией в отрасли и пр.

Увы, но твое деление кодеров на царей и анскиллов носит чисто теоретический характер и не выдерживает встречи с реальностью. Вот первый попавшийся гуглёж: https://www.google.ru/?gws_rd=ssl#newwindow=1&q=kernel null pointer deref...

Значит проблема в квалификации. Помимо этого ещё и отсутствие навыков/желания пользоваться инструментами для поиска подобных косяков.

И при чем тут rust? У таких людей и с ним багов будет не меньше.

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

Че дурак?

Значит проблема в квалификации.

Ситуация в отрасли такова, что кодеры одной только силой своего разума не могут в memory safety. Это реальность и реальная проблема.

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

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

Когда поймешь, что для спасения от «говнокода, который портит память» не нужна виртуальная машина - считай, начал понимать современные ЯП.

Вопрос - _зачем_ ты их так месишь?

Меньше выделений памяти => меньше фрагментация кучи со временем. + для сишечки это еще и меньше free => меньше мест, где можно налепить утечек памяти. Еще мог бы наплести про локальность данных, но это не сильно решает в данном случае.

У таких людей и с ним багов будет не меньше.

Каких - «таких»? Почему ты думаешь, что хорошие люди не могут время ото времени допускать подобных ошибок?

И при чем тут rust?

Притом, что rust сообщил бы о возможном null pointer dereference еще на этапе компиляции.

Меньше выделений памяти => меньше фрагментация кучи со временем

Выгодно только для иммутабельных объектов переменной длины.

для сишечки это еще и меньше free

В Rust нерелевантно.

В Rust нерелевантно.

Почему? В Rust исключительно дешёвый free/malloc и нет проблем фрагментации кучи?

Когда поймешь про перестраховку и про безопасное программирование можешь написать мне.

В Rust нерелевантно.

Почему?

kawaii_neko> меньше free => меньше мест, где можно налепить утечек памяти

Когда поймешь про перестраховку и про безопасное программирование можешь написать мне.

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

Про фрагментацию кучи он тоже упоминал.

Про фрагментацию кучи он тоже упоминал.

Ты, похоже, вообще не читаешь постинги, на которые отвечаешь.

Ты, похоже, вообще не читаешь постинги, на которые отвечаешь.

И именно поэтому ты мне ответил не фрагментацией, а утечками памяти, которые были указаны «для сишечки» )

ты мне ответил не фрагментацией

Про фрагментацию я ответил не тебе.

Про фрагментацию кучи он тоже упоминал.

У современных аллокаторов на небольших объектах рандомных размеров проблем с фрагментацией нет. См, например, http://goog-perftools.sourceforge.net/doc/tcmalloc.html

А со стоимостью выделения/высвобождения памяти что?

А со стоимостью выделения/высвобождения памяти что?

А со стоимостью strlen/memcpy что? Почему длина строки не таскается вместе со строкой, а каждый раз вычисляется заново? Почему строки не copy-on-write с подсчетом ссылок (что позволило бы избежать преждевременного выделения памяти и копирования)? Если мы считаем каждое выделение, то почему в коде не рассмотрен отдельно случай, когда выделять ничего не надо, а можно просто скопировать указатели из аргументов функции в тело структуры (передать владение)?

Вывод: обсуждаемый кусок кода — это перемалывание байтов ради перемалывания байтов, бессмысленное и беспощадное.

Мне нравится Julia. Чудесный ЯП.

Эта проблема уже 100500 лет назад решена различными тулзами. А вообще нормальная квалификация приведёт к тому, что такие баги будут случаться раз в год, когда ты с похмелья что-нибудь закодишь. А это жалкие доли процента от общего числа багов. Так что даст нам раст?

Так что даст нам раст?

Людям, которые не делают ошибок, предотвращать которые должна система типов Rust, он ничего не даст // К.О.

Как часто у тебя была такая ошибка и какой процент от твоих багов она составляет?

Ошибки делают все. Вопрос в их частоте и соотношении с общим числом ошибок.

Эта проблема уже 100500 лет назад решена различными тулзами.

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

И да, ололо, тулзы для си/с++! Это ты про уродцев на костылях, вроде cppcheck и valgrind? Они иногда кое-что находят, но ни одна из не может дать гарантий, что твоя программа однажды не скопытится с сегфолтом. Зачем они, такие убогие, теперь нужны?

А вообще нормальная квалификация

Да-да, писать код без ошибок — неужели это может быть сложно? :D

Ты читать умеешь? У меня нет ни слова про отсутствие ошибок. Лучше ответь на вопросы о количестве описанных тобой ошибок и их соотношении с общим числом ошибок. Вспомни свои проекты, посмотри на чужие. А по поводу инструментов не баттхерть, она пользы пока людям принесли больше, чем раст =)

Я просто не вижу смысла переходить на новый язык ради исправления меньше 1% ошибок. При том, что производительность пока не навысоте, синтаксис сомнителен, рантаймные средства фиксированы(придется, скорее всего, что-нибудь своё unsafe'ое пилить в реальной жизни). Да и вообще язык не зарелизен ещё...

Как часто у тебя была такая ошибка и какой процент от твоих багов она составляет?

Давай мою персону оставим в покое, и посмотрим на фактически найденные в продакшн софте уязвимости.
http://cwe.mitre.org/data/lists/658.html
http://cwe.mitre.org/data/lists/659.html

Пройдись глазам по списку, и увидишь, что львиная доля проблем состоит из:
* проблемы с memory safety (всевозможные buffer overflow, use after free, invalid array index, out of bounds, и так далее, и тому подобное)
* проблемы с race conditions
* проблемы с неспособностью отследить время жизни (double free, use of expired file descr, return of stack variable address, и тому подобное)
* проблемы с ненужной мутабельностью (Assigning instead of Comparing)
* проблемы с нарушением типизации

Всё, что я перечислил, в Rust невозможно.

Давай, честно открой ссылки и честно подсчитай. Это действительно впечатляет.

Мой опыт(и я уверен, что опыт тут присутствующих) говорит о малой доле подобных ошибок. И это важнее чьей-либо статистики.

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

От «одиннадцать тысяч глобальных переменных» и подобного не спасёт.

Heartbleed с тобой согласен.

Там вообще присутствуют «обычные» баги? Насколько все это хозяйство репрезентативно?

Мой опыт ... важнее чьей-либо статистики.

Ну, как скажешь.

А ты там код видел? Такое говно редко где наблюдать можно. И такие умельцы и unsafe напишут не думая, дар другой способ наговнять найдут.

и я уверен, что опыт тут присутствующих

Зря так уверен.

Так твой-то опыт о чем говорит?

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

Ну вы, блин, даёте...

Был в восторге от юлечки, пока не попробовал на ней писать программы. Тут и вылезает неадекватность авторов и отсутвие у них опыта. Индексация массивов от единицы? Нуууу, оооокей. Но когда слайсы включают верхнюю границу - это уже явный признак школоты, не читавшей Дейкстру. Потому что в юлии длина l[start:end] не равна разнице между end и start, как во взрослых языках. А равна end - start - 1. Это сраная +/-1 в юлечкиных программах вылазит повсюду. Как и в матлабовских, например. Но зачем мне второй сраный матлаб? Такого говна достаточно одного на весь мир, чтобы он содрогнулся. Но юлечкины родители решили выйти на новый уровень. Все приличные языки приучают писать лаконичный, идиоматический код, и он в них работает. Только не в юлии. Сами авторы на голубом глазу пишут: не надо складывать матрицы так: X = A + B. Надо так: for col=1:n, row=1:n X[row, col] = A[row, col] + B[row, col]. Вдобавок надо помнить, что у юлечке уёбищный порядок индексов, как в фортране (и в матлабе). Такое впечатление, что авторы ходили по помойкам истории и собирали все неудачные решения, от которых в цивилизованном мире давно отказались. Почему в XXI веке компилятор не может оптимизировать векторизованный код? Самое весёлое, что есть костылик Devectorize.jl, который разворачивает векторизованные операции до тупых фортран-стайл вложенных циклов - и они работают быстрее! Почему нельзя встроить это во встроенный оптимизатор? Потому что СРАНЫЕ КРЕТИНЫ. Потому что они всерьёз не понимают, чем плох низкоуровневый код и операции с индексами, чем плоха индексация массивов от 1 и закрытые интервалы. Просто элементарных вещей не осознают, что в тарболе julia-x.x.x.tar.gz дожет быть каталог julia-x.x.x, а не просто julia, что не надо в тарбол julia-x.x.x.tar.gz класть llvm-x.x.x.src.tar.gz, gmp-x.x.x.tar.gz, fftw-x.x.x.tar.gz и ещё килотонну зависимостей. Из какого заповедника они к нам выползли? Строгая типизация - че? join([«a», «b»], None) спокойно нам выдаст «aNoneb» - это что за ПХП вообще? Понятные сообщения об ошибках, удобный бэктрейс? У нас его есть:

ERROR: c not defined
 in include at /usr/bin/../lib/julia/sys.so
 in process_options at /usr/bin/../lib/julia/sys.so
 in _start at /usr/bin/../lib/julia/sys.so (repeats 2 times)
while loading /tmp/generate_latex_symbols_table.jl, in expression starting on line 23

Штоэтааа? Они про бэктрейс только в книжках читали? Пускай попросят маму сегодня перед сном им питон показать - вдруг им что-то умное приснится. А лучше пускай заползут под кровать и поплачут за плинтусом, потому что быть таким безудержным мудаком - СТЫДНО. Вывод редакции - julia не предназдачена для написания программ. Это вообще не язык программирования, а интерактивный калькулятор с расширенными возможностями скриптования. Убедительная просьба в тредах о языках программирования эту поделку не поминать.

Heartbleed с тобой согласен.

Вообще-то Heartbleed — это как раз выход за границы куска памяти. http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html Ты забыл тег «сарказм»?

В Rust нерелевантно.

Если тебе похрен на производительность, безусловно нерелевантно. Кстати, а как вообще управлять памятью без адресной арифметики? Например, slab'ы нарезать? Или «кастомные аллокаторы не нужны»?

Я уже понял, что в стране единорогов эльфы 80-го уровня привыкли к тому, что весь критически важный софт состоит из безукоризненного кода, написанного высококвалифицированными профессионалами как ты сам. Однако, в мире реальном OpenSSL, каким бы говном по твоему мнению он ни был, является самой распространённой библиотекой шифрования, в котором такая «1% случаев» ошибка была допущена. Последствия этой маленькой неприятности, надеюсь, знаешь.

Так твой-то опыт о чем говорит?

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

Ты забыл тег «сарказм»?

Да, я думал, что это очевидно. :(

Вот первый попавшийся гуглёж

в ядре kernel null pointer dereference часто косвенный признак бага совсем иного рода, собственно никто не мешает обмазываться

http://lxr.free-electrons.com/source/include/asm-generic/bug.h#L55