Разработчики операционной системы Redox (https://www.opennet.ru/opennews/art.shtml?num=46919), развиваемой с использованием языка Rust и применяющий концепцию микроядра, представили (https://www.redox-os.org/news/this-week-in-redox-36/) проект по созданию собственной стандартной Си-библиотеки Relibc (https://github.com/redox-os/relibc). Код проекта написан на языке Rust и распространяется (https://github.com/redox-os/relibc) под лицензией MIT. Relibc позиционируется как переносимая реализация стандартной библиотеки Си, соответствующая стандарту POSIX и способная работать не только в Redox, но и в дистрибутивах на базе ядра Linux.Работа над проектом началась 2 марта и функциональность библиотеки пока сильно ограничено, но к разработке уже подключилось 5 участников и проект активно развивается. Ранее в Redox в качестве стандартной библиотеки применялся форк (https://github.com/redox-os/newlib) библиотеки newlib (https://github.com/redox-os/newlib) от проекта Сygwin, но он не устраивал разработчиков с точки зрения безопасности и кросс-платформенности.
Использование языка Rust позволяет избавиться от свойственных языку Си усложнений при организации работы с памятью и задействовать при разработке предоставляемые языком Rust средства по обеспечению безопасного программирования. Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.
URL: https://www.redox-os.org/news/this-week-in-redox-36/
Новость: https://www.opennet.ru/opennews/art.shtml?num=48226
Давайте теперь посмотрим на тесты скорости по сравнению с обычной библиотекой :)
Зачем? Оно не ради скорости делалось. А ради... блин, я х.з. ради чего, но точно не ради какого-либо практического применения.
Для того чтобы показать, что уменьшение скорости выполнения на 10% даже если код абсолютно безопасен, на фиг никому не нужно из компаний, потому что любое уменьшение производительности там, где до этого использовался C - это миллионы американских долларов.
А скорость всегда будет падать?
А если отключить всякие проверки на выход за границы, то оно станет такое же быстрое? (ну небезопасное)
> А скорость всегда будет падать?
> А если отключить всякие проверки на выход за границы, то оно станет
> такое же быстрое? (ну небезопасное)Если отключить проверки, тогда зачем нужен раст?
В Rust все проверки при компиляции проходят.
Тогда насколько они эффективны? Что-то мне подсказывает, что 99% выходов за пределы массива проходит в циклах и т.п. И что тут можно анализировать на этапе компиляции?
> Что-то мне подсказывает, что 99% выходов за пределы
> массива проходит в циклах и т.п. И что тут можно анализировать на этапе компиляции?Спасибо за Мудрость и приоткрытие Изначальных Законов Вселенной!
Хотелось бы знать, видели ли Вы хоть раз суслика в норе и можете изобразить его в мельчайших анатомических подробностях? Если нет, значит ли это отсутствие сусликов в природе вообще или же только видов, проживающих в норах?
Доказать, что индекс всегда внутри правильного диапазона, например. Про rust не знаю, но в каком-нибудь Idris это довольно легко.
Это практически всегда невозможно. А в тех тривиальных случаях когда такая возможность есть, проблема практически не возникает.
>В Rust все проверки при компиляции проходят.ну это как вставить cppcheck какой-нибудь в препроцессор :)
Замечательно.Теперь продолжите логическую цепочку. Почему " cppcheck какой-нибудь " не эффективен для C++ и C ? Потому что язык слишком лоялен к выстрелам в ногу. Теперь делаем язык, такой, что он эффективно интегрирует некий langcheck для проверок во время компиляций. Вот Rust - он по такому принципу сделан
>Почему " cppcheck какой-нибудь " не эффективен для C++ и C ?Как это не эффективен?
Просто язык не лоялен к тем кто делает все наполовину. Сделал char* t = malloc(15* sizeof(char*)); почему не делаешь free(t) ?
> Просто язык не лоялен к тем кто делает все наполовину. Сделал char*
> t = malloc(15* sizeof(char*)); почему не делаешь free(t) ?На раз поймается и valgrind и asan.
Он (точнее, более живые анализаторы) очень даже эффективен для отлова отхода от современных плюсов (с которых, кстати, "безопасные" концепты раста во многом и содраны).
Лайфтаймы, владение и заимствование?
> Лайфтаймы, владение и заимствование?unique_ptr или auto_ptr + RAII.
Но там есть множество других идей, пришедших из ML, которые тоже уменьшают кол-во ошибок.
> unique_ptrТолько если вы при этом ещё запретите get и ссылки на unique_ptr, что вряд ли реализуемо на практике. Владение и заимствование — это не только про то, кто отвечает за удаление объекта, но и про то, кто в него в данный момент может писать и кто может из него читать.
Нельзя линейные (на самом деле аффинные) типы эмулировать unique_ptr'ом, увы.
О! Спасибо, чё-то не задумывался об этом. И тут, значит, уши ML-ей (конкретно - Clean) торчат.Я как-то под эти разговоры, что дескать это С++-v2, совершенно упустил этот момент.
Выход за границы массива бросает исключение в расте. Проверка в рантайм.
> Выход за границы массива бросает исключение в расте.Бросает, да.
> Проверка в рантайм.
Да ладно. Почему же в рантайме, если её можно выполнить статически в compile-time?
> В Rust все проверки при компиляции проходят.Он читает мысли?
Ну точно, так же как и в JAVA.
Сколько ни изобретай свой собственный велосипед с треугольными колёсами, всё равно придётся осилить грёбаные указатели. Мир несправедлив.
Давайте. Но только когда проект дорастёт до первого стабильного релиза.
Это когда версия будет 248.0.3?
Через еще одну неделю.
Скорее всего всё ок, т.к. в rust управление памятью не создаёт оверхеда (все проверки статические, во время компиляции).
Даже для динамических массивов? :) Ну, ребята, ну что же это такое. Почему не разбирающиеся в чем либо лезут комментировать?
То есть проверок для динамических массивов в рантайме лучше не делать?
Мы же про статический анализатор динамических массивов разве нет? :)
Иногда и для них. Rust предоставляет достаточно информации llvm, чтобы тот мог удалять проверку диапазона в некоторых случаях. Например (насколько я помню), когда вы делаете цикл по неизменяемому объекту (например неизменяемой ссылке) и только что получили длину массива, llvm может понять, что вы никогда не выйдите за границу диапазона и удалить проверку.
А если я в цикле присвою счетчику другое значение? А если обращусь к a[i+1] на последней итерации?
Дада, это всё очень просто отлавливается компилятором.
Разве что в самых простейших случаях, типа тела цикла из одного выражения. При наличии других переменных, ветвлений и вызовов функций всё становится совсем не простым для компилятора.
> А если я в цикле присвою счетчику другое значение?for mut i in 0..10 {
println!("{}", i);
i += 1;
}
результат компиляции:
warning: value assigned to `i` is never read
--> tmp.rs:4:9
|
4 | i += 1;
| ^
|
= note: #[warn(unused_assignments)] on by defaultЯ поясню на всякий случай: изменение i на итерации цикла никак не влияет на то, с какими значениями i будет вызвано тело цикла.
> А если обращусь к a[i+1] на последней итерации?
И как это будет выглядеть? Может так?
for i in 0..a.len() {
if i == a.len() - 1 {
println!("{}", a[i+1]);
}
}Или как-то интереснее? В приведённом варианте, компилятор, раскрывая a[i+1], заинлайнит метод a.index(i+1), и таким образом вставит в код проверку i+1<a.len(), а дальше llvm, найдя эту проверку, заметит, что проверка не нужна, потому что если выполняется i==a.len()-1, то i+1<a.len() гарантированно не выполняется, значит можно ругнуться о dead_code и вышвырнуть из кода println!, а затем и весь if тоже, а затем ещё и цикл, потому что это код не имеющий побочных эффектов.
Если мы просто будем обращаться к a[i+1], без всяких условий, то тут есть два варианта. Если цикл пойдёт по диапазону 0..a.len()-1, то проверка внутри цикла будет выкинута оптимизатором как ненужная. Если цикл пойдёт по большему диапазону, то проверка останется, потому что оптимизатор не сможет доказать, что она не нужная, и в этом случае мы собственно и получим панику на этапе выполнения.
А если компилятор для цикла 0..a.len() сможет вычислить точный размер a на этапе компиляции, то, я подозреваю, он сделает цикл по диапазону 0..a.len()-1, который не будет содержать проверок, а после цикла вызовет panic! (тот который должен был случится, в силу выхода индекса за границы массива). То есть там будет одна проверка на весь код, и эта проверка будет связана с организацией цикла. Если конечно компилятор не развернёт этот цикл, так чтобы он превратился бы в линейный код.
Все эти вещи компиляторы C тоже умеют делать не хуже чем компилятор rust'а, вы можете поизучать эти возможности оптимизаторов даже не связываясь с rust'ом, для этого достаточно освоить опции -S, -fverbose-asm, и ещё полезно подчастую -Os вставлять вместо -O2 -- так ассемблерный выхлоп получается понятнее человеку, правда это искажает результаты оптимизации. И я очень рекомендую поизучать их, потому что использование C без знания того, как компилятор генерит код -- это... я не знаю, как это назвать, но это совершенно неправильно. Так не выйдет писать хороший код на C, можно писать что-нибудь в стиле exim, но не хороший код.
Ох уж эти титеретики
fn main() {
let a: [i32;5]=[1,2,3,4,5];
for i in 0..a.len() {
if i == a.len() - 1 {
println!("{}", a[i+1]);
}
}
}Compiling playground v0.0.1 (file:///playground)
Finished release [optimized] target(s) in 0.59 secs
Running `target/release/playground`
thread 'main' panicked at 'index out of bounds: the len is 5 but the index is 5', /checkout/src/libcore/slice/mod.rs:830:10
note: Run with `RUST_BACKTRACE=1` for a backtrace.
И? Вы хотите сказать, что проверка осталась и выполнялась на каждой итерации цикла? Что вызов panic! не был вынесен за пределы цикла? Или что вы хотите этим сказать?
.type _ZN3tmp4main17hd307395e913df02cE,@function
_ZN3tmp4main17hd307395e913df02cE:
.cfi_startproc
pushq %rax
.Lcfi0:
.cfi_def_cfa_offset 16
leaq panic_bounds_check_loc.1(%rip), %rdi
movl $5, %esi
movl $5, %edx
callq _ZN4core9panicking18panic_bounds_check17ha7f06c957d05f2e3E@PLT
ud2
.Lfunc_end0:
.size _ZN3tmp4main17hd307395e913df02cE, .Lfunc_end0-_ZN3tmp4main17hd307395e913df02cE
.cfi_endprocЯ даже не поленился и посмотрел. С -C opt-level=2 (в коде приведённом выше) цикл был выкинут вообще, и вся функция была оптимизирована к вызову паники. С opt-level=s почему-то остался пустой цикл, а вызов паники был вынесен за пределы.
> и вся функция была оптимизирована к
> вызову паники. С opt-level=s почему-то остался пустой цикл, а вызов паники
> был вынесен за пределы.С одной стороны это круто, с другой - компилятор явно недоделан, а с третьей, получается, можно статически анализировать не только исходный код, но и сгенерированный машинный код (это может дать доп. результаты, особенно с LTO).
>> и вся функция была оптимизирована к
>> вызову паники. С opt-level=s почему-то остался пустой цикл, а вызов паники
>> был вынесен за пределы.
> С одной стороны это круто,Сегодня это уже не круто, это нормальное поведение для любого уважающего себя компилятора. Собственно всё это даже не столько заслуга rust, сколько llvm. Я говорю: и clang, и gcc проворачивают то же самое с C'шным кодом. Если этот код переписать на C, добавив туда явную проверку на выход за границы массива и вызов функции panic, если это случается, то и clang, и gcc сгенерят практически такой же код, может быть даже ровно такой же байт в байт.
> с другой - компилятор явно недоделан,
Я бы сказал, что язык недоделан, а не компилятор. Но, может быть, это без разницы.
> с третьей, получается, можно статически анализировать не только исходный код, но
> и сгенерированный машинный код (это может дать доп. результаты, особенно с
> LTO).Можно анализировать статически всё что угодно, но зачем? Какие, например, доп. результаты мы можем получить при анализе машинного кода?
> Собственно всё это даже не столько заслуга rust, сколько llvm.Ох.
> Можно анализировать статически всё что угодно, но зачем? Какие, например, доп. результаты мы можем получить при анализе машинного кода?
После большого количества inline'ов и всяких мудрых мыслей может получиться, что функция редуцируется до panic, как тут, что довольно неприятно.
>> Можно анализировать статически всё что угодно, но зачем? Какие, например, доп. результаты мы можем получить при анализе машинного кода?
> После большого количества inline'ов и всяких мудрых мыслей может получиться, что функция
> редуцируется до panic, как тут, что довольно неприятно.Такие вещи будет сложно отловить анализируя чисто машинный код, всё равно придётся сравнивать семантику описанную в сорце с семантикой машинного кода. Поэтому статические анализаторы сами не дураки проделать работу компилятора и редуцировать код, выкинув оттуда всё то, что не несёт смысловой нагрузки. Собственно, а как иначе можно вычислить условие которое всегда выполняется или код, который никогда не выполняется?
> .type _ZN3tmp4main17hd307395e913df02cE,@function
> _ZN3tmp4main17hd307395e913df02cE:О да. Вот что они взяли из плюсов - так это вот это. А в сях таки в этих случаях нормальные названия функций вместо этого птичьего чирикания. Что сиииильно упрощает разборку с программой :). Как угодно но читать в инстурментах вот такое птичье чирикание - желания никакого.
> Как угодно но читать в инстурментах вот такое птичье чирикание -
> желания никакого.Что, так сложно накидать скрипт, который будет парсить такой вывод и деманглить имена?
>> Как угодно но читать в инстурментах вот такое птичье чирикание -
>> желания никакого.
> Что, так сложно накидать скрипт, который будет парсить такой вывод и деманглить
> имена?c++filt вполне себе справляется;
(Код из #73)
% cat /tmp/tst
.type _ZN3tmp4main17hd307395e913df02cE,@function
_ZN3tmp4main17hd307395e913df02cE:
.cfi_startproc
pushq %rax
.Lcfi0:
.cfi_def_cfa_offset 16
leaq panic_bounds_check_loc.1(%rip), %rdi
movl $5, %esi
movl $5, %edx
callq _ZN4core9panicking18panic_bounds_check17ha7f06c957d05f2e3E@PLT
ud2
.Lfunc_end0:
.size _ZN3tmp4main17hd307395e913df02cE, .Lfunc_end0-_ZN3tmp4main17hd307395e913df02cE
.cfi_endproc
% c++filt < /tmp/tst
.type tmp::main::hd307395e913df02c,@function
tmp::main::hd307395e913df02c:
.cfi_startproc
pushq %rax
.Lcfi0:
.cfi_def_cfa_offset 16
leaq panic_bounds_check_loc.1(%rip), %rdi
movl $5, %esi
movl $5, %edx
callq core::panicking::panic_bounds_check::ha7f06c957d05f2e3@PLT
ud2
.Lfunc_end0:
.size tmp::main::hd307395e913df02c, .Lfunc_end0-tmp::main::hd307395e913df02c
.cfi_endproc
Не пользуюсь, но все равно - большое спасибо. Когда-нибудь точно пригодится.
Я хочу сказать ровно одно, сказанное титеретиком не выдержало проверки практикой. Но так как ты страдаешь избирательной амнезией, то я процитирую, что именно ты сказал: "гарантированно не выполняется, значит можно ругнуться о dead_code и вышвырнуть из кода println!, а затем и весь if тоже, а затем ещё и цикл, потому что это код не имеющий побочных эффектов."
> Но
> так как ты страдаешь избирательной амнезией, то я процитирую, что именно
> ты сказал: "гарантированно не выполняется, значит можно ругнуться о dead_code и
> вышвырнуть из кода println!, а затем и весь if тоже, а
> затем ещё и цикл, потому что это код не имеющий побочных
> эффектов."А, ну да, я там ошибся -- я всё ж не компилятор. Но давай вернёмся тогда чуть назад: мы ведь говорим о лишних проверках в рантайме нет? Я тебе дал ассемблерный листинг, в нём нет ни одной проверки. Немного не по тем причинам как я ошибочно описал: условие цикла гарантированно выполняется на последней итерации и гарантированно не выполняется на предыдущих, компилятор может это доказать, что позволяет ему оторвать последнюю итерацию от цикла статически и реализовать её отдельно. При таком подходе ни одна проверка не нужна, и поэтому ни одной проверки в коде нету.
Ещё какие-нибудь возражения у "практика" есть?
> Скорее всего всё ок, т.к. в rust управление памятью не создаёт оверхеда
> (все проверки статические, во время компиляции).И как статически проверить конкатенацию 2 строк вводимых юзером, например?
> Код проекта написан на языке RustБла-бла-бла, математика использует openlibm, а оно на C.
Алокаторы памяти и прочие низкоуровневые вещи регулярно пестрят unsafe блоками, что автоматически нивелирует все "плюшки" Rust'а.
Есть примеры?
Модуль реализации строк посмотри.
> Есть примеры?
Лучше молчи... Когда я сказал что без unsafe на rust далеко не уедешь, любители смузи меня тапками забросали. Им что то объяснять себе дороже.
> тапкамикедами
Вот и выросло поколение школьников, которое думает, что кеды придумали хипстеры...
Вообще касательно самого языка.
Идея хорошая, только зря они его назвали "rust".Большинство не захотят пользоваться "ржавчиной" и "коррупцией", пусть даже рассказывают, что это на самом деле такой грибок.
В итоге все заглохнет. И проекты на нем тоже. Будет еще хуже, чем с D.
А жаль, был бы неплохой язык, если бы не название.Это еще как с OS Fiasco.
Ой, оказывается это такая итальянская бутылка!
А в итоге кто ее использует?
>OS FiascoЭто когда FreeBSD переименовать успели?
У вас фиаско с FreeBSD?
Надо ([кому?]) переписать игру Rust на язык Rust.
И что? Похоже вы как и многие не правильно понимают назначение unsafe (так же как многие не правильно понимают значение "свобода слова" или "независимая пресса" и лепят в них собственные определение. простите за политоту.).Unsafe не что-то плохое в rust, в вполне сознательно сделанная вещь. Она позволяет создавать эффективные реализации, предоставляя к ним безопасный интерфейс для всей остальной программы. Если вы например написали реализацию двунаправленного списка при помощи unsafe, то очевидно, что вам придётся покрыть её изрядным количеством тестов, чтобы убедиться, что во всех возможных случаях код будет работать правильно, а в указателях никогда не окажется некорректных значений.
С другой стороны, безопасный интерфейс к такому списку избавит вас от необходимости покрывать такими же тестами остальную прогрумму. Там этим займётся компилятор.
Хорошим примером такого подхода является языки C/C++, где программисты регулярно лажают от лени или усталости забывая вставлять проверку указателей на каждом шагу или делая это неправильно.
О чем и речь, что в коде там дофига unsafe и смысла писать на Rust нет.А вообще, еще до Rust'а были "безопасные" варианты C, Cyclon например.
Да и вообще, к тому-же GCC / Clang приписать пару пачку проверок и поставить их в -Werror.
А -fpermissive можно? А то на с++ такое бывает...блаблабла предупреждение: декларация ничего не описывает [-fpermissive]
# define off_t long
Да можно typedef-ом, но за что препроцессор?
> О чем и речь, что в коде там дофига unsafe и смысла
> писать на Rust нет.Смысла есть - во-первых, внутре unsafe тоже rust, а не C. Во-вторых, ошибки бывают разные, причём большая часть ни к каким segfault'ам не приводит. В Питоне, например, довольно тяжело сделать выход за границы выделенной интерпретатору памяти, однако написать программу в 1000 строк без дюжины ошибок совершенно невозможно.
Rust'овские владения, частичный вывод типов, неизменяемые объекты по-умолчанию и т.д. отсекают ряд ошибок, в том числе и такие, что ни к каким падения не приводят, а ведут к неправильным результатам.
>Unsafe не что-то плохое в rust, в вполне сознательно сделанная вещь. Она позволяет создавать... хоть как то работающие программы :) Не надо песен, у нас их тоже есть!
>С другой стороны, безопасный интерфейс к такому списку избавит вас от необходимости покрывать такими же тестами остальную прогрумму. Там этим займётся компилятор.
Наивняк! :) Это уже было. Да - Java promise :) Чем всё кончилось? Покрывают тестами __всё__! И это правильно, ибо нефиг. И у вас тоже самое будет, всё суета сует :-)
>Хорошим примером такого подхода является языки C/C++, где программисты регулярно лажают от лени или усталости забывая вставлять проверку
Оу-е бэйби! А ржавчики будут кодячить без усталости и лени! :-))))) Гив ми море! :)
Может оно и взлетит, но взлетит вопреки. Ибо нафиг оно - до сих пор не очевидно.
Вы так ничего и не поняли.> Это уже было. Да - Java promise :)
Бессмысленное сравнение. В Java (визитной карточкой которого является NullPointerException) такае навеска - как фаервол с политикой "пропускать" и попытка сделать надёжным, путём кучи запрещающих правил. Unsafe это необходимая дырка в запрещающем фаерволе. Rust потому и бесит многих, что похож на фаервол с политикой "запрещать".
> Покрывают тестами __всё__!
Я не знаю как там в Java, не видел много Java, но судя по регулярным статьям о PVSStudio - нет, не покрывают. Хуже того, некоторые сознательно даже кое-каких проверок не вставляют, рассчитывая, что пусть оно лучше упадёт. Забывая, что в C/C++ это UB.
> А ржавчики будут кодячить без усталости и лени! :-)))))
Как я говорил - вы ни фига не поняли. "Ржавчики" такие же люди, по этому язык исключает ситуации, когда эта возня понадобится. Внутри безопасного кода не может возникнуть null или висячий указатель.
> Внутри безопасного кода не может возникнуть null или висячий указатель.Все объекты, используемые хоть раз в программе, что, сразу нужно инициализировать (создавать) и до отказа по ошибке OutOfMemoryError? В надёжной безопасной программе разве запрещено динамическое/"ленивое" создание объектов, когда ссылка на объект есть, но самого объекта нет - он будет создан и инициализирован в момент обращения к нему? Тогда готовьте разориться на оперативную память для инициализации всего и вся в момент старта программы.
Да забей ты. Поносятся годик второй с этой модной молодежной поделкой. Накопится достаточное количество реальных проектов, и все вернется на круги своя.К сожалению, ничего принципиально нового с момента изобретения первых языков так и не появилось, все эти "языки" похожи на дистрибутивы - разные коктейли Лиспа и Фортрана с втаскиванием внешних инструментов внутрь "языка", с немножко разной степенью удобности использования.
Смешно, когда начинаются баталии тупоконечников против остроконечников, по сути пережевывающие одно и то же яйцо.
> ссылка на объект уже есть а объекта еще нетВы сами то поняли, что сказали? Типа указатель у нас уже есть на память, но там ещё ничего нету, а появится магическим образом как только мы туда обратимся? Или это какой-то умный указатель? Так таких указателей можно и в русте наклепать. Или хотите чтобы у вас такие вещи автоматом работали? Ну тут в примитивных ситуация и джавка справится и gcc и rust, а в сложных только всякие Haskell и тому подобные.
>> ссылка на объект уже есть а объекта еще нет
> Вы сами то поняли, что сказали?https://en.wikipedia.org/wiki/Lazy_evaluation
Это ничего, что Вы чего-то не знаете.
Плохо, что Вы делаете из этого неправильные выводы.
Скушайте немного этих мягких https://www.microsoft.com/en-us/research/wp-content/uploads/... французских микрософт-рисиорчей, да выпейте жж водички.
Ну а ещё есть Option<T>, который от null отличается тем, что если в нем лежит НИЧЕГО, то и попробовать обратиться к T не получится.
"Работа над проектом началась неделю назад и функциональность библиотеки пока сильно ограничена" - ну и смысл в таких новостях? Когда что-то хотя бы слегка живое будет - тогда и поговорим. И даже после этого - в реальном применении возникнет миллион нюансов, частных случаев и прочего, и только после возни с ними станет понятно, жизнеспособна идея или нет.
> Работа над проектом началась неделю назадВопрос, дотянет ли оно хотя бы до четвёртой недели.
Первый релиз нового быстрого офиса, без глюков работающего с doc и docx:int main()
{
return 0;
}Посоны, заходите коммитить, я создал!
exit(EXIT_SUCCESS);
Вот! Уже можно ещё одну новость писать про значительные улучшения, про сообщество с патчами и даже честно можно приложить ченджлог!
Смысл новости в подтексте видимо, который такой: некоторые люди считают, что rust уже достаточно зрел для того, чтобы переписать на нём libc.
Пиарят Rust как могут. Только лучше бы толковых библиотке понаписали и примеров понаделали, а то быстрое знакомство с языком пока только рвотный рефлекс производит. А это сразу отворачивает всех.
С нетерпением жду когда питонисты подхватят знамя и напишут стандартную либу для сишников.
> С нетерпением жду когда питонисты подхватят знамя и напишут стандартную либу для сишников.Там "знамя", AFAIK, немного не о том.
Поэтому питонистам придется сначала написать свою ОСь на питоне и Pylibc под нее, а потому уже думать о портировании на прочие ОСи.А вообще, некоторым опеннетчикам не угодишь:
Использовали cишный – "Фи! Не осилили даже стандартный ОСевой рантайм на своей ржавчине для своей игрушки написать!"
Начали писать на ржавчине – и опять все не так, "Бласфемия! Да как они смеют!".Как будто следующим шагом будет принудительная установка и использование под страхом отлучения от интернета.
> Поэтому питонистам придется сначала написать свою ОСь на питоне и Pylibc под
> нее, а потому уже думать о портировании на прочие ОСи.Они бы может и написали, но если растаманы только немного подтыривают си и асм, питонисты без этого вообще ничего системного не могут. Так что только зубами щелкают.
> Использовали cишный – "Фи! Не осилили даже стандартный ОСевой рантайм на
> своей ржавчине для своей игрушки написать!"Ну, хорошо, уговорил. В ненужно-ос появилась ненужно-либ. А чтобы это за игрушку не считали - наверное, авторам и фанатам неплохо бы своей операционкой пользоваться. Хотя-бы для себя. Для своих повседневных задач. Ну или нафиг еще операционка может быть нужна?
> Ну или нафиг еще операционка может быть нужна?Ну а нафиг на опеннте еще одно (не)нужное мнение о (не)нужности (не)нужного!?
"Just For Fun!"(c)
Очередной пеар от раст боев.
У раста ещё меньше каких то полезных работающих проектов чем у го.Кроме пеара в общем то у обоих новых языков ничего и нет, на фоне мира си и крестов.
>раст боевЧто, так и хочется сказать прямо, да? ;)
Зачем тащить этот образчик, как не надо делать в новую ось?
Избыток свободного времени и неумение найти ему лучшее применение.Давайте перепишем окаменелости мамонта 100500 раз, но на этот раз с хрустом, а не на JS.
> избавиться от свойственных языку Си усложнений при организации работы с памятьюи приобрести 5 новых типов указателей.
> Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателямиОсобенно при написании функции strlen, например. Или при реализации printf.
Кстати, любопытно как они собираются разруливать varargs, если rustc вечно настаивает на том, чтобы сохранять за собой возможность точно рассчитать на этапе компиляции размер стека, который требуется для программы.
Про безопасность ранней Жавы говорил что-то схожее "безопасности" нынешнего сырого хруста в руках малолетних фанатиков :)
Вот! Просто таких старых как мы с тобой уже почти не осталось, другие забыли, а новые - и не знали никогда! :-)
Безопасненько#[no_mangle]
pub unsafe extern "C" fn strncat(s1: *mut c_char, s2: *const c_char, n: usize) -> *mut c_char {
let mut idx = strlen(s1 as *const _) as isize;
for i in 0..n as isize {
if *s2.offset(i) == 0 {
break;
}*s1.offset(idx) = *s2.offset(i);
idx += 1;
}
*s1.offset(idx) = 0;s1
}
Так и запишем: go для безделушек типа сервисов, rust для системных безделушек. Хотя, если не загнутся, и те и те могут оказаться полезными.
> Так и запишем: go для безделушек типа сервисов, rust для системных безделушек.
> Хотя, если не загнутся, и те и те могут оказаться полезными.Они полезны. Одно выпячивает титиретиков от програмизма и прочих страдальцев фигней, которых к нормальным проектам лучше не подпускать. Второе - надежно диагностирует хипстеров.
Заметьте, снова под нормальной свободной лицензией (MIT), а не вирусным несвободным недоразумением от ГНУ.Скоро отовсюду его выкинут, уже к либку подбираются. МОЛОДЦЫ!!!
Кстати да, MIT лицензия может стать очень серьёзным конкурентным преимуществом данной реализации. Ибо, насколько я знаю, все реализации libc, которые хоть сколько нибудь живы нынче под прости господи копилефт лицензиями.
Не ново. Musl несколько лет уже есть, он под MIT.
Чем бы дитя не тешилось...
> Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.Интересно, а malloc (и вообще работу с динамической памятью) они в этой библиотеке каким образом реализовали?
Похоже, ребята придумали такую "безопасную версию" пилорамы - с циркулярной пилой без зубьев. А когда на ней нужно что-нибудь распилить, пилу нужно временно поменять на нормальную, с зубьями. Зато она теперь Безопасная, чо.
> Интересно, а malloc (и вообще работу с динамической памятью) они в этой
> библиотеке каким образом реализовали?https://github.com/redox-os/relibc/blob/1b1ff5c750cac0db2324...
pub unsafe extern "C" fn malloc(size: size_t) -> *mut c_void {
let align = 8;
let ptr = ralloc::alloc(size + 16, align);
> Похоже, ребята придумали такую "безопасную версию" пилорамы - с циркулярной пилой без
> зубьев. А когда на ней нужно что-нибудь распилить, пилу нужно временно
> поменять на нормальную, с зубьями. Зато она теперь Безопасная, чо.Похоже, опять пришла пора притянутых за уши аналогий?
Просто воспользоваись общим прогрессом последних 30 лет, установили МК, кучу сенсоров и управляющий комп, отключающий питание и мгновенно перекрывающее физический доступ с самых опасных направлений. А еще бьющий током злостных нарушителей техники безопасности.
В итоге травматичность снизилась на порядок, особенно среди новичков. Но ветераны, с некомплектом пальцев на руках, говорят, что все фигня это и достаточно было просто пообвыкнуть и не щелкать клювом.