Опубликован релиз языка системного программирования Rust 1.55, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=55775
Язык недалёкого будущего. Отлично развивается!
> недалёкого будущегоВ том-то и дело. Сляпали - и так пойдет!))
Паскаль тоже сляпали. Причем меньше людей. И что? Паскаль впосле себе жив, и приятен. Но непопулярен.
мaнямирок такой мaнямирок. легаси-хлам на дельфи != паскаль
Lazarus тебе привет передаёт
Давайте не будем говорить про язык программирования идеологического врага )))
В отличии от Раста, который до сих пор сочиняется -- Паскаль был спроектирован.
Никлаус Вирт правильно сделал что не стал все пихать в Паскаль, а сделал новый язык Оберон, который как раст никому был не нужен и все могли спокойно использвать Паскаль.
из оберона вырос Oberon-2, Component Pascal, Active Oberon, Zonnon, Oberon-07.
Если бы назвал Oberon-007, наверное, бы хайпанули :)
> И переписывают на ВЕРИФИЦИРУЕМОМ диалекте АДА лучшие решения и алгоритмы с C и Rust.Ну с Си понятно, много десятилетий существования, миллиарды строк кода и миллионы ошибок в нём, и, соответственно, "лучших решений" для переписывания там можно нарыть на сотни лет работы сотне разработчиков. А с раста они что взялись переписывать - рендерер мозиллы, Actix и фанатскую ОС Redox? Или просто основной репозиторий crates.io отсортировали в алфавитном порядке и начали весь переписывать? Или понавыдергивали из него куски? Очень любопытно по расту, просветите.
сорри, промахнулся, отвечал на коммент ниже
В конце 70-тых французы от департамента обороны США получили контракт на разработку правильного и безопасного языка. В 1983 вышла ADA. В школе нам его упоминали как ответвление от Паскаля. Думал что язык АДА не используется и мертв.Недавно, чисто случайно узнал что на современном ВЕРИФИЦИРУЕМОМ диалекте АДА в ЕС активно пишут софт. Написали матверифицированное ядро ОС системный и прикладной софт. И переписывают на ВЕРИФИЦИРУЕМОМ диалекте АДА лучшие решения и алгоритмы с C и Rust.
А местные рестораны в курсе языка ADA и то что люди переписывают софт с Rust на верифицируемый диалект ADA для пущей безопасности?
Что все 3 разработчика?ПС. тоже интересовался ADA - прямая дорога с PLSQL, но нарыл другую информацию
В основном ADA сейчас применяется в следующих областях:
1) в мин. обороны США
2) в авиации, но применение сокращается
3) в электронике, но там тоже сокращается применениеКомпилятор GNU ADA - не очень хорош, да и коммерческие компиляторы тоже ругают.
Проигрывает компиляторам C++ (но обеспечивает лучшую защищенность).Разработчики уходят от этого ADA на C++
3 пользователя, но зато какие эти пользователи. На самом деле пользователей больше чем 3.Речь шла не о АДЕ, а о ВЕРИФИЦИРУЕМОМ диааекте ADA: SPARK.
Гугли SPARK !
Тоже мне новость.
У нас ПО для спутников пишут на Modula-2.
Чем сочинение Rust-а -- не проектирование?
Паскаль действительно сляпали, но до вмешательства Борланда, он не только не был приятен, а вообще непригоден к практическому использованию.
Борланд постарался в развитии и популяризации языка, но концептуальные рудименты и неудобства исходного языка дали о себе знать.
Надо было не стесняться и менять всю систему.
>Паскаль действительно сляпали, но до вмешательства Борланда, он не только не был приятен, а вообще непригоден к практическому использованию.А ты не будь формошлёпом. Паскаль создавался не для формошлёпов.
Именно, что недалекого. Язык становится таким же, как и программисты под него. Недалекие.
А ваша-то какая боль? Не нравится - не пользуйся. "Большим умом не блещешь ты, отнюдь..."
> А ваша-то какая боль?Та, что чуть пониже спины.
Очевидно же.
>> Dzen Python
> Именно, что недалекого. Язык становится таким же, как и программисты под него.
> Недалекие.А ты самокритичный!
>Язык становится таким же, как и программисты под него.Ну вот "прям в точку", юзер с Python в нике:)
Недалёкого от слова "недалёкий".
Он так и сказал, в чём проблема?
недалёкий язык
недалёких людей
недалёкого будущего
- всё верно
недалёкие комментарии недалёких людей.
>недалёкого будущегоКакие люди, такое и будущее.
Прекрасное далёко, не будь ко мне жестоко
> недалёкого будущегоБудущего недалекого.
Fixed не благодарите
Уже столько лет смотрю на все это и никак не могу понять зачем этот раст нужен, а судя по синтаксису и непонятно чем заблобленому исходному коду - причина нужна железнейшая. Только искуственно создавать эти причины научились загаживая нормальные проекты хрустом. Деградация, а не будущее в светлом его понимании.
FreeBSD на PowerPC?
В природе есть такие реальные конфигурации?
Даже гента на powerpc существует.
Да никто не спорит что что-то где-то всегда может быть. Вот дум вообще не фотоаппарате запустили, и что?
powerpc64le, если я правильно понимаю, это POWER8 и новее. Сервера, кластеры и т.д. Кто туда в здравом уме bsd будет ставить. При официальной поддержке линукса. Ну, кроме ситуации "а вот смотрите что мы по приколу сделали".
Есть же воркстейшены от Raptor CS
Как 20 лет на сервер поставили FreeBSD так она там и стоит.
Работает - не трогай! ;)
> Работает - не трогай! ;)А то внедрившегося 10 лет назад трояна разбудишь...
У него уже управляющий сервер потух потому что админ ботнета закончил школу.
>Как 20 лет на сервер поставили FreeBSD так она там и стоит.Хоть раз включать пробовал? Ну признайся - мы никому не расскажем.
>Даже гента на powerpc существует.Гента-то не удивительно, она на широкоиспользуемом ядре основана, где поддержка POWER на должном уровне.
PowerPC, а не POWER. Первый - урезанная версия второго.
Где-то наверное есть :). После того как оно в своей дефолтной установке после запуска ядра не нашло свой root - больше не пытался смотреть :D. (PowerMac G5 Quad, PPC64)
Ну что сказать
Хороший релиз хорошего современного языка с хорошим синтаксисом.
Жирнишь
> с хорошим синтаксисом.Такой себе. У JavaScript и Python гораздо лучше. А из новых языков вон у Nim вроде норм.
Ты это серьёзно насчёт Javascript?
Он просто решил обогнать Эмальку по количеству жЫра.
А что не так, лол?
===
Всего то лишь, и то как следствие отсутствия типизации. Или надо было больше ??*::()}{[] добавить?
>Или надо было больше ??*::()}{[] добавить?Надо было их отступами заменить ;)
>Или надо было больше ??*::()}{[] добавить?Диакритик насовать забыли. Всех, которые есть в юникоде для дойча, французского, вьетнамского и прочих. Непременно каждую с особым смыслом-модификатором. (Кто пытался учить вьет, тот поймёт...)
> Ты это серьёзно насчёт Javascript?А что? Я про язык (синтаксис), а не сам рантайм. Никто ж не запрещает написать компилятор JS в машинный код, чтобы можно было и системным программированием на нём заниматься. (ну, для этого в язык придётся ещё что-то опционально добавить, режим строгой типизации, например, но не суть).
Как будете компилировать eval()?
> Как будете компилировать eval()?Такую функцию не обязательно реализовывать вообще.
> pythonЛюбые языки с блоками через пробелы / табуляции идут лесом. Нужно было тут чужой скриптик подменять, так началось, тут пробел, тут табуляция и самое главное что если участок кода не выполняется, то о проблеме и не узнаешь.
Проблемы-то с пробелами возникают только при копипасте с некоторых сайтов. А так, в исхходном тексте, который ASCII, с чего бы им теряться?
>> Python disallows mixing tabs and spaces for indentation.
cat ind.py && python ind.py
def foo():
print(0)
print(1)
print(3)
File "ind.py", line 3
print(1)
^
TabError: inconsistent use of tabs and spaces in indentation
> так началось, тут пробел, тут табуляция
> и самое главное что если участок кода не выполняется, то о проблеме и не узнаешь.... тут - опеннетный балабол.
Не знаю питон, но любопытно - а если в разных рядом лежащих файлах? (в одном всё пробелами, в соседнем скачанном - табами и всё в одном проекте)
Так не ругается. Это и правильно, иначе это сильно усложнит возможность использования сторонних модулей.
for i in range(1, 10): #{ begin block code
...
#} end block code
Так и делаю, кстати. https://mobile.opennet.ru/opennews/art.shtml?num=53987#29
> Любые языки с блоками через пробелы / табуляции идут лесом. Нужно было тут чужой скриптик подменять, так началось, тут пробел, тут табуляция и самое главное что если участок кода не выполняется, то о проблеме и не узнаешь.Это замечательно, на самом деле. Питон таким образом бережёт код от говнокодеров, которые постоянно норовят расставить отступы рандомно так что читать потом сложно.
nim-у 15 лет в обед
Но официально стабильным его вроде объявили только то ли в этом, то ли в прошлом, толи в позапрошлом году.
>> с хорошим синтаксисом.
> Такой себе. У JavaScript и Python гораздо лучшеА при чем тут JavaScript и Python?
Это скриптовые языки, сравнивать с языком никакого уровня несколько странно.
Синтаксис любых языков сравнивать это нормально. Никто не запрещает написать компилятор питона в машинный код, пусть даже если он будет не очень совместим с cpython, в том плане что существующие сложные питоновские программы он собрать не сможет, но на нём можно будет разрабатывать с нуля новое, даже низкоуровневое.
А что с синтаксисом у Яваскрипта не так, он позволяет как писать изящно, так не запрещает прострелись себе мозг.
А я тут причём, синтаксис у JS норм, я об этом.
>не запрещает прострелись себе мозг.Нельзя прострелить то, что у вэб-макаки отсутствует.
> с хорошим синтаксисом.Юморист.
>> с хорошим синтаксисом.
> Юморист.В сравнении с C и C++, разумеется.
Но некоторых фишек и общей строгости не хватает и в других языках.
Неплохо, но утомляет его постоянно компилировать ради полутора в принципе заменимых библиотек. С svg только беда.
В плане, кого компилировать? Раст что ли?
На рабочем компе не нужно компилировать Раст
Какой оптимистичный взгляд на мир
У него просто гента. Он всё компилирует.
А, ну дык, хомячье всегда верин он трму дяде который ему копилит и бинари выдает. Он же дядя надежный.
> А, ну дык, хомячье всегда верин он трму дяде который ему копилит
> и бинари выдает. Он же дядя надежный.Да-да, хомячье всегда верит в исходные коды без проверок, да-да.
Понимаю ещё мейнтейнерам дистров не верить, мало ли что они задумали и какие цели, но, если не веришь авторам используемого языка, то как бы лучше его и не использовать.
Пользуюсь старой версией из принципа. Точнее уже форком старой версии.
А в чем принцип если новая работает лучше старой? Назло кондуктору?
В чём лучше?
Тем что она валится на меньшем количестве тестов чем предыдущая (где-то на треть).
Это является достаточной причиной для большинства пользователей.А любители поконпелять на старом ведре могут как обычно ныть в комментах и страдать, на них всем и так наплевать.
> Тем что она валится на меньшем количестве тестов чем предыдущая (где-то на
> треть).
> Это является достаточной причиной для большинства пользователей.Мне картиночки смотреть надо, а не тестики гонять.
> А любители поконпелять на старом ведре могут как обычно ныть в комментах
> и страдать, на них всем и так наплевать.УМВР.
Зачем его самому собирать? rustup update скачает готовые бинари
Чтобы коммент написать, как минимум.
Вылезай из танка, дистры бывают ещё source based.
Вылезай из пещеры, в source based никто не мешает запускать бинари ,и да , rustup спокойно работает в какой нибудь Генте ,и еомпилять не надо . Вауу
Сразу видно, что ты Gentoo в глаза не видел.
> rustup update скачает готовые бинарилинчевать за это и за make install
Но за make install условно. Если вы предварительно сделали ./configure --prefix=your_path , то ничего страшного с целостностью вашей системы не произойдёт.
> Если вы предварительно сделали ./configure --prefix=your_path , то ничего страшного с целостностью вашей системы не произойдёт.Или make install DESTDIR=/my/fake/root
rustup же ...
Уррра!!!
Жалко, синтаксис не как у Python.
Жалко, но он слишком низкоуровневый. Но сахара со временем скорее всего будет все больше и больше
Примерно как C# только без виртуальной машины
Ты лжешь или не видел ни раста ни C#?
Подход один и тот жеУ C# unsafe работает также само, все что внутри unsafe это неуправляемый дотнетом код
Прикинь, у Модулы-2/3, Оберона, Go -- точно такой же подход. С той лишь разницей, что Модула-2 появилась 36 лет тому назад.
А я с этим не спорю
Для начала, Rust использует LLVM
Что является его недостатком.
> Для начала, Rust использует LLVMА в огороде бузина?
> А в огороде бузина?Может быть.
Но комментарий то относится к упомянутой выше .net машине. То же в отношении JVM. Какой смысл говорить, что Rust без виртуальной машины .net, если он на LLVM-машине?
> Но комментарий то относится к упомянутой выше .net машине. То же в
> отношении JVM. Какой смысл говорить, что Rust без виртуальной машины .net, если он на LLVM-машине?Смысл - в неплохом детектировании опеннетных "Ыкспертов", которые не в кусе "маленькой разницы" между JVM/NET и LLVM, но Ценнейшее Мнение имеют.
А так - никакого, потому что никакой "виртуальноой машиной" а ля JVM/NET там и не пахнет ...
> Смысл - в неплохом детектировании опеннетных "Ыкспертов", но Ценнейшее Мнение имеют.Ну детектировался. Помогло?
>> Смысл - в неплохом детектировании опеннетных "Ыкспертов", но Ценнейшее Мнение имеют.
> Ну детектировался. Помогло?Сказать-то что хотел, Ыкспертус?
> Смысл - в неплохом детектировании опеннетных "Ыкспертов", которые не в кусе "маленькой
> разницы" между JVM/NET и LLVM, но Ценнейшее Мнение имеют.Вот чем плохо молодёжь в форумах - пользы от ваших комментариев почти ноль. На то, чтобы по существу написать ответ, знаний не хватает. Зато самомнение и агрессия.... И сразу переход на личности....
А ты такой не молодой и тооже в нашу кашку взел.
> Вот чем плохо молодёжь в форумах - пользы от ваших комментариев почти
> ноль. На то, чтобы по существу написать ответ, знаний не хватает.
> Зато самомнение и агрессия.... И сразу переход на личности....Вот чем плохи косящие под олдфагов "снежинки" - они совершенно не в курсе, что раньше _продолжающего_, несмотря на намеки, с умным видом нести ахинею - тыкали просто и без экивоков носом. Особенно тех, кто прятался за безликим анонимом.
Еще и считают, что им _базовые_ вещи должны разжевывать и в рот ложить, если уж они соблаговалили влезть в обсуждение.> чтобы по существу написать ответ, знаний не хватает.
Не льсти себе о "знаниях". Если бы ты нормально спросил, а не продолжал упорно писать чешуйню - был бы нормальный ответ.
Ты ведь даже на страницу проекта не ходил, где первым же предложением разъясняется даже для далеких от темы:
> The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
> Despite its name, LLVM has little to do with traditional virtual machines. The name "LLVM" itself is not an acronym; it is the full name of the project.
>
Разница в том что LLVM это Low Level Virtual Machine. Такая же виртуальная машина как и JVM, а сраст так же убог, тормозен и нечитаем как Java.
Все нормальные программисты пишут на ANSI C и только убогие говнокодеры пишут на этих поделках.
Жду когда добавят совсестимсть с языком ждаваскрипт и можно будет фронтендеру писать для процессора, а сишечка станет не нужна
И про Electron'чег не забудьте! Тоже пусть добавят совместимость.
Электрон на процессоре будет выполнятся быстрее, без замедления в виде прослойки из операционной системы гуи будут летать.
>Электрон на процессоре будет выполнятся быстрее, без замедления в виде прослойки из операционной системыИ мелтдауниться будет точнее и производительнее.
Не будь веб-макакой, осиль сишечку.
Сишка лучше этого модного недоязычка
Чем лучше, например?
Качественные UB, красивые segmentation faultы
Что ещё для счастья надо?
> Чем лучше, например?Чем раст.
При этом будет забавно, если он полностью вытеснит сишку
Не, ну это вряд ли.
Существуют тонны легаси (говно)кода который никто не будет переписывать пока он не станет ненужным вообще. В лучшем случае обернут в какую-то обертку, как сейчас виртуализируют проги на коболе.
Алгол вообще тру.
Компилятор увеличился на очередной гигабайт...
Он собирается дольше LibreOffice'а, а им ещё лису собирать
Планирую перейти на "Beyond Linux From Scratch" брат твой коментарий меня глубоко печалит.
Это все скрытая реклама бинарных дистрибутивов, да.
Раньше профит от лисы был в том, что она быстрее хромого собиралась.
Спасибо за руст! Отличный руст!
Отличный хруст
Хруст в коленях или в позвоночнике.
Слышишь хруст?
Это ломаются спины растоманов.
Надо переписать раст на раст.
конпелятор давно на хрусте
Ага канешн, когда LLVM успели переписать с C++ на ржавого?
а при чем тут llvm. его никто в здравом уме не будет переписывать, потому что зачем
Но он же на плохом С++
вентилятор не надо переписывать, нужно на него ещё больше говна набрасывать
Карго культ в действии... прорыва нет но вы держитесь
cargo написан на Go
Маски бесполезны. Особенно на аватарке.
Комментаторы бесполезны. Особенно на опеннете.
https://github.com/rust-lang/cargo> Rust 94.5% Roff 5.0% Other 0.5%
Товарищ жыыырно пошутил, а вы за пруфами полезли.
Без ООП это лучший язык для хэллоуворлдов
Там ещё и goto нет!
Goto нужен в глубоко вложенных циклах, без него что выпрыгнуть из вложенного цикла нужно такой костыль городить
В расте оно есть https://doc.rust-lang.org/rust-by-example/flow_control/loop/...
Такой?int x_max = 50;
int y_max = 50;
int z_max = 50;for (int x = 1; x <= x_max; x++)
{
for (int y = 1; y <= y_max; y++)
{
for (int z = 1; z <= z_max; z++)
{
if (z > 10)
{
x = x_max;
y = z_max;
break;
}printf("%d %d %d\n", x, y, z);
}
}
}
Два верхних цикла с пустым телом? Дастишь фантастишь
> Два верхних цикла с пустым телом? Дастишь фантастишьЭто No Code Design Pattern
https://github.com/kelseyhightower/nocode
Синтетический код
1. Хорошим тоном является не делать вложенность циклов больше 2.
2. throw также умеет выскакивать из любой вложенности.
Ага умеет выскакивать в ядро, фига там контекст переключить, один хрен электрон
throw медленный
В Go, кстати, это решили goto-подобным break-ом.
В расте также есть break на метки.
Мне кажется я теряю веру в Раст. Окружающие говорят что дыры не зависят от языка, а зависят от программиста, который пишет на языке. Пожалуйста скажите что они не правы.
Ищи единомышленников на Stack Overflow.
К сожалению от языка тоже зависят. Вопрос в процентном соотношении этих дыр. и если можно автоматизировать отлов любой части это нужно делать. Статические анализаторы отчасти решают некоторые проблемы(и обязательно должны использоваться), но к сожалению некоторые они пропускают(например мутации итерируемых контейнеров)
А в расте без приседаний получится менять текущий итератор?Скиньте код, пожалуйста?
Нет, компилятор придет и скажет что так нельзя. В расте вообще все сведено чтобы максимальное число потенциальных UB не компилировались. https://play.rust-lang.org/?version=stable&mode=debug&editio... по-началу ошибка может показаться какой-то сумбурной, но немного разобравшись с правилами алиасинга все становится стройно
В C++ если не писать в Си-стиле, юзать ООП ипользоваться STL, можно забыть и про утечки и про сегфолты и макаронный кодНо мамкиным хацкерам это не обьяснишь, они ждут серебрянную пуля из гвна
В этом сообщении как раз вся мякотка. Можно писать. а можно не писать. А на ржавом нельзя не писать. И готовые зависимости что важно тоже так же написаны.
Базаришь? Скажи это unsafe где безопасность раста не работает
Он как раз-таки работает. Просто возникнет ошибка, которая благодаря расту не завалит прогу с Access violation, и прога продолжит работать, ну кроме разве что этого забагованного куска по внешней зависимости.
В unsafe все проверки раста отлючены, это по сути тот же подход что и с unsafe в дотнете
> В unsafe все проверки раста отлючены,Почему ты такой балабол?
https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
> It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety.
>
Дядя Петя ты дурак? Кидаешь мне в ответку на утверждение что в unsafe безопасность is off пруф с прямым указание что Rust в unsafe не обеспечивает безопасность работы с памятью?
>>> (Хан) unsafe где безопасность раста не работает
>>> (Хан) В unsafe все проверки раста отлючены, это по сути тот же подход что и с unsafe в дотнете
>> unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks
> (Хан) Дядя Петя ты дурак? Кидаешь мне в ответку на утверждение что в unsafe безопасность is off пруф с прямым указание что Rust в unsafe не обеспечивает безопасность работы с памятью?А, так ты просто не умеешь в английский? Это многое объясняет
Разыменовывание raw указателей вызываеи ошибок работы с памятью?Null-pointer и Access violation передают тебе пламенный привет
Учитывая что основная часть проблем связанных с Си кодом связана с работой с памятью через указатели, то Rust в unsafe менее безопасен чем C++
В чем смысл безопасности раста если взаимодействие с Си все в unsafe? По сути самый критичный к проблемам код
Ну так это проблема си. Будет меньше си кода - будет меньше ненужных unsafe оберток.
Вызов си функции из любого, даже managed, языка - это потенциальная проблема и "unsafe" в терминах этого языка.
Очевидно, что программа на расте не должна вызывать функции ОС. Ни доступа к файлам и усройствам ввод/вывода, ни к сети и даже не выделять память
> В чем смысл безопасности раста если взаимодействие с Си все в unsafe?"В чем смысл собирать с варнингами и прогонять статический анализ кода на Си, если оно все равно пропускает ошибки?"
В чем смысл этой унылой демагогии?
Дело не в том что можно писать, а можно не писать.
А в том что по факту не пишут! Потому что... да куча отговорок - "медленно", "я так не привык", "и там сойдет"
Конечно неправы! Вы видели хоть одну дыру в коде на расте, например, в ядре линукса?
Или в той же openssl? Или вон в хроме? А в сишном коде - тыщи их!
Нет кода, нет дырей...
Rust помогает программеру писать корректный код. Но это не серебряная пуля. Головой думать всегда надо!
каким таким образом он помогает? если быть точным то так называемая помощь она изза ограничений
А вот если говорить о чистой помощи то это подсказки в IDE.
ну вот, навскидку:
1. модель работы с память в rust такова, что запрещает делать ошибки типа "чтение неинициализированной памяти", "висячие указатели", "утечка памяти (классическая)", "гонка конкуретного доступа к памяти"
2. rust "заставляет" программиста проверять ошибки, возвращаемые функцией (не забудешь, ага)
3. система типов более мощная, чем плюсовая, и, например, через паттерн newtype позволяет не складывать мандарины с выключателями (или метры с километрами, или рубли с копейками)
4. нормальный встроенный в язык механизм макросов позволяет творить чудеса, но ценой сложности реализации (впрочем, скрытой от того кто макрос потом используем). как пример - https://docs.rs/serde и https://docs.rs/inline-python
5. "карго-культ" и современная система модулей (crates) поощряет переиспользование кода (не надо писать велосипеды, бери готовое и пиши то что тебе нужно)
1. если не уверен в своей внимательности используем умные указатели.
2. а как иначе не проверять? ну разве что если человек пишет код в одну строчку.
3. можете кейс привести в каком случае не хватает типов в плюсах? если сравнивать с пхп то да )
4. макросами практический не пользуюсь, поэтому может и да, но макросы эт не ЯП
5. тут слово современный это значит хайпово?
Так в этом и смысл, что лишняя самодеятельность (т.н. свобода) в программировании не нужна
для этого существуют фрэймворки
Как этот ужасный синтаксис может помогать писать корректный код? Он не помогает, а мешает поэтому даже Фаерфокс не смогли запилить на Расте. Даже движек Servo не смогли доделать.И самое забавное раст скомпилированный под продакшен не проверяет выход за пределы буфера. Это какой-то позор.
```rust
fn main() {
let arr = [0_u8;2];
for n in 0..3 {
println!("{}", arr[n]);
}
}
``````sh
Compiling playground v0.0.1 (/playground)
Finished release [optimized] target(s) in 4.27s
Running `target/release/playground`
thread 'main' panicked at 'index out of bounds: the len is 2 but the index is 2', src/main.rs:12:24
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace```
>И самое забавное раст скомпилированный под продакшен не проверяет выход за пределы буфераОчередной ананимный балабол детектед
В примере недостаточно информации, что бы определить выход за границу во время трансляции? Или почему компилятор пропустил, Rust такое не ловит?
На мой взляд информации достаточно.
И если обратиться к массиву с константным индексом, то компилер ловит такое.
такое: arr[3] .А вот циклы, походу, не разворачивает. Причин не знаю. Может руки у разрабов не дошли, а сожет это сильно бьет по скорости компиляции, которая и так нешустрая.
> а сожет это сильно бьет по скорости компиляции, которая и так нешустрая.This.
https://users.rust-lang.org/t/why-index-out-of-bound-is-not-...
Плюс, доступ к элементам конст-массива _таким_ образом - довольно "синтетичен" и мало употребляется в реальности (да и за такие употребления нужно бить по рукам).
Насколько я понял из рекламируемых особенностей языка, задача Rust как раз и состоит в том, что бы заменить специально обученного тютора с линейкой, который бьёт по рукам. В подобном случае (если он не столь прост как данный) ошибка во время исполнения не обязательно будет отловлена тестами.
> Насколько я понял из рекламируемых особенностей языка,Где и кем рекламируемых?
> задача Rust как раз и состоит в том, что бы заменить специально обученного тютора с линейкой,
> который бьёт по рукам. В подобном случае (если он не столь прост как данный) ошибка во время исполнения не обязательно будет отловлена тестами.Задача "не дать писать на любом ЯП как на сишке и с теми же ошибками" (т.е. как тут - игнорировать наличие итераторов и вместо каноничного "for elem in arr" и писать привычный из сишки костыль) - вряд ли выполнима даже с помощью кнута, не то что линейки.
>> Насколько я понял из рекламируемых особенностей языка,
> Где и кем рекламируемых?В частности, здесь.
>> задача Rust как раз и состоит в том, что бы заменить специально обученного тютора с линейкой,
>> который бьёт по рукам. В подобном случае (если он не столь прост как данный) ошибка во время исполнения не обязательно будет отловлена тестами.
> Задача "не дать писать на любом ЯП как на сишке и с
> теми же ошибками" (т.е. как тут - игнорировать наличие итераторов и
> вместо каноничного "for elem in arr" и писать привычный из сишкиЗадача статического анализа вышеприведённого кода решаема, с чем согласен ("На мой взляд информации достаточно") в том числе отвечавший на мой исходный вопрос. Не надо подменять его и приписывать мне заявления про "любой ЯП".
> костыль) - вряд ли выполнима даже с помощью кнута, не то
> что линейки.Значит Rust, где позволено написать "костыль", тем более не годится, я верно понимаю?
>>> Насколько я понял из рекламируемых особенностей языка,
>> Где и кем рекламируемых?
> В частности, здесь.Т.е. внятного ответа не будет.
>> задача Rust как раз и состоит в том, что бы заменить специально обученного тютора с линейкой, который бьёт по рукам
> Задача статического анализа вышеприведённого кода решаема, с чем согласен ("На мой взляд
> информации достаточно") в том числе отвечавший на мой исходный вопрос. Не надо подменять его и приписывать мне заявления про "любой ЯП".Любители "соломенных чучел" возмущаются "подменой тезиса"?
>> костыль) - вряд ли выполнима даже с помощью кнута, не то что линейки.
> Значит Rust, где позволено написать "костыль", тем более не годится, я верно понимаю?Значит наброс от n00by слишком уныл, все верно.
А, ты решил меня потроллить. В общем-то, предсказуемо. Вменяемых растоманов в темах по Rust меньше половины, к сожалению.
программисты мозиллы (не путать с менеджерами!!) ухитрились не только написать на rust движок рендеринга веб-страницы (а это ОЧЕНЬ сложная штука), так ещё и встроить его в C++ код движка gecko, причём "на живую", в продакшене!
Потому что Servo они дописать не смогли в силу ограниченности. Все уже давно знают эту историю. Это всего лишь повод отказаться от Раста везде где это возможно.
к сожалению, у компании мозилла банально нет ресурсов (читай - денег), чтобы разрабатывать servo. для этого надо платить примерно 100 человек (в основном - разработчикам) в течение 3-4 лет, чтобы с нуля разработать движок современного "веб-барузера". и даже "помощи" в разработке со стороны языка rust здесь не хватит, там банально десятки миллионов строк кодазато проект servo дал лисичке stylo и webrender, что тоже очень хорошо
Нет это не так работает. Сначала намеренно выбирать небезопасный по умолчанию инструмент а потом его безопасно использовать - это чтобы ЧСВ потешить? Есть люди которые голой ладонью гвозди забивают, но почему то мастера всегда молоток используют."Верить" в инженерных решениях плохая идея - нужно понимать что вы получаете и чем за это расплачиваетесь, так что хорошо что теряете.
Хороший язык, с С++ конечно же переходить не буду
Ну конечно если ужеж опыта много, то на кой переходить,
а если осточертело все это таскание библиотек с собой (все беру с собой),
то можно попробовать из коробке вкусно и тащит все, но
пока рановато экосистема пока сырая и если не готов сам что-то сделать,
а скорее всего не готов так как опыта нет, то это только изучать и начинать смотреть
Господа, кто в теме глубоко разбирается: объясните чукче почему нужен именно отдельный язык Rust, а не Memory Safe C Compiler?
У си слишком красивый синтаксис
Но у Си фатальный недостаток - он придуман не Грэйдоном Хором.
https://blog.logrocket.com/introducing-the-rust-borrow-checker/
Прочитал, предполагалась реклама, но для меня оказалась антирекламой.Цитата:
"The borrow checker can be tricky to understand and work with — so much so that it’s pretty common for newcomers to the Rust community to get stuck fighting the borrow checker. I’ve personally lost many hours of my life to this struggle."Из этой статьи видно: передача вектора как аргумента в функцию, возможна тремя способами:
1) передачей владения,
2) копией всех данных вектора,
3) по ссылке.Необходимость передачи владения при передаче аргумента в функцию - очень редко возникающая ситуация (в расте она выполняется по-умолчанию, в отличие от С/С++, которые делают копию).
Чаще всего нужно наоборот - вернуть созданный внутри функции объект наружу.
В примере из статьи этот метод не применим, т.к. вектор используется после вызова функции.
Копировать все данные тоже не вариант - не оптимально. Остается только передать по ссылке.Подозреваю, что из-за этих ограничений при передаче объектов, использование ссылок в расте (ради оптимальности естественно) распространилось как эпидемия. И для поддержания порядка в этом "генераторе ссылок" понадобился borrow checker.
Для сравнения: С++ предлагает множество вариантов передачи аргументов, в том числе все аналоги раста.
Какой именно больше подходит в конкретном случае, определяется архитектурой приложения.
И можно сделать так, чтобы беспокоиться о ручном освобождении памяти/объектов не нужно было.
Аналоги раста:
1) передача владения - явное использование std::move(): void f(std::unique_ptr<T> arg); f(std::move(object))
2) копия - void f(std::vector<T> array); f(objectsWithCopy)
2) ссылка - void f(std::vector<T> const& objectsByRef); f(objectsNoCopy)Беспокоиться о ручном освобождении объектов (и появившимся из-за этого невалидных ссылок) не нужно если пользоваться стандартными контейнерами и смарт-пойнтерами.
Еще пример удобного управления временем жизни объектов можно найти в Objective-C: "Autorelease Pool".
Этому механизму уже несколько десятков лет (https://ru.wikipedia.org/wiki/Objective-C#Autorelease-%...).
А набор из нескольких простых правил пользования им вполне сходен с правилами которые налагает раст. Отличие в том, что в Objective-C эти правила должны войти в привычку, но оставляют программисту свободу, а раст просто запрещает всё кроме 3-х перечисленных случаев.
Короче, я вижу, что borrow checker - это не очень нужная мне фича, т.к. я уже научился проектировать управление временем жизни объектов и проблем с этим не возникает. Для тех, кто этому не научился, borrow checker - это ложное обещание того, что компилятор решит эти вопросы за них, а он их не решает. Он налагает ограничения (как по мне, слишком жесткие) на владение и передачу объектов, и пока нубы этому не обучатся, будут выгребать "error[E0382]: borrow of moved value" и "I’ve personally lost many hours of my life to this struggle."
> Необходимость передачи владения при передаче аргумента в функцию - очень редко возникающая ситуация (в расте она выполняется по-умолчанию, в отличие от С/С++, которые делают копию).Во-первых, не так уж и редко. Не надо судить по опыту C/C++, как часто это оказывается полезным: в C/C++ невозможно передать владение. Там это никто не использует не потому, что не нужно, а потому что нельзя.
Во-вторых, копия по-дефолту -- это нарушение принципа "zero-cost abstraction". Передача копии -- это дорого. Не всегда, но очень часто.
В-третьих, дефолты меняются. Вот для тех случаев, когда удобнее передавать копию, перед декларацией типа можно написать #[derive(Copy)], тогда макрос derive напишет для этого типа реализацию трейта Copy (это пустой трейт, там нету методов, т.н. трейт-маркер), а компилятор, видя что тип -- Copy, будет передавать копию, вызывая метод clone для создания этой копии. Например, если ты напишешь
let x: i32 = 2;
foo(x);
println!("{}", x);То это сработает. Компилятор не начнёт ругаться на то, что println! использует x, откуда значение было перемещено в foo. Магия? Не, если ты передашь в функцию i32, то туда будет передана копия значения. И всё потому, что для i32 реализован трейт Copy, то есть, как бы, i32-значение при передаче из одного места в другое автоматически вызывает свой метод clone. То есть, тот вызов foo, как бы заменяется на foo(x.clone()) автоматически.
Но это, понятно, хорошо только для небольших типов. Часто для всяких enum'ов используется. Или для векторов длиной с небольшое целое число, например, длины 4. Ну и понятно, что std делает это для всех примитивных численных типов.
То есть, практически, разница лишь в том, что для объектов, которые дорого копировать, тебе придётся явно вызывать clone(), вместо того, чтобы создавать копию неявно передачей по значению. Для объектов, которые копируются легко и непринуждённо, реализован Copy, и они передаются так же, как они передавались бы в C/C++.
>> Во-первых, не так уж и редко.Приведите примеры когда это нужно.
>> в C/C++ невозможно передать владение
Можно, см. std::move().
>> Передача копии -- это дорого.
Согласен, поэтому в С++ для таких случаев можно передавать (константные) указатели, ссылки или смарт-пойнтеры.
>> В-третьих, дефолты меняются.В С++ тоже можно менять поведение класса при создании копии его объекта. Выполняется это переопределением конструктора копирования (и других методов, там где надо). Если очень нужна эффективность по-дефолту, чаще всего реализуют CopyOnWrite.
>>> Во-первых, не так уж и редко.
> Приведите примеры когда это нужно.Всё что угодно большое ты не будешь передавать "по-значению" без передачи владения, которая позволит избежать копирования. Если владение не передаётся, то компилятор вынужден создавать копию, дабы не было бы двух одновременных ссылок. Пример, может не очень "необходимого", но очень удобного -- это "типы-конструкторы":
let win = WindowBuilder::new()
.size(800, 600)
.title("Хелловорлд")
.build();Тут цепочка вызовов после new. new создаёт объект типа WindowBuilder, этот объект затем передаётся в size, где он модифицируется и возвращается, потом передаётся в title, где он модифицируется и возвращается оттуда, после чего он передаётся в build, который на основании значения типа WindowBuilder строит объект типа Window. Понятно, что при желании можно разорвать цепочку вызовов, сохранить промежуточный результат WindowBuilder в переменной, сделать что-нибудь ещё, потом продолжить. Ноль мутабельности, ноль ссылок. Никому не надо связываться со ссылками, потому что... а нахрена? Паттерн с передачей "по значению" с передачей владения моментально виден в документации. Скажем, вижу я в документации метод хештаблички into_values(self)->/*что-тотам*/, я вижу, что self передаётся по значению, и моментально понимаю, что это _деструктивное_ преобразование хештаблички во что-то там, что судя по имени функции содежит все значения в хеш-табличке. После вызова её у меня не останется на руках исходной хеш-таблички.
Или, допустим, я вижу String::from_utf8(vec: Vec<u8>) -> Result<String, FromUTF8Error>, я моментально знаю, что from_utf8 "съедает" Vec<u8>, и даже не заглядывая в доки и сорцы, я спорить готов, что from_utf8 не выделяет память под новую строку, он повторно использует память Vec<u8>.
Или, скажем, я вижу конструктор BufReader<R>::new(inner: R) -> BufReader<R> where R: Read. Он принимает объект реализующий трейт Read (то есть у объекта есть метод read), употребляет его "насовсем", возвращает BufReader, то есть, в терминах STL/C++ это буферизованный istream. inner был небуферизованным, а BufReader -- буферизованный. Я вижу такое, и я понимаю, что мне не удастся попеременно читать буферизовано или небуферизовано, потому что BufReader хочет владеть низлежащим небуферизованным потоком. Зачем ему это надо, я не уверен навскидку, у меня есть разные предположения, но это другой вопрос.
А ещё у BufReader'а есть метод into_inner(self) -> R, который принимает self "по значению", то есть он употребляется насовсем, и возвращает R по значению, то есть совмещая это с конструктором, мы понимаем, что владением исходным небуферизованным istream'ом можно получить обратно, только BufReader этого не переживёт.
Ни в одном из этих примеров для объектов нет смысла передаваться по-дефолту созданием копии, потому что даже если бы это и было бы возможно, всё равно никто не пользовался бы этой возможностью. Иногда, может быть, в каких-то специальных условиях это имеет смысл, но на тот случай есть clone. А вот передавать владение объектом имеет глубинный смысл, как с точки зрения использования моментально детектируемого паттерна, так и с точки обеспечения безопасности. String сделанный на повторном использовании памяти с Vec появится только тогда, когда Vec прекратит существовать. А это значит, что не будет двух разных указателей на буфер в памяти хранящий char'ы, а значит не случится, например, такого, что один указатель падёт жертвой drop и освободит память, а другой указатель затем будет разадресован.
>>> в C/C++ невозможно передать владение
> Можно, см. std::move().Нну, это костыль. Что-то типа того, но не то. std::move, как бэ, перемещает объект, но хех, что будет если ты сделаешь:
string s = "хеллоувролд";
foo(std::move(s));
std::cout << s << std::endl;Будет UB. Я чесслово не знаю, что произойдёт, в силу всех этих оптимизаций, проводимых llvm и gcc, но при том уровне оптимизации который был в 90-х это бы означало, что s нихрена не переместился и остался доступен здесь.
Запрет на такие штуки на уровне ошибок компиляции очень важен, это гарантия того, что как в декларациях API написано его использовать, именно так его и будут использовать. Такие штуки могут приводить к нелокальным багам, после которых бывает очень сложно найти виноватого в рантайм-ошибке. А это значит, что от писателя вызывающего кода надо ждать очень точного понимания тех API, которые он дёргает. А это значит, что а) C++ программисты не любят внешние API, потому что их надо скрупулёзно изучать, прежде чем использовать, проще навелосипедить своё; б) писатели внешних API вынуждены думать, как бы так не разложить граблей, которые сложно заметить.
>>> В-третьих, дефолты меняются.
> В С++ тоже можно менять поведение класса при создании копии его объекта.
> Выполняется это переопределением конструктора копирования (и других методов, там где надо).
> Если очень нужна эффективность по-дефолту, чаще всего реализуют CopyOnWrite.Когда я последний раз щупал эти конструкторы, они сделаны таким образом, что на них невозможно реализовывать некоторые паттерны безопасно. То есть, ты делаешь что-то эдакое, но чтобы оно работало, надо чтобы вызывающий код понимал как и что надо делать, чтобы не наступить на грабли. А это значит, что внутри реализации класса нет уверенности в том, на что можно положиться. Можно ли положиться, что вот этот вот inner istream внутри BufReader -- это владение BufReader? Когда выполняется BufReader::drop, следует ли вызвать drop на inner? Если inner принадлежит BufReader'у, то да, это _необходимо_, потому что иначе объект inner просто "утечёт": либо останется потерянный открытый файловый дескриптор, либо потерянный выделенный кусок кучи, либо и то и другое, и может быть ещё что-то третье. Если же вызывающий код сохранил у себя ссылку на inner, то такой drop приведёт к последующему use-after-free в вызывающем коде. Ну или если inner -- это просто файловый дескриптор, то вызывающий код либо столкнётся с внезапно ставшим невалидным файловым дескриптором, или, что хуже, будет читать из нового файлового дескриптора, который был открыт между drop и попыткой чтения и занял то же значение, что и дропнутый файловый дескриптор. А такое уже вообще хрен отладишь, потому что такая ошибка может вылезать в коде, который вообще никак логически не связан ни с данным инстансом BufReader'а, ни с кодом работающим с BufReader'ом. В смысле, глядя на место возникновения ошибки можно математически доказать, что там всё правильно написано и без ошибок, и это даже будет так, но ошибка всё равно будет возникать, и где тот код, который нacpaл? Как его найти теперь?
>> Всё что угодно большое ты не будешь передавать "по-значению" без передачи владения, которая позволит избежать копирования. Если владение не передаётся, то компилятор вынужден создавать копию, дабы не было бы двух одновременных ссылок.По значению передавать не буду, буду передавать другими способами, но передавать владение при этом вовсе не обязательно. Передача владения по-умолчанию приводит к борьбе программиста с борроу-чекером.
А где сказано, что компилятору (даже расту) нельзя создать несколько "одновременных ссылок"? В С++ такого ограничения вообще нет.>> WindowBuilder
Да, для этого примера, передача владения работает как некая оптимизация, но это не единственный метод который позволяет избежать копирования в таком паттерне. В часности, компилятор С++ может выполнять технику "избежания копирования": https://en.wikipedia.org/wiki/Copy_elision#Return_value_opti...
>> String::from_utf8(vec: Vec<u8>) -> Result<String, FromUTF8Error>
Тут описан очень частный случай. Тк. если создается уникод-строка, то чаще всего под неё понадобится больше памяти чем есть у "vec" и выделять новый блок памяти всё-равно придется.
Если же String остается в UTF8 представлении, то эта функция - просто преобразование типов, которая скомпилируется в no-op. С точки зрения оптимизации, передача владения тут - сомнительная необходимость.>> что будет если ты сделаешь:
>> string s = "хеллоувролд";
>> foo(std::move(s));
>> std::cout << s << std::endl;Ничего "такого" не будет, cout "напечатает" пустую строку.
>> C++ программисты не любят внешние API
Откуда такая уверенность?
>> проще навелосипедить своё;
Это зависит от конкретной ситуации, бывает что проще своё написать.
>> надо чтобы вызывающий код понимал как и что надо делать, чтобы не наступить на грабли.
Да, надо. Читайте документацию (и документируйте свой АПИ).
>>> WindowBuilder
> Да, для этого примера, передача владения работает как некая оптимизация,Нет, это работает как паттерн, который виден в документации к WindowBuilder прямо сразу. Ты видишь и знаешь, как это использовать. Тебе не надо два часа читать документацию, чтобы понять.
>>> String::from_utf8(vec: Vec<u8>) -> Result<String, FromUTF8Error>
> Тут описан очень частный случай.Постоянный. Я тебе привёл ещё один пример ровно того же самого -- BufReader. Такие "преобразования типов" типичны. В качестве ещё одного примера: drain итераторы, например, создаются именно так, и позволяют тебе деструктивно вынимать из контейнера один элемент за другим вплоть до исчерпания контейнера.
В std есть стандартные трейты Into и From, которые забирают один объект насовсем, и возвращают другой. И трейты эти используются на регулярной основе. Скажем, если я вызвал функцию, получил ошибку, и хочу завершить функцию с ошибкой, то в некоторых случаях я буду возвращать err.into() -- компилятор сам подберёт нужную реализацию трейта Into, которая преобразует ошибку полученного типа, в ошибку возвращаемого типа.
Хотя, если точнее, Into и From не обязательно забирают объект насовсем -- это зависит от того, реализует ли тип объекта трейт Copy. Как правило они не реализуют, потому что копировать налево и направо неявным образом -- зашквар.
> Тк. если создается уникод-строка, то чаще всего
> под неё понадобится больше памяти чем есть у "vec" и выделять
> новый блок памяти всё-равно придется.Нет. Это в C/C++ придётся выделять из-за нуля-терминатора, который постоянно мешает работать со строками, там без своей реализации строк вообще невозможно жить. В rust'е же не придётся ничего выделять, потому что нет никаких терминаторов. String отличается от Vec только тем, что String гарантирует валидность utf8, обеспечивает некоторые операции, специфичные для utf8 строк, не обеспечивает некоторые операции Vec, которые не очень работают с utf8 строками.
> Если же String остается в UTF8 представлении, то эта функция - просто
> преобразование типов, которая скомпилируется в no-op.Нет, это не noop. Result видишь? Происходит проверка валидности utf8, потому что String гарантирует, что если String-объект существует, то он содержит валидный utf8. Кроме того, String и Vec, хоть и являются оба умными указателями на один и тот же буфер, и оба сводятся к трём полям -- buf, size, len, -- но они _разные_ умные указатели, там может быть другое расположение полей в структуре, например. String::from_utf8, я полагаю, делает Vec::into_raw_parts(self) с возвращаемым значением по типу (usize, usize, *u8) /* обрати внимание, опять тот же паттерн, Vec уходит в into_raw_parts насовсем и безвозвратно */, а потом создаёт из этих raw-parts новый объект String. Если случится чудо, и новый объект String будет бинарно идентичен старому объекту Vec, то перетасовка полей превратится в noop. Если нет, то значит это не будет noop'ом.
>>> что будет если ты сделаешь:
>>> string s = "хеллоувролд";
>>> foo(std::move(s));
>>> std::cout << s << std::endl;
> Ничего "такого" не будет, cout "напечатает" пустую строку.А, да точно. Я увидел на cppreference в примере упоминание UB, но при внимательном изучении там оказывается, что UB возникает не из-за неопределённого состояния s, а из-за того, что s.back() при том состоянии -- это UB. (Не, ты прикинь, ты вызываешь внешний API, и он тебе выкидывает не ошибку, не исключение, но UB. Ипануцца!) Но это значит, что foo(std::move(s)) -- это вызов конструктора std::string для создания пустой строки в s? Нахрена? Не, я понимаю, что в данном случае компилятор отоптимизирует и выкинет ненужный вызов (хотя не, не выкинет, s ведь используется в operator<<). Но в каких-то других случаях, этот конструктор может иметь side-эффекты, он может быть тормозным, он может не инлайниться, и мы не будем использовать s после вызова foo, но компилятор не сможет доказать, что выкидывание этого вызова -- это законная оптимизация, а не саботаж задумки программиста. Мы получаем абстракцию, которая нихрена не zero-cost.
>>> C++ программисты не любят внешние API
> Откуда такая уверенность?Сравни использование внешних зависимостей в rust'е с таковым в C++. Как давно тебе приходилось тянуть в свой проект зависимостью специфическую реализацию хештаблички, которая долго создаётся, не умеет добавлять элементы после создания, зато выделяет памяти ровно столько сколько нужно (а не на 20-50% больше) и гарантирует отсутствие коллизий? Или пакет для работы со временем, который умеет всё, что нужно тебе, а не только то, что в прошлом веке сочли нужным те, кто писал стандарт для стандартной библиотеки? Или пакет для url-encode/url-decode? Пакет для парсинга markdown? Реализацию sha512? Base64? Пакет для форматирования размера в понятном человеку виде -- в смысле чтобы не "310438330", а "297M". Все эти вещи в C и C++ принято велосипедить. В C++ может чуть меньше, но всё равно велосипедить. Опеннет полагает это признаком квалификации программиста и способом избежать dependency hell'а, что может быть и так, но это также приводит к появлению тысяч полусырых велосипедов. Зато мейнтейнерам дистров жить проще.
>>> проще навелосипедить своё;
> Это зависит от конкретной ситуации, бывает что проще своё написать.В расте крайне редко это проще. Если нет, того что надо, то скорее всего есть почти то, что надо, а это значит, что проще туда пулл-реквест закинуть, который доведёт "почти то что надо" до уровня "то что надо". И это проще, в частности, потому что даже внутренние, возможно недокументированные, API пакета довольно прозрачны, очень легко работать с чужим кодом. Ты видишь #[derive(Copy,Clone)] ты знаешь всё что тебе нужно знать о реакции объекта на присваивание его куда-то, тебе не надо выискивать код трёх-четырёх конструкторов и продираться через него, чтобы понять, что, собственно, имелось в виду. Ты смотришь в код, и понимаешь задумку автора этого кода.
>>> надо чтобы вызывающий код понимал как и что надо делать, чтобы не наступить на грабли.
> Да, надо. Читайте документацию (и документируйте свой АПИ).Это не всегда работает. Попробуй продраться через документацию, скажем, к ffmpeg, понять когда безопасно вызывать free на буфер, который ты передавал в недра ffmpeg, когда не стоит этого делать, а когда ни-ни-ни-низзя этого делать совсем. В расте полезно проконсультироваться на этот счёт с документацией, но там такие вопросы _прозрачны_, и, кроме того, если ты где-то что-то поймёшь неверно (потому что документация кривая, или потому что ты читал невнимательно), то тебе компилятор потом об этом сообщит, выкинув ошибку компиляции. Лучшая документация на код -- это сам код. Документация может отстать от изменений кода, или не отстать, а измениться вместе с версией библиотеки, но твой код так и останется написанным по старой версии документации.
> Я понял - вы нашли своё растаманское счастье. Я не намерен
> вас его лишать.Ох, как резко с обсуждения по существу на личности. Ничто не предвещало, и вдруг БАБАХ.
>C/C++Товарищ майор такого языка не существует.
>>C/C++
> Товарищ майор такого языка не существует.Мне начхать.
Это как если бы у бабки был эцсамое.. Раст позволяет на писать код для очищения памяти(он его генерирует за программиста, причем можно явно понять в каком месте будет освобождена любая переменная и гарантирует что не будет утечек и doublefree, по крайней мере в unsafe-коде. Так же компилятор гарантирует что все ссылки всегда ссылаются на живые объекты и в расте в принципе не возможны null-pointer-exception'ы). Си можно было бы исправить, но из-за обратной совместимости это уже не будет си. С плюсами собсна то же самое.
чем вам умные указатели не угодили? ну если быть внимательным не вариант
После раста что будет? зменить мозк на чип? ну как же, мозг он то боится то отвлекается, то и меет свою точку зрения, что не безопасно.
А где в чистом Си умные указатели? Стороннюю либу для этого тащить? Или свой велосипед писать?Внимательнее быть не вариант - такая уж багонутая прошивка у homo sapiens. Особенно на больших и запутанных проектах. Периодически невнимательные все вплоть до kernelописателей, а потом cve с получением рута исправляют.
> А где в чистом Си умные указатели? Стороннюю либу для этого тащить?
> Или свой велосипед писать?
> Внимательнее быть не вариант - такая уж багонутая прошивка у homo sapiens.
> Особенно на больших и запутанных проектах. Периодически невнимательные все вплоть до
> kernelописателей, а потом cve с получением рута исправляют.в си не приходилось использовать умные указатели не сторонние (если таковые имеются) не реализовывать свой. В с++ пользуюсь QTшными, но и свой создать дело получаса, а после моно пользоваться. Если мне нужен стиль си то просто его использую и без умных указателей потому что о боже, не может быть , я с другой планеты, для меня в полне нормально внимательно создавать переменные указатели, освобождать память и обращатся к ней. Вы пытаетесь проблему идиота повесить на плечи нормальных людей. Если бы растоманы и прочие хайповые любители говорилибы так что вот вам новй язык который разработан для невнимательных программистов то все было бы логично, но когда читаешь про то что всякого рода клоуны теперь могут ликовать что все больше и больше не нужно думать своей головой а ЯП сам все за вас сделат. блин , да это быдло новость, и прививать эту было идею моветон среди порядочных людей.
+
Ага, появился ДВС - кучеры и конюхи сразу напряглись.
> Ага, появился ДВС - кучеры и конюхи сразу напряглись.появление ДВС является прогресс, а вот появление телевизора является деградацией.
конечно смотря сколлько времени уделять и тому и тому, и какие цели при использовании. а то для того кто на тачке катается по городу и шлюх по дорогам снимает, то таким двигатель это не про прогресс.двигатель и колесо - для вас ходить не нужно и педали крутить
телевизор - путишевствовать не нужно
раст - думать не нужночто вам еще не хватает для полного счастья?
Если так рассуждать, то и другие проверки на уровне компиляции не нужны - нужно быть просто внимательным.Были времена, когда это всё нужно было делать вручную. Теперь хороший язык тот, который позволяет сосредоточиться на конкретной задаче, а не думать постоянно об единицах с нулями.
"знать и учитывать" != "думать постоянно".
вы из крайности в крайности бросаетесь.
еще раз для тупоголового быдла ) если инструмен позволяет только упростить процесс создания чего либо - это хорошо.
если инструмент в чем то упрощает труд но в чем то ограничивает (пример водолазный скафандр для охотника, да мошкара не кусает, но передвигаться становится не удобно) а так же если инструмент в последствии становится частью продукта - это не очень хорошо.надеюсь понятно объяснил.
> А где в чистом Си умные указатели? Стороннюю либу для этого тащить?
> Или свой велосипед писать?
> Внимательнее быть не вариант - такая уж багонутая прошивка у homo sapiens.
> Особенно на больших и запутанных проектах. Периодически невнимательные все вплоть до
> kernelописателей, а потом cve с получением рута исправляют.и потом, вам для лэндинг-пэйджей зачем? вы вообще хоть чтото на с++ писали? )
Уже писал уже как-то:
Мемори-сейф-си требует квалификации программиста гораздо выше средней.Нет, программа будет работать быстро и круто, но у нас тут как бэ капитализм, тут сверху стучат сотня "нужных" этому программисту т.н. "управленцев" и "менеджеров", не говоря уже про владельца сией шараги.
Вот тут и происходит конфликт интересов: прогер, могущий быстро и качественно писать на си, просит не просто много денег, но и серьёзные нематериальные и неденежные бенефиты, без которых - вся эта менеджерская мразота горько рыдает из-за отмененных рабства и крепостного права - он может просто тупо встать и тупо уйти в другую контору. Или даже работать на себя. Или присосаться к госкормушке. Или создать свою контору, СБиШ. Неважно. Так вот, мразота плачет и думает, как удешевить разработку и при этом уменьшить вероятность ухода человека.
Так вот, хрустик это всего лишь попытка максимально убыстрить и удешевить разработку того софта, что просто так в браузер не сунешь, для контингента, знакомого лишь с "программированием" на js, подкатыванием штанишек и разговорам через губу при реальном отсутствии даже намека на высшую нервную деятельность. Корпам нужно дешевое айтишное пушечное мясо, которое можно пасти не как умнейших людей поколения, а как обычных продавашек и впаривателей. Корпам нужен легко заменяемый, дешевый и достаточно запуганный т.н. "культурой отмены" офисный скот.
Все остальные аргумента хрустеров стоит рассматривать только в этом контектсе.
<\Нодискасс>
Твоя теория не подтверждается: школьники и дебилы, обозлённые сложностью вхождения в Rust, плюются говном в сторону его синтаксиса и концепций, которые осилить у них не получается.
Сириус? И именно поэтому т.н. корпы так радостно наяривают на сиё творение? Рассказывают про то, что большинство ошибок в их корпо-коде связаны с работой с памятью и как они хотят побыстрее внедрить Раст?Судя по вашему комментарию, если у школотронов и есть мнение про Раст, то оно фанатично-одобряющее. А своеобразный синтаксис только добавляет налёта илитарнасти. Они это любят.
Корпы наяривают на Go, JavaScript, Java. Rust лишь очень узкую нишу у них занимает.
>но у нас тут как бэ капитализмбла-бла-бла, капитализьм польоха, угнетение, привилегии белых. Тху!
А покажи ка пару хороших языков порожденных вне капитализма ?!
И еще напомню, угнетенной снежинке, что С родился внутри бессердечной капиталистической корпорации AT&T.
И призван он был быстрее клепать код (по сравнению с кучей ассемблеров).>Вот тут и происходит конфликт интересов: прогер, могущий быстро и качественно писать на си, просит не просто много денег, но и серьёзные нематериальные и неденежные бенефиты, без которых - вся эта менеджерская мразота горько рыдает из-за отмененных рабства и крепостного права - он может просто тупо встать и тупо уйти в другую контору. Или даже работать на себя. Или присосаться к госкормушке. Или создать свою контору, СБиШ. Неважно. Так вот, мразота плачет и думает, как удешевить разработку и при этом уменьшить вероятность ухода человека.
Вот тут в своем опусе меняй раст на С, а С на ассемблер и наслаждайся.
>А покажи ка пару хороших языков порожденных вне капитализма ?!Рефал, ДССП.
если Рефал еще как-то похож на ЯП, то ДССП - это вообще какоето академическое убожество, которое морально устарело уже на момент создания.
Писал на ДССП в конце 80х. Оно какое угодно, только не "академическое". На практике это просто более удобный форт, чем форт. А на настоящий фортанутый форт мне мозги вывернуть так и не удалось. Неудобно всё: базовый набор слов для манипуляций стеком, вывернутый flow control, налепленные зачем-то сверху фичи времени компиляции (это в лиспе они уместны, но когда ты байтики экономишь -- нафига тебе ещё и мета?!). Для машинки с десятками килобайт памяти -- самое оно.
ДССП - Для Служебного Системного Программирования
Гоподи какой унылый совок.
Ну ведь соврамши товарищ, а вы повелись! Не так оно расшифровывается!
Проблема в том что погромисты даже с супер квалификацией не умеют в мемори-сейф-си. Раз в год, но и они стреляют себе в ногу. Есть только те кто рассказывает что "все вокруг рукожопы, а вот у меня ничего не падает".
И это прекрасно видно по спискам CVE в ядре линукса и популярных либах.А потом это заканчивается необходимостью накатить патчи на миллионы серверов, взломы, утечки пользовательских или что еще хуже бизнес данных, короче сплошные финансовые и репутационные потери. И именно это корпам и не нравится. Потому что когда из-за работы квалифицированного программера у тебя на миллиарде необновляемых устройств Heartbleed или локальный юзерь может получить рут на твоем серваке, то с этим нужно что-то делать.
А знаешь, почему нет такого количества CVE в проетах на Расте? Очевидно, потому, что его используют полтора землекопа. И если он распространится, то будет то же самое. Или накатывать патчи на бгоугодный растософт - это будет совсем другое?
Нет, тоже самого не будет. Во всех проектах есть логические ошибки - и в с, и в раст - недавняя проблема с парсингом ip4 в растовой stdlib прекрасный пример. И от них не спасешься (кроме возможно формальной верификации, но это стоит кучу денег).
Но такого количества безумных проблем с памятью в расте не будет by design.
И вот сходу началось виляние.
Так это хорошо - хаос, бурления и срывы покровов! И пусть обновляют своё проприетарное почаще. )
Говорите так, будто можно что-то написать один раз и навсегда (* таки, на теоретическом уровне, можно было и это уже сделали Дейкстра с Кнутом, например), но по факту всё равно будут раз в полгода обновляться стандарты, протоколы и чужие софты, так что, сидеть без обновлений всё равно не уастся.
Попробуй хоть раз в жизни собрать что-нибудь стороннее из сорцов на C/C++. Вопросы отпадут сами.
Собаки лают, караван идёт. Красивый язык, успехов команде.
Разрабы D так же считают
Разрабы D хоть не призывают переписать ВСЁ
В Rust тоже не призывает никто, а призывают люди понимающие преимущество,
но я чет не очень понял там почти все под капотом уходит корнями в дырявый
рантайм, так что непонятно ну да верхушка такая вся надежная, а под капотом
все такое багованное, а своб систему они сделали ради привлечения внимания.
"Автоматическое управление памятью в Rust избавляет разработчика от ошибок при манипулировании указателями и защищает от проблем" - это чепуха для молодых дурачков. Если уж совсем программист не внимательный или да проект очень большой в котором сплош и рядом указатели, то можно использовать умные указатели либо уже готовые, либо написать свой класс что весьма не сложно. Считаю что многократное упоминание в новостях о том что раст чтото там решает, является не более чем рекламным трюком, расчитанным на слабых людей.
Когда вам компилятор даёт хоть минимальную гарантию хоть чего-то - надо брать.Ошибки очень дорого чинить, особенно когда ваш код раскатывают на десятки окружений. Вы тратите часы (годы) на отладку, тратите время и нервы девопсов, менеджеров, клиентов, которые с горящей жопoй бегают по офису.
Я как представлю, что из-за многопоточки у кого-то недосчитали три копейки - меня аж в дрожь бросает.
Посмотрите сообщение про итератор ниже
И что ты такого развернул на десять окружений на расте. Ты даже хеллоуворлд на расте еще не написал, а уже лезешь рассуждать про мифические ошибки. Ты отладку ни секунды пока еще не потратил.
это не так
Очень обоснованный ответ. Регулярно вас вижу в комментариях и никогда не понимал вашей позиции - "нет, это ограничения, не надо компилятор делать ограничивающим". Надо. Самодеятельность в программировании не нужна, нужно решение задачи. Поэтому потенциально опасные методики запрещаем.Прогать на не-Тьюринг полном языке, кстати, мб весьма хорошая идея, в ФП-кругах во всю обсуждают. Там не-ТП языки с доказательством тотальности от компилятора. Жаль только пока многое из этого весьма лабораторно выглядит
вы в корне не понимаете суть. или не хотите понимать
если требуется "ограничит" сотрудника в команде разработки - используем фрэймворк (про любой язык)
если ноги вечно обстреленные - используем умные указатели (если говорим о недостатках си)вопрос в том , для чего нужно отказываться от жизни и тратить время на изучение нового ЯП, что бы плучить в итоге что? какая неоспоримая выгода от большенства хайповых языков которые продвигают как на замену старым?
Вот говорят что с++ это старый древний язык и что его нужно закопать. а позвольте, если все даже ваши новые яп написаны на плюсах. давайте напишем к примеру раст на питоне, как вам такое? Тольо не говорите в компании питонистов что в итоге получится тормознутое г..но, вас закидают неприличной сбстанцией.
хайповых языков очень много и давно, и вот скажите мне , что такого удивительного написанно на гламурных языка , чего не написать на с++ , на этом старом ненужном языке? в чем профит? При этом весь интерент говорит что нужно закопать, что старье. Вас такое вранье не напрягает, вы вообще как к вранью относитесь?
есть специализированные языки, пхп, перл, js прижился на фронте, и много других которые и правду упращают труд в рамках конкретных областях.
Но когда начинают врать недоговаривать в угоду замены, пропихывать пропиаривать свое. Ну вот вам и ответ в чем мы разные, для вас лож это норма получается так. А меня такое положение не устраивает и по итогу я выгляжу как белая ворона. Понятно что здесь собрались в основном люди с ускоспециализированным сознанием.
Хруст, он и в Африке хруст
А Rust -- он и в Африке Rust, да. Кто про что...
Про хруст ржавчины.
Простой вопрос, без троллинга.
Когда уже хрустики наконец начнут писать нормальный софт? Не полуавтоматом переписанные сишные утилиты, доказавшие надежность еще с 80х, не обертки над хттп или столбики для пинга, а нормальный софт для людей. Не копроративный, а нормальный.
Я слышал есть несколько крупных проектов. Из тех, что видел/изучал исходники сам - OpenEthereum (бывший Parity client) https://github.com/openethereum/openethereum.P.S.
Не сторонник Раста, мне больше Го/Better-C (https://dlang.org/spec/betterc.html)/чистый С заходит.
из того что сразу сходу вспоминается - vaultwarden или alacritty. из коммерческого - в новом 1password бэкенд на расте.
Операционка на 100500 loc? Такое просто не реально написать за настолько малый срок.
Но меньшие по размеру есть и вполне успешно используется. Servo, Firecracker, Rocket.
Плюс еще то что не открыто https://www.rust-lang.org/production/users.> Не копроративный, а нормальный.
Ну расскажи мне какой нормальный софт ты написал хотя бы за год))
А вообще интересно было бы сравнить сколько софта на с/с++ пишется "копроративного", а сколько "нормального". Боюсь ситуация будет еще хуже.
> Ну расскажи мне какой нормальный софт ты написал хотя бы за год))вас просили показать, а вы сразу кидать стрелки. Ржавые как всегда в своем репертуаре.
Ты так туп что не смог осознать предыдущие 3 строки? Там есть пример трех больших открытых и ссылка на десятки закрытых, которые просто лень копипастить.
Хватит ныть, переходи на Rust, пока не поздно. Поезд еще не ушел, есть вариант (для тебя) что-то достойное написать и запрыгнуть в последний вагон. Но это вечно длиться не будет, время уходит. Иначе - так и останешься у своего "разбитого корыта" и будешь что-то там брюзжать в оправдание самому себе.
Т.е. ты делишься инсайдом что Раст закрывают и надо скорее писать на нём? Хорошо что предпупредил можно даже не начинать пользоваться этим языком недоразумением.
Ну вы же не используете саблю для рубки дров, например? Rust как та сабля. Повесить на стенку и любоваться. Не для реальных вещей нужен топор, хоть щепки и летят, зато все быстро в топку... т.е. в продакшн :)
>зато все быстро в топку... т.е. в продакшн :)вот PHP кодерок и спалился ...
https://github.com/topics/rust вот изучайте
кажется мне что в целом "нормального" софта всё меньше и меньше, просто из-за того что всё идёт в веб и электрон пророк его. Написали, например, alacritty (эмулятор терминала), так этих эмуляторов как грязи, врядли закрыли важную проблему этим продуктом. Разве что для самообразования. Может кто-то и плеер напишет еще один, с такой же целью.
Идейки-то неплохие у языка
Идейки не плохие (хотя и ничего принципиально нового).
Но вот реализация откровенный шлак.
> Идейки не плохие (хотя и ничего принципиально нового).И это неновое было раскидано по нескольким экспериментальным языкам, которые не взлетели. Надо полагать, что реализация там была ещё шлачнее. Лучшее враг хорошего, в общем. Если ждать идеального языка можно никогда не дождаться.
Что конкретно там "шлак"? И как нужно сделать, чтобы было не "шлак"?
Ах, ну да, делать вообще ничего не надо: выбирайте породистых жеребцов, нанимайте хороших конюхов, умеющих правильно выгребать навоз, а автомобиль - это от лукавого.
>реализация откровенный шлак.И это говорит чудик на аватарке которого и то, и другое - шлак.
>> Автоматическое управление памятью в Rust избавляет разработчика от ошибок при манипулировании указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п.Они повторяют это, словно мантру. Из раза в раз. Что, вот прямо "избавляет и защищает"? Без исключений? Может чуть поумерить категоричность формулировок? Или для того, чтоб этот ваш Раст работал необходимо повторение мантр?
Кто "они"? Те кто пишет посты на Opennet про Rust и каждый раз копипастят 3 параграфа называя это новостью? Они к авторам языка отношения не имеют.
Язык написан на c++. Вместо компилятора, llvm-приблуда. Ориентирован на студентов, ими же и продвигается. Имхо не взлетит.
Гугл, Майкрософт, Амазон уже используют язык. Они же, кстати, язык и продвигают. Все, кто этот факт игнорирует, похожи на страуса, прячущего голову в песок при приближении опасности.
Они просто остатки команды наняли для своих нужд, лол. До раста им дела никакого нет. А ты продолжай распространять это бред.Еще скажи что у дропбокса бекенд на раста. Хотя на самом деле у дропбокса бекенд на Go. И на срасте пара ненужных тулзовин в корпоративном гитхабе.
>Они просто ... А ты продолжай распространять это бред.Корпорации? Просто? Бредишь тут какраз то ты.
О да они же КОРПАРАЦИИ они не могут ошибаться. Там же боги работают, которые только и ждут как бы за свой счет создавать ненужно язычек. Зачем им доделывать то что не смогла Мозилла?
Разжую для неострых форумчан свою мысль.Корпорации могут ошибаться и ошибаються. Но вот чего они точно не делают - это "просто", без причины кому-то раздают бабло. Если корпорация кому-то платит, то она однозначно расчитывает получить больше бабла (сократить издержки) в будующем.
> Они просто остатки команды наняли для своих нуждИ что это за нужды такие? В туалет ходить? Что-то дороговато для таких нужд.
> Гугл, Майкрософт, Амазон уже используют язык.Используют для привлечения студентов на рабочие места. И всё это под флагом прогресса технологий.
Такие времена. Им важно показать, что они поддеривают Diversity & Inclusion. А то могут и из насдака выгнать.
Точно, 3 опсоса юзают, значит миллионы мух не ошибаются.
> Язык написан на c++.https://www.openhub.net/p/rust-lang/
> Languages
> Rust 98%
> Other 2%Ыксперт ...
Make sure you have installed the dependencies:g++ 5.1 or later or clang++ 3.5 or later
> Make sure you have installed the dependencies:
> g++ 5.1 or later or clang++ 3.5 or laterВ комментах опеннета опять стратровал чемпионат по самому унылому и тупому набросу?
https://gcc.gnu.org/install/prerequisites.html
> Perl version between 5.6.1 and 5.6.24
Теперь смотри пререквизиты llvm и на чём он написан.
> Теперь смотри пререквизиты llvm и на чём он написан.https://llvm.org/docs/GettingStarted.html#software
> GCC >=5.1.0 C/C++ compiler1
> python >=3.6 Automated test suite2По твоей "логике" - очевидно что на перле с питоном.
> По твоей "логике" - очевидно что на перле с питоном.Лучше уж на питоне чем на с++.
Ты его не переспоришь, ведь он не простой акробат, а умственный.
На деле rust последнее время не радует обновлениями, сплошное шлифование напильником, никаких тебе новых блестящих фичей. Самое интересное теперь происходит в крейтах: https://static.stillinbeta.com/cold-iron/cold_iron/
Если у языка есть интересные фичи (и тем более продолжают появляться) -- это плохой язык.
Это означает, что язык не был спроектирован (имеет идеологию). Этот язык был сочинён (т.е. этот язык -- кустарщина).
>Если у языка есть интересные фичи (и тем более продолжают появляться) -- это плохой язык.Под твои критерии "хорошего" языка попал только Brainfuck. Пользуеш его в проде?
>Под твои критерии "хорошего" языка попал только BrainfuckЕщё Python
>Ещё Pythonразве что python2. он недавно стал хорошим :)
> Если у языка есть интересные фичи (и тем более продолжают появляться) -- это плохой язык.Не. Интересные фичи, значит потенциально полезные фичи. Неинтересные фичи, значит бесполезные фичи. Наличие интересных фичей необходимо, чтобы язык был бы полезным. Полезность, в свою очередь, необходима для языка, чтобы называться хорошим.
> язык не был
> язык былКакое мне дело до того, чем там язык был или не был в прошлом, когда у меня есть язык в настоящем, который является тем, чем является сейчас?
идеи закончились
началась стагнация
Мозилла разогнала разработчиков языка, им теперь ненужно отчитываться перед менеджерами.
Все с Rust ок. Сейчас они сосредоточены над Edition 2021
Так даже там вроде ничего особо интересного (ожидаемого).
Растофанатики ликуют. Интересно, когда изменят лицензию и переделают язык из зонда в свободный?!
Про что речь?
Сделать компилятор автономным, неоснованным на LLVM. Лицензию сменить на MPLv2, хотя бы (уж коль в Мозилле родился). Т.о., отмежеваться от Ябблокопрорашки и их шакалов.
Хорошим признаком признания языка, признание его огромных плюсов по сравнению с C будет переписывание (полное, частичное) на него значимых проектов.Пока ни OpenSSl, ни Nginx, ни Apache Web Server, ни PostgreSQL, ни Gnome, systemd, ни еще 100500 значимых проектов не заикаются об этом.
>Пока ни ... systemd, ни еще 100500 значимых проектов не заикаются об этом.Подскажите кто-либо это Лёньке. Время настало!
PS А мы подождём ;)
>признание его огромных плюсов по сравнению с C будет переписывание (полное, частичное) на него значимых проектов.Это полохо. Как правило, вещи переписанные на Расте идут с пермиссивной лицензией. На сишке пишут. как правило с копилефтной лицензией. И это не удивительно. До появлния, LLVM единственным бурно развивающимся бекендом был GCC.
На Си пишут с любой лицензией. И да - пермиссив свободнее копилефта, пермиссив - будущее
>На Си пишут с любой лицензией.Основной компилятор у сишников - это GCC. со всеми вытекающими, "нутыпонел".
>И да - пермиссив свободнее копилефта, пермиссив - будущее
Ага, влажные мечты. Единственная в мире сила противостоящая проприетарщине это копилефт. Разрешительные лицензии очень удобны проприетарщикам.
FSF и GNU не хейтят Раст. Они лишь видят опасную тенденцию, когда появляются ЯП с пермиссивной культурой. А Раст именно имеет пермиссивную природу.
Корпорации монополизирующие рынок должны обанкротится.
Так а если я за корпорации и ответственный капитализм?
А я за малый и средний бизнес.
> ни OpenSSlНапример, curl (так же как и firefox), давно уже использует Rustls.
> ни Gnome
внезапно
https://wiki.gnome.org/Hackfests/Rust2020
https://www.youtube.com/watch?v=zmrWdPI9R1oХром вовсю движется в том же направлении
https://security.googleblog.com/2021/09/an-update-on-memory-...Да и в целом, всем, кто начинает новые проекты на Rust, как-то параллельно на признание со стороны динозавров. Адаптируются - выживут, не адаптируются - найдётся кому занять освободившуюся экологическую нишу.
Вангую утечки памяти!
Это не баг, это защита от use-after-free.
Там одни сегфолты, учитывая разыменовывание raw указателя
Вот говорят, почему у Rust такой инопланетный синтаксис? А вот ответ: "Автор дал проекту название Rust, по его словам связанное с грибами семейства ржавчинные (англ. rust fungi)".
Лучше бы для названия выбрал из семейства псилоцибиновых.
Ошибка в том что не взяли за основу синтаксис Питона
За синтаксис питона надо сразу грязными тряпками и тухлыми фруктами забрасывать... И автора, и последователей....
_bittestandcomplement64 читатьудобнословнетуописатьвосторг
Это просто широко используемые имена, не в Rust их придумали:
https://docs.microsoft.com/en-us/cpp/intrinsics/bittestandco...
Что стало с идеей сделать сделать хоть чуть лучше, чем С ? Если вы создаёте новый язык (пусть даже с вырвиглазным синтаксисом) зачем тащить в него го..код ? Это же нечитаемо!
И ответа от этого супермена защитничка не последовало. Типичные ржавые
> И ответа от этого супермена защитничка не последовало. Типичные ржавыеА что можно (и нужно ли?) ответить местному ламерью, которое об интринсиках ни ухом, ни рылом?
https://software.intel.com/sites/landingpage/IntrinsicsGuide...
> Что стало с идеей сделать сделать хоть чуть лучше, чем С ?
> Если вы создаёте новый язык (пусть даже с вырвиглазным синтаксисом) зачем
> тащить в него го..код ? Это же нечитаемо!И правда, какая глупость - использовать для интринсиков устоявшиеся и легко гуглящиеся обозначения.
А придумали бы свое - можно было бы гордо заявлять "опять хрустики переизобрели велосипед и выдумали свои названия, главное чтоб не как в ненавидимой ими сишечке/плюсиках! Фу!"
Вин-вин ситуация, че ...
>> использовать для интринсиков устоявшиеся и легко гуглящиеся обозначения.ну, так можно пойти ещё крохопулечку дальше и использовать устоявшиеся и легко гуглящиеся языки...
>>> использовать для интринсиков устоявшиеся и легко гуглящиеся обозначения.
> ну, так можно пойти ещё крохопулечку дальше и использовать устоявшиеся и легко
> гуглящиеся языки...Скорее, просто чесать об этом языком на опеннете ...
Для тех кто додумается мигрировать с хруста на c++ вот инструкция как на c++ делать borrow checker https://www.youtube.com/watch?v=Lj1GppqNr8c Да C++ Core Check из Visual Studio не код, будет иметь мозг не хуже этого вашего храста.
А ещё можно гвоздём на полу расчертить шахматную доску, а шашки из грязи слепить.
Пока в дистры не будут своевременно завозить релизы и ночные версии, и пока разработчики не перестанут пользоваться ночными фичами, язык так и останется проблематичным в использовании, а значит - ненужным. А снап свой пусть себе в одно место засунут.
с огромной вероятностью продакшн уже на контейнерах, доставить что надо или даже скомпилить бинарник и покласть в реестр образов такой контейнер не вызывает особых проблем. Дистрибутивы уже нужны полутора землекомпам-админам.
Руст вытаскивает из unsafe всячину, Zig готовится к самокомпилированию – ляпота да красота
> Код для разбора чисел с плавающей запятой в стандартной библиотеке переведён на использование более быстрого и точного алгоритма Эйзеля-Лемира, применение которого решило некоторые ранее наблюдаемые проблемы с округлением и разбором чисел с очень большим числом цифр.С точностью до наборот. Цитирую:
The Eisel-Lemire algorithm is very fast (Lemire’s blog post contains impressive benchmark numbers, e.g. 9 times faster than the C standard library’s strtod) but it isn’t comprehensive. There are a small proportion of strings that are valid numbers but it cannot parse, where Eisel-Lemire will fail over to a fallback ParseNumberF64 implementation.
VERY FASL BUT ISN'T COMPREHENSIVE.
Этот алгоритм более быстрый, но менее точный. В случаях, когда он не может правильно разобрать число, происходит откат на стандартный С-алгоритм.
> but it isn’t comprehensiveПро точность там где? Не покрывает все случаи, не "всеобъемлющ" - да.
> There are a _small proportion_ of strings...
Ну так в большинстве случаев работает как надо и в 9 раз быстрее. Наверное выигрыш в среднем выше, когда 100 раз выполнит в 9 раз быстрее, а на 101-ый откатится на стандартный С-алгоритм.
А где я говорил, что это плохо, что вы так рьяно кинулись защищать? Подозрительно...Я только исправил новость, вот и все.
>printlnЧому не православный writeln?
Потому шо запись конкретно в stdout принято везде называть принтом. райт более абстрактый - для любого дескриптора/сокета
>Потому шо запись конкретно в stdout принято везде называть принтом. райт более абстрактый - для любого дескриптора/сокетаИ да. и нет.
1. print - распечатать в смысле "вывести", куда угодно, в том чиле и на экран монитора; write - записать в исходник.2. Это просто две разные традиции. Европейская Алголоподобное и Американское Си-подобное.
Всякая хрень для попсовых программистов последнее время выходит. Для слабакок. Всякие питоны, расты и тому подобная попса. Епрст учите с++ это единственное, что стоит учить. Все остальное просто однодневная парша.
Шаблонно и неинтересно. Серебряных пуль нет
осторожно. так можно проспать эволюцию)
Так люди и изучают Расты, Жабы и Питоны чтобы уйти от "Си плюс-плюс". В Мозилле когда-то поговаривали, что Раст заменит Си плюс-плюс. Один жабист мне сказал. что после перехода с Си плюс-плюс на Жабу, он стал мало писать. Наверно он имел ввиду компактность кода.
и мало какать
Ну как, сколько %% FF переписали на раст? Менее 10%?! А ведь прошло 15 лет с 2006-го!
Добавить бы immutables и borrow checker в Go. А так приходится в сторону Rust смотреть, хоть и сттабельность кода слегка пугает. Хотя, полагаю, это просто дело привычки.
s/сттабельность/читабельность/ (автозамена)
На Rust будете стабильно переписывать.
>Стабилизирована возможность указания незакрытых диапазонов в шаблонах ("X.." интерпретируется как диапазон, который начинаетсяинтересная фича, жаль что в Kotlin такой нет.
У тебя есть возможность написать это как библиотеку и прославится (нет)
Как вы себе представляете изменение логики оператора when с помощью библиотеки?
Эй, жаждущие безопасности и контроля, уже давно для вас придумали и создали неско поколений стандартного языка Ada. Используйте! Только не надорвитесь :)
Раст модный язык, Ада не модный язык. Я выбираю модный язык.
Модный это Go. Ты опять ошибся.
Раст - это высокая мода.
> высокаяплавающая
Толку от твоего выбора как и от раста.
И как вегда ниочём. Виджетов не завезли, нормальных шаблонов не завезли, проектов не завезли. Только блаблабла
Нытьё формошлёпа очень важно для нас.
Ну да. Гораздо важнее очередная версия языка от балаболов на котором нет ни одного законченного и работающего продукта.
> Ну да. Гораздо важнее очередная версия языка от балаболов на котором нет ни одного законченного и работающего продукта.И какой же версии (и как вообще называется) твой ЯП, о самокритичный ты наш?
Профессиональное, качественное, недорогое фотометр КФК-3-01 в РФ
Профессиональное, качественное, недорогое заказать фотометр КФК-3-01
Кчественные спектрофотометры в РФ