Доступен выпуск инструментария uutils coreutils 0.0.18, в рамках которого развивается аналог пакета GNU Coreutils, переписанный на языке Rust. В состав coreutils входит более ста утилит, включая sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln и ls. Целью проекта является создание кроссплатформенной альтернативной реализации Coreutils, способной работать в том числе на платформах Windows, Redox и Fuchsia. В отличие от GNU Coreutils реализация на Rust распростраеяется под пермиссивной лицензией MIT, вместо копилефт-лицензии GPL...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58910
Изучаю раст - а он не так уж и плох. Боров чекер сильно ограничивает, но безопасность того стоит. Что касается синтаксиса, то там все хорошо, в плюсах он гораздо ужаснее. Что касается аргумента от "язык макросов отличается от языка самого раста", то это пустой аргумент, ибо в си тоже пишешь на двух языках одновременно: CPP (C preprocessor) и C (C). Все инструменты под рукой: пакетный менеджер, сборщик, форматировщик, генератор документации -- в си каждую приблуду придется ставить отдельно, причем пакетного менеджера нет в принципе, и не будет. Есть концеция "фич". Допустим, crossterm знает все о том, как выводить цветной текст в терминал, а lscolors имеет опциональную поддержку crossterm, если врубить для нее такую фичу.
>Боров чекер сильно ограничивает, но безопасность того стоит.Абстрактная безопасность. Оно того стоит https://www.opennet.ru/opennews/art.shtml?num=56551
>Что касается синтаксиса, то там все хорошо, в плюсах он гораздо ужаснее.
Еще более наркоманский чем в плюсах. Причем в плюсах это наследовали от си, а си это древнючий мамонт, а зачем такой синтаксис в 2014 в совершенно новом языке - непонятно.
>Что касается аргумента от "язык макросов отличается от языка самого раста", то это пустой аргумент, ибо в си тоже пишешь на двух языках одновременно: CPP (C preprocessor) и C (C).
В С он по сути сводится к копированию. Это довольно грубый, но хотя бы простой подход.
В плюсах уже есть темплейты и они уже встроены в язык (хоть как-то) и довольно мощны, но все равно с ними много исключений и нужно быть осторожным. И насколько я понимаю раст берет все (худшие) недостатки темплейтов из плюсов. В современном языке хотелось бы видеть что-то более элегантное и надежное, без усложнения отладки, без сильного увеличения времени компиляции. Но раст пошел дальше и еще добавил DSL (там где и макросы не хотелось бы видеть). Серьезно?>Все инструменты под рукой: пакетный менеджер, сборщик, форматировщик, генератор документации -- в си каждую приблуду придется ставить отдельно
Что же тут может пойти не так? https://www.opennet.ru/opennews/art.shtml?num=58458
> в си каждую приблуду придется ставить отдельно, причем пакетного менеджера нет в принципе, и не будет
Есть и не один. Да, его придется ставить и это хорошо.
>Есть концеция "фич". Допустим, crossterm знает все о том, как выводить цветной текст в терминал, а lscolors имеет опциональную поддержку crossterm, если врубить для нее такую фичу.
Растоманы так носятся с этими фичами и трейтами, но это же синтаксический сахар, да и не первой свежести.
> Абстрактная безопасность. Оно того стоит https://www.opennet.ru/opennews/art.shtml?num=56551Типичный эксперт опеннета, который не в состоянии отличить язык от библиотеки
Типичный эксперт опеннет по экспертам опеннета.
>> Абстрактная безопасность. Оно того стоит https://www.opennet.ru/opennews/art.shtml?num=56551
> Типичный эксперт опеннета, который не в состоянии отличить язык от библиотекиУ глиняного колосса еще одна рука отвалилась. Теперь растоманы не считают карго частью раста (хотя совсем недавно это было одним из основных преимуществ языка и тогда растоманов не смущало что это либа).
Каким образом гарантии memory safety, которые и даёт Rust, могут защитить от data race? От data race в принципе, кроме valgrind-а какого-нибудь, ничего не спасёт, да и то не на 100%.
> Каким образом гарантии memory safety, которые и даёт Rust, могут защитить от
> data race? От data race в принципе, кроме valgrind-а какого-нибудь, ничего
> не спасёт, да и то не на 100%.Так и я про тоже. Да и memory safety решается использованием безопасных типов и умных указателей (ну и если хочется можно добавить харденинг вроде опций компилятора, системы или аппаратных расширений)
>> Боров чекер сильно ограничивает, но безопасность того стоит.
> Абстрактная безопасность. Оно того стоит https://www.opennet.ru/opennews/art.shtml?num=56551Именно. Ошибки связанные с логикой никто не отменяет. Реализация, повторённая на новом языке, пройдёт ровно тот же путь стабилизации, что и исходный тулкит, это очевидно. То есть вот те несколько десятков лет, что стабилизировался условный coreutils на сях -- вот тот же самый путь теперь предстоит пройти новому тулкиту на раст.
Зачем он нужен -- вопрос в целом понятный:
1) Во-первых сменить лицензию, корпорастам уже давно не нужен GPL, чтобы сотрудничать: они прекрасно сотрудничают и без лицензионного принуждения, и потому GPL приносит им больше проблем, нежели пользы; так что реализацию нужно повторить, причём так, чтобы это был не производный продукт; лучший способ, как можно этого добиться -- переписать на другом языке.
2) Во-вторых это снижает стоимость поддержки в долгосрочной перспективе, поскольку исчезает весьма немалый пласт ошибок, связанных с выходом за пределы допустимых областей памяти. Но это, конечно же, не основное, поскольку это будет лишь в очень отдалённой перспективе, ибо на ближайшее десятилетие само собой будут превалировать ошибки логики.>> Все инструменты под рукой: пакетный менеджер, сборщик, форматировщик, генератор документации -- в си каждую приблуду придется ставить отдельно
> Что же тут может пойти не так? https://www.opennet.ru/opennews/art.shtml?num=58458Странный наезд. С пакетным менеджером жить лучше, чем без него. И тем более хорошо, когда есть официальная имплементация оного. Ну да, эталонная реализация у растаманов оказалась так себе (я не знаю, как иначе объяснить CVE по ссылке выше, кроме как криворукостью и безалаберностью), и это повод призадуматься, какого уровня специалисты оказались в данной нише. Большинство ли разработчиков на RUST имеют подобную квалификацию, или нет -- покажет только время, оно-то в итоге всё по полочкам и расставит.
> Растоманы так носятся с этими фичами и трейтами, но это же синтаксический сахар, да и не первой свежести.
Ничего удивительного, это просто пиар. Язык должен всеми силами привлекать к себе пользовательскую базу или подохнет: ну серьёзно, какому бизнесу нужен язык, если к нему не прилагается очередь разработчиков, жаждущих пройти собеседование на только что открытую вакансию по нему?
>си это древнючий мамонт, а зачем такой синтаксис в 2014Чем тебе синтаксис сишки не нравится?
>>си это древнючий мамонт, а зачем такой синтаксис в 2014
> Чем тебе синтаксис сишки не нравится?Очень перегружен. Куча лишних "{}<>#;%1f", магических знаков, макросов. Я уже привык к этой жути, но каждый раз когда возвращаюсь с современного языка ужасаюсь.
Много устаревших и неудобных конструкций (вроде спецификаторов формата в строках, их наверное только профессиональные сишники и помнят) (пофикшено в C++)
Много лишних и очевидных слов (тоже пофикшено в C++).
Вот как могло бы выглядеть более современное представление (увы, для указателя я не придумал замены, в идеале должно быть понятно что это указатель, а не логическая операция например, еще идеальнее если будет понятно как называется этот элемент не перелистывая спецификацию к языку):
include stdiodouble first
printf "Enter number: "
scanf &first
printf "Number: {first}"
return 0И оригинал
#include<stdio.h>int main() {
double first;
printf("Enter number: ");
scanf("%lf", &first);
printf("Number: %.2lf", first);
return 0;
}
> Вот как могло бы выглядеть более современное представление (увы, для указателя я
> не придумал замены, в идеале должно быть понятно что это указатель,
> а не логическая операция например, еще идеальнее если будет понятно как
> называется этот элемент не перелистывая спецификацию к языку):
> include stdioНе различает
#include<stdio.h>
#include "stdio.h"впрочем, м.б. и не надо
> double first
static storage duration
в оригинале automatic> printf "Enter number: "
> scanf &first
> printf "Number: {first}"
> return 0С точкой с запятой всё просто в простых примерах, как и с круглыми скобками - можно просто убрать. Вопрос, что с более сложными.
Вы смотрели язык Genie? Это Vala (транслируется в Си) с синтаксисом Python.
Почему-то на нём не пишут (я не нашёл проекты), в отличие от Vala.
Подозреваю, как раз из-за всех этих "лишних" символов.> И оригинал
> #include<stdio.h>
> int main() {
> double first;
> printf("Enter number: ");
> scanf("%lf", &first);
> printf("Number: %.2lf", first);
> return 0;
> }
> С точкой с запятой всё просто в простых примерах, как и с
> круглыми скобками - можно просто убрать. Вопрос, что с более сложными.Скобки и точки с запятыми это всего лишь разделители, их всегда можно заменить на другие разделители, в т.ч. в самых сложных случаях.
> Вы смотрели язык Genie? Это Vala (транслируется в Си) с синтаксисом Python.
Нет, посмотрел на примеры, нечто такое и хотелось бы видеть.
> Почему-то на нём не пишут (я не нашёл проекты), в отличие от
> Vala.
> Подозреваю, как раз из-за всех этих "лишних" символов.Достаточно упоминания гнома, чтобы отпугнуть всех желающих :)
А вообще я придерживаюсь мнения что само существование высокоуровневых языков (и си на мой скромный взгляд первый виновник в этом преступлении) привело к появления потрясающего количество ошибок и неоптимальных программ по перетасовке байтиков (в духе преобразования из int в string, из string в unicode string, из unicode string в double и обратно в int) и собственно расцвету ада зависимостей от зависимостей. В идеале я считаю надо спуститься ближе к псевдоассемблеру (или условному байткоду) и постараться сохранить скорость разработки (частично она итак ускорится из-за устранения лишних абстракций) без запрятывания реализации под ковер как это делают высокоуровневые языки.
>> С точкой с запятой всё просто в простых примерах, как и с
>> круглыми скобками - можно просто убрать. Вопрос, что с более сложными.
> Скобки и точки с запятыми это всего лишь разделители, их всегда можно
> заменить на другие разделители, в т.ч. в самых сложных случаях.
>> Вы смотрели язык Genie? Это Vala (транслируется в Си) с синтаксисом Python.
> Нет, посмотрел на примеры, нечто такое и хотелось бы видеть.
>> Почему-то на нём не пишут (я не нашёл проекты), в отличие от
>> Vala.
>> Подозреваю, как раз из-за всех этих "лишних" символов.
> Достаточно упоминания гнома, чтобы отпугнуть всех желающих :)В том-то и дело, что Vala не отпугивает. Язык прикручен к GLib, но технически можно писать без неё
> А вообще я придерживаюсь мнения что само существование высокоуровневых языков (и си
> на мой скромный взгляд первый виновник в этом преступлении) привело к
> появления потрясающего количество ошибок и неоптимальных программ по перетасовке байтиков
> (в духе преобразования из int в string, из string в unicode
> string, из unicode string в double и обратно в int) и
> собственно расцвету ада зависимостей от зависимостей. В идеале я считаю надо
> спуститься ближе к псевдоассемблеру (или условному байткоду) и постараться сохранить скорость
> разработки (частично она итак ускорится из-за устранения лишних абстракций) без запрятывания
> реализации под ковер как это делают высокоуровневые языки.Си и есть псевдоассемблер. Некоторые ассмеблерщики его так и изучали - смотрели, в какие инструкции компилируется исходник. Другое дело, что на Си пишут в том числе и те, кто не понимает, как железо работает. Что Вы описываете, похоже на MSIL. Я даже видел человека, кто в том байткоде и кодит, без Сишарпов и Додиезов.
>Что касается синтаксиса, то там все хорошо, в плюсах он гораздо ужаснее.Сравнить левую пятку с мандарином.
Раст ближе к классическому Си.
Говно эта концепция фич. Несовместима с динамической линковкой. Как и весь раст. Каждый разработчик на Rust должен платить налог на обновление компов всем остальным, пропроционально количеству сжираемой им памяти * количество установок. Ибо это по его вине софт жрёт столько памяти, что мне ком придётся на свалку отправить, ибо теперь даже ванильный firefox просто запустить нельзя, либо системе трэшит, либо вылетает сам..
Если языку нужен пакетный менеджер и своя система сборки сложнее make (которым можно не только код собирать, а, например, запускать кодогенераторы на чём-то ещё), то это плохой язык.
Это ты сам такие требования ввёл? Они реальности соответствуют примерно никак - попробуй большой проект на одном мейке и без пакетов сделать. Надоест тебе это развлечение очень быстро.
Ядро Linux-a для сборки требует только GNU make.
в линуксе пакеты не ставии? ну или исходники не компилировали библиотек не разу? или у вас в час по 1000 новых приблуд ставится??
Ну реально достали уже. Всё подряд переписывают, ничего до конца не доводят, но радостных отчётов как говна за баней.
А что конкретно не довели до конца? И нгапример можно ли казать, что доевли до конца Widnows или Linux? По мне так пиши грамотно не соответствет твоим ожиданиям.
В линуксе? в линуксе только команду cat до конца довели (и то, не уверен на 100%), а всё остальное отваливается через релиз. Без знания консоли им пользоваться невозможно в принципе. Да и со знанием - сплошной гемор, даже в простом обращении с файлами.
> Без знания консоли им пользоваться невозможно в принципе.Хи, хи... Специально ж так сделано.
Выходит, успех! :)
Ну не было же новостей "проект на расте доведён до конца", вот он по этому и судит =)
Вы сначала покажите что довели, из того что здесь рекламировалось. А в какую новость про руст не посмотришь - так васянская поделка на 300 строк. Тор переписали? Нет. Греп грозились переписать. Тоже нет. М.б. FF целиком переписан? Не только нет, но и разработчиков погнали ссаными тряпками с проекта. А к тому что переписать успели (css) есть нарекания - тормозит ещё хуже прежнего.
Мне вот давно интересно
А наши местные растохейтеры это все один психбольной или вас двое?ripgrep прекрасно работает, быстрей и эффективней
fd(альтернатива find) прекрасно работает, быстрей и эффективней
Куча всякого серверного софта, типа shadowsocks-rust, прекрасно работает
А опеннет все несет чушь
fd работает быстрее, если запущена па NVME диске а сравнивается с find запущенной на NTFS-3G разделе и USB2.0 флэшке?
Вот никак не могу понять - зачем использовать ripgrep при наличии собственно grep? В качестве замены второму первый годится ровным счетом "никак" т.к. несовместим по синтаксису примерно совсем а переписывать over9000 башевской лапши по всей системе - ну, такоэ. А использовать два grep'а - в скриптах (в том числе и чужих, да) один - а "для души" другой, периодически натыкаясь на отсутствие реплейсмента у "бездушных" - это прям очень специфический склад ума иметь нужно.
Каких-то Решительных Преимуществ вроде как и нет - в реальной жизни разница в объеме данных который grep уже "не тянет", ripgrep "еще да" а какой-нибудь elastic или там бинарные логи с нормальной индексацией рано прям маленькая как по мне.
1. Скрипты на баше можно переписать уже на какой-нибудь язык например Python или ну Rust в конце концов не в 90-е живем
2. Никто ради разовой операции поиска подстроки в директории вытащенной из гита пять секунд назад поднимать Elastic не станет, а вот подсветочка в ripgrep под венду работающий так же почему бы и нет
1. Уелкам! За себя и за того парня, желательно.
2. А что там с подсветочкой? В wt все работает - а луддиты с cmd.exe... Ну, пусть вот на расте переписывают.
> Ну реально достали уже. Всё подряд переписывают, ничего до конца не доводят, но радостных отчётов как говна за баней.А как еще тестировать язык?
И второй вопрос, чисто риторический и из праздного любопытства: Вам-то от этого какая печаль?
Что-то долго тестируют, пусть бы уже что-нибудь оригинальное написали.
> Что-то долго тестируют, пусть бы уже что-нибудь оригинальное написали.Писать что-то оригинальное с целью протестировать язык? Вот скажите мне по-честному, пусть удалось Вам заработать кучу бабок и решили Вы стать венчурным капиталистом. Станете Вы вкладывать свои бабки и бабки доверившихся Вам людей в такую авантюру?
Ну с CPython и Go пишут только оригинальное.
Nushell написали. Про бэш и скрипты на нём можно забыть навсегда.
> Nu speaks JSON, YAML, SQLite, Excel, and more out of the box.Excel - позабавило. Могут не справиться взяв слишком широко - смешав не относящееся др. к др., увеличив сложность.
> А как еще тестировать язык?А, так это они для тестирования языка уже почти 10 лет переписывают? Теперь понятно.
Но возникает другой вопрос: нафига писать про это новости на опеннете? Почему, когда какой-то другой васян тестирует c++, он не оповещает об этом весь интернет? А про раст - на каждую васянскую поделку - новость. Вот из недавних:
* Инициатива по переработке инструментария для гипервизора Xen на языке Rust
* Командную оболочку Fish планируют переписать на языке Rust
* Прогресс в разработке пользовательского окружения COSMIC, написанного на RustВидишь? Тут местами даже ещё не написано ничего, а уже "Ура, руст шагает по планете".
И ещё куча такого же мусора.
> Но возникает другой вопрос: нафига писать про это новости на опеннете? Почему, когда какой-то другой васян тестирует c++, он не оповещает об этом весь интернет? А про раст - на каждую васянскую поделку - новость. Вот из недавних:Потому, что людям это нравится читать, они эти материалы обсуждают, пишут свои отзывы и мнения. Вот как, например, мы с Вами.
Насчёт "нравится" - не согласен. Больше негативных отзывов. Но суть понятна - любой срач полезен для продвижения "продукта".
Маркетологи захватили мир программирования. И это грустно.
Почему грустно? Пока маркетологи на стороне добра, пока они продвигают Rust — наоборот хорошо, что они есть, нет?
> Почему грустно? Пока маркетологи на стороне добра, пока они продвигают Rust — наоборот хорошо, что они есть, нет?Вот я согласен, что это вряд ли грустно и что хорошо, что маркетологи есть. Единственное замечание -- маркетологи всегда на стороне бабла, а уж окажется эта сторона доброй или злой... Маркетологам нужен какой-нибудь перекос, если его нет, они его создадут. В какую сторону -- не важно, и это не просто хорошо, это -- замечательно.
В общем, если удалось привлечь маркетологов, то это уже большое дело для проекта. С другой стороны, у С++ и Питона маркетинга, по сравнению с Растом, вообще нет. Прут сами по себе. И это тоже здорово.
> Пока маркетологи на стороне добра, пока они продвигают RustСкандалами, интригами, расследованиями продвигают однодневную попсу. Потому, что пипл бабки только один раз за такую попсу понесет. Второй раз на ней срубить не получится.
Пустыми новостями продвигают лишь попил бюджета, чтобы пипл не возмущался сразу, пока пилищики еще не сбежали с баблом.Уж сколько было замечательных обзоров на Nikola One. Потом на Nikola Two. А их защитники бегали по форумам в попытках заткнуть рты тем, кто не верит в светлое будещее.
Про раст почему-то все точно так же.
Тут местами даже ещё не написано ничегоА местами и написано, много. Если сидишь сейчас в файерфоксе, то вебрендерер и многопоточность там на расте. Если пользуешься андроидом, то в 13 версии в _новом_ нативном коде (это си/плюсы/раст) раст составляет 21% и заявлено стремление всё новое нативное в дальнейшем писАть на расте вместо си/плюсов. И это не единственные примеры. Но тебе всё божья роса что бы тебе не говорили и в какие ссылки бы не макали.
>Если пользуешься андроидом, то в 13 версии в _новом_ нативном коде (это си/плюсы/раст) раст составляет 21%https://www.opennet.ru/opennews/art.shtml?num=58249
>В Android 13 примерно 21% от добавленного нового компилируемого кода написано на Rust, а 79% на C/C++. В репозитории AOSP (Android Open Source Project), в котором развиваются исходные тексты платформы Android, насчитывается примерно 1.5 млн строк кода на RustНовый код это, конечно, круто, но посмотрите ОБЩЕЕ соотношение кода.
> Новый код это, конечно, круто, но посмотрите ОБЩЕЕ соотношение кода.Аргумент уровня "русский язык это конечно круто, но посмотрите сколько на китайском и английском разговаривают".
> Аргумент уровня "русский язык это конечно круто, но посмотрите сколько на китайском и английском разговаривают".А что не так? Этот аргумент имеет рациональное зерно, лол.
Потому что новости про раст читают и комментируют, а новости про с++ никого не интереуют
Потому что поиск "SFINAE" на Опеннет выдаёт пустое множество сообщений.
Это, вероятно, и есть цель и задача, отчёты )
Хм, возможно. Возможно все переписки на Rust - это лабораторные работы в каком-нибудь MIT. В любом случае люди неплохо набивают руку, может и до чего серьёзного дойдёт.
Начали в 2014 году (https://www.opennet.ru/opennews/art.shtml?num=39989), до сих пор половина тестов не выполняются. Это успех, я считаю :-)
стало быть есть к чему стремиться
Главное это же хайп. А дальше ChatGPT будет все переписывать с любого языка на любой.
Я об этом же написал, лол, что самый лучшие программисты на самом лучшем языке не могут переписать 100 файлов по 1к loc за такое время. Но модераторам почему-то такое сообщение не понравилось и он его удалил... Больно, наверное, правду осознавать.
Тут надо разделять цели языка, который в целом хорошие и хайповые, и реализацию. Реализация языка раст не выдерживает совсем никакой критики от слова ваще.
Не нужно превращать технническую область(в нашем случае программирование) в гуманитарную и политическу помойку, где выбор идет не по техническим причинам, а потому что "можно", " хайпово", "правильные вещи говорят". Если послушать, то цели у всех хорошие, а потом получается бочка дегтя и ложка меда.
в 2014м они первый (пресс-)релиз сделали, а писать начали еще в 2013.
Стопе оно что под линукс не работает? Это как они так умудрились?Это я уже не говорю про зачем тут раст когда все эти тулзы проще переписать на быстрый и безопасный язык Go. Самое забавное что go-coreutils написан ещё 8 лет назад и полностью работоспособен.
> Самое забавное что go-coreutils написан ещё 8 лет назад и полностью работоспособен.https://github.com/ericlagergren/go-coreutils#completed
Completed: 15/100Чувак 8 лет назад написал реализацию 15ти утилит, почти не двигался все эти 8 лет, а в феврале этого года и вовсе архивнул репу.
https://github.com/aisola/go-coreutils
Not all commands have the flags you may expect.Чувак 9 лет назад написал реализацию 40 утилит, но в целом не особо парился над совместимостью утулит с оригиналом по флагам и поведению. Точно так же заброшено.
Да представь себе, дорогой мой, фанатик. Он просто 8 лет назад написал все что хотел и забил потому всё что надо он сделал. А не орал 8 лет как он безопасно все переписывает с сотней новостей.
> Он просто 8 лет назад написал все что хотелвсё, что смог
> и забил
на самое сложное и нужное другим, а не ему - совместимость и паритет по возможностям с оригиналом
> потому всё что надо он сделал
а надо ему было, вероятно, просто новый язычок изучить, потренироваться, а не сделать для всех безопасную, полностью совместимую с оригиналом, замену.
А вот здесь, судя по тому что не забрасывают и реализуют всё новые и новые флаги в бОльшем числе утилит, чем у гошника, поставили себе цели более глобальные и трудные
Меня вот интересует, сколько процентов гнутых тестов выполняет занятойкоробок. Вот тут есть очень рабочий порт busyboxа и gnu make https://github.com/xpack-dev-tools/windows-build-tools-xpack
Где ты был 8 лет?
> MIT, вместо копилефт-лицензии GPLосновная причина, а раст как морковка для осликов
и волки сыты, и баранам не жарко
сколько оно весит?
сколько оно собирается?
Сколько зависимостей оно тянет?
1m 2s - х. знает зачем тебе это правда в конкурсе каком участвуешь?
1.5 ГБ
Переписали готовое, работающее, и теперь львиная часть тестов не проходит.
Откуда у них руки?
Из политкорректного места, очевидно.
У тебя в закладках не сохранилось того коммента где анон конкретно разложил недостатки и опасности раста? У себя не нашёл (
Из применимого к своеё координатной сетке Политбюро?
>Из политкорректного места, очевидно.Сказал собиратель маргинального дистрибутива линукс под маргинальный процессор, который вот уже 40 лет пилят пилят, да все не выпилят.
Когда эльбрус зохватит мир?
Какая тебе разница? Люди пишут своё, да пусть пишут. Они может только по праздникам пишут код в свое удовольствие. 8 лет - это ничего по сути.
8 лет - это полторы пятилетки или две пятилетки, если ударно программировать.
Какие приложения вы написали за 8 лет? Можно ссылки на гитхуб?
echo "Hello World!" > index.html
Вот держи:
https://github.com/Winderton
По-моему, для DX вместо GetMessage() следует PeekMessage(), если хотите отображать анимацию без зависаний при отсутствии сообщений. Или придётся лепить фиктивный таймер.Вместо __asm int 3 в MSVC есть интринсик __debugbreak().
>> если хотите отображать анимацию без зависаний при отсутствии сообщенийэто у вас зависает, я всё правильно нпаписад
>> Вместо __asm int 3 в MSVC есть интринсик __debugbreak().
я в программирование больше 10 лкет, я сам знаю как мне вызывать прерывания
>>> если хотите отображать анимацию без зависаний при отсутствии сообщений
> это у вас зависает, я всё правильно нпаписадДа, это верная копипаста из MSDN. Пока этот код ничего не анимирует на экране, естественно, с ним нет проблем.
>>> Вместо __asm int 3 в MSVC есть интринсик __debugbreak().
> я в программирование больше 10 лкетНо собирать код разными трансляторам за эти 10 лет, очевидно, не приходилось. Как и видеть в стандарте определение well-formed translation unit.
> я сам знаю как мне вызывать
> прерыванияВызвать можно прерывание 2Eh. А 3-е прерывание вызывает ловушку.
> Но собирать код разными трансляторам за эти 10 лет, очевидно, не приходилось.в отличие от вас собирал.
> Как и видеть в стандарте определение well-formed translation unit.
А это тут при чем?
> интринсик __debugbreak()
и что мне делать с gcc, clang, где нет этой встроенной функции?
>> Как и видеть в стандарте определение well-formed translation unit.
> А это тут при чем?__asm это ill-formed. То есть не Си++
>> интринсик __debugbreak()
> и что мне делать с gcc, clang, где нет этой встроенной функции?Скопипастить у меня и дописать
#ifndef __ICL
extern "C" void __debugbreak();#ifdef _MSC_VER
# pragma intrinsic(__debugbreak)
#endif
#endifstatic __forceinline
void debugbreak()
{
__debugbreak();
}
тесты не проходят скорее всего из-за различий в реализации фич (то есть это не падение утилиты как таковой, просто результат отличается от эталонного)
Анекдот про машинистку, печатающую 1200 символов в минуту?
Объяснить я сам могу что угодно. Откуда руки ростут, неспособные даже списать с готового?
Если ты можешь объяснить что угодно, то есть супер специалист. Тогда, где твои приложения?
А твои?
У Роста?
Вот пришел ты в магазин, а там есть кило кортошки за 40 рублей и бесплатно, но нужно 30 послушать рекламу и намазать на себя 30 пробников. В целом наверное любителям халявы зайдет, но вот очевидно,
что практической пользы от этого мало.
> "бесплатно, но нужно 30 послушать рекламу и намазать на себя 30 пробников."Это называется условно бесплатно.
Все эти переписывания на расте напоминают мне разукрашивание чёрно-белых фильмов - "ну как же, Штирлиц в цвете же лучше!"
тонко
Ещё можно взять "Броненосец Потёмкин". Причем не только раскрасить, но и озвучить.
> Для определения терминала осуществлён переход на пакет is_terminal вместо atty.Is_terminal зависит от atty:
https://docs.rs/is-terminal/latest/is_terminal/
Ну это же дао раста - проще замести под коврик, раз не можем реализовать ... ну или под unsafe
is_terminal использует atty только для Unix платформ.
Для других он использует другие способы определить терминал.Они просто расширили некросплатформенное решение до кроссплатформенного.
Причем тут замести под ковер - не понятно.
https://docs.rs/atty/latest/src/atty/lib.rs.html
И к чему эта ссылка?
Для винды используется другой вызов, а не ::isatty
https://docs.rs/is-terminal/latest/src/is_terminal/lib.rs.ht...
> is_terminal использует atty только для Unix платформ.А вот и нет. is_terminal использует atty только для тестов. Всё ещё хуже.
А где собсно, о зависимости написано? Нашел только "this is effectively the same as the isatty function" те "это фактически то же самое, что и функция isatty". Что вроде как не то же самое что "is-terminal зависит от atty". В зависимостях is-terminal нет крейта isatty. Или я что-то не так понял?
Вопрос снят, все-таки есть там зависимость от atty, нужно было в dev-deps смотреть. Поторопился, проглядел, замыленным глазом.
Dev-deps потому так и называются, что используются только во время разработки (для тестов, например). В релизный код они не попадают.
Молодцы.
СОгласен. Вот еще б установщик под венду был бы...
Никого не хочу обидеть, но вопросы про Раст неизбежно появляются.
Почему программисты переписывают старые приложения на Раст, вместо того демонстрировать его мощь и эффективность на новых приложениях.
Может быть дело в том, что написание кода на Раст достаточно трудоёмко и сложно, настолько, что на обдумывание алгоритма уже на остается сил?
Раст не упрощает разработку, а усложняет, c благой целью - полученный результат будет более качественный и надежный.Если у вас хватит на это сил и терпения...
Все немного проще. На расте пишут много нового кода, но просто многое не опенсорс и его не видно.> на обдумывание алгоритма уже на остается сил
Тоже немного не так. Ты не сможешь просто взять и переписать с си на раст. Просто потому что оно не скомпилируется из-за borrowing. Придется повозиться, в зависимости от проекта, чтобы код стал доказуем в смысле заиствований.
Не смотря на распространенное мнение что на расте пишут js-ники и т.д., на самом деле многие програмисты пришли из с/с++. И им смотреть в старый код - это почти как смотреть в доку (которой часто нет). Плюс у них уже есть знание матчасти для конкретного проекта.
> Просто потому что оно не скомпилируется из-за borrowing.А почему тогда при переписывани с Паскаля на Си или Си на С# или Яву, и даже с Си на JS и обратно, переписывание не приводит у утрате работоспособности?
> в старый код - это почти как смотреть в доку (которой часто нет).К этому я и веду. Надо не операторы построчно переписывать , мыслить надо выше :)
К тому же современные IDE си-исходники и разберут и на блюдечке с голубой каёмочкой преподнесут.
А где тут утрата работоспособности?
В си ты можешь писать что угодно куда угодно, менять как захочешь из каких угодно потоков, гонять данные через void* и т.д. И тебе за это ничего не будет. Все держится на честном слове разраба.
А тут пойди докажи компилятору, что оно валидно.Переписывание на С#, Ява, JS - мимо, там сборка мусора, есть реальная опасность только в retain cycle.
> Надо не операторы построчно переписывать
Так они и не переписывают. Потом что это нереально. Они повторяют интерфейс (или вызовы, или cli), а под капотом оно вообще другое.
потомушта ruffle.rs все еще стреляет из кривой эскопеты самому себе в оппу.Вот казалось бы - люди не безумные фанатики но апологеты нескучного язычка умеющие и в другие. За деньги (пусть небольшие но регулярно). Взялись переписать то что действительно нужно переписывать ибо имеющееся нельзя использовать.
Им правда нужен безопасный язык - данные сложноструктурированные и обрабатываются непросто. Лучше день потерять на боровчекера чем за час долететь но все больше вниз.
Они во всю используют чужие наработки потому что ну надо экономить труд, его вообще небесконечно.
Они используют фичу компилироваться в вебасм, потому что это надо уметь внутри браузера.
И, и... и... и хрен там. Устаревший апи 96го года реализован на 70 процентов но есть нюансы, апи 2010го года не работает от слова совсем.
И если присмотреться - там по всем перечисленным пунктам сплошное фиаско.
Неправда, не все так плохо.
ActionScript 1&2 - Language 95%/API 73%
ActionScript 3 - Language 60%/API 56%И эти проценты мягко говоря не равнозначные. Одну функцию может использовать 99% программ на флеше, а другую - всего пара. А и та, и другая посчитается как одинаковый процент.
> там по всем перечисленным пунктам сплошное фиаско.
Почему фиаско? Оно выполняет задачу ради которой его писали - сохранение цифрового наследия в виде старых игр и роликов.
И огромное количество таки работает. Никто не ставил первостепенной задачей реализовать весь флеш.
дык ты процентики читаешь или запустить что попробовал?Вот по факту - эскопета стреляет себе в жо через дырку в текстурах. Я проверял разумеется на нормальном флэше - там дырки нет.
Баг репортить постеснялся...зачеркнуто, продолбал очередную учетку в шитхабе и неохота сливать ему мобило.
Но по факту этот мусор был никому неинтересен кроме совсем уж долбанутых коллекционеров еще двадцать лет назад. Потому что все давно перешли на as3. Который у них совсем неживой.
Прошло уже сколько - пять лет?
А щастье ведь было возможно... (есть у меня архив одного сайтика, состоящего из флэшовых видео. И это вот - наследие, а не игори. Сбегать переснять - иных уж нет, а там заминировано.
Увы, нет на свете ни одного плейера написанного на as1. впрочем, уже, конечно, жалеть не о чем.)
Сам тестил. На newgrounds и kongregate.
Ясно что не на всех играх, но то что интересовало и не было переписано на юнити - работало через ruffle.
А VmWare client 5.5 так и не работает.
Но наследие, наверное ... ну ты понел - сохраняется
Еще раз - оно не делалось для запускания софта, сайтов на флеше и т.д.
Оно делалось для флеш-игр.
> Еще раз - оно не делалось для запускания софта, сайтов на флешеа врали что - делалось
А получилось - только примитивные игрули 1998го года и те с глюками.
1999го уже не все.Ну вот такое наследие и вот такие хранители, ага.
Просто для раста выбрана паразитарная модель развития. Это же язык от корпорций и людей, которые приняли CoC. Им главное, чтобы их поделие стало вендорлоком и зацепилось в крупных проектах, а на остальное им строго плевать. Поэтому и переписываются строго системные утилиты, "добавляется" код в ядро, пишутся библиотеки, чтобы от этой корпоративной античелевеческой субстанции было не отмазаться.
Потому что у раста нет никакой мощи и эффективности в принципе.
Потому что новые приложения — это искусственные нейронные сети, а там хоть Си, хоть Фортран, ибо работы с памятью нет никакой, и все навороты Раста не нужны.
В расте есть проблема того, что все зависимости по сути едут в бинарь статической линковкой. В результате:
1) Бинарь получается неимоверных размеров
2) Устранение дырок в библиотеке потребует пересборки всех бинарей, которые от неё зависят.
3) Шэринг библиотек в анонимной памяти становится невозможным.
Напоминает эпопею с программкой gosu (на Go, но принцип такой же), которая меняет юзера с рута на непривелегированного при запуске в контейнерах. Бинарь под alpine весит несколько мегабайт. Аналогичная прога на C - su-exec занимает экран текста, 20 кб в скомпилированном виде и делает то же самое.
> 1) Бинарь получается неимоверных размеровА линкер и оптимизацию не завезли, которые не используемое не линкует?
Не логичнее сперва ли инструмент до ума довести, а не под альфа-версию переписывать?> 2) Устранение дырок в библиотеке потребует пересборки всех бинарей, которые от неё
> зависят.Какие проблемы? Ну пересобрал. А проблема в пункте 1.
> 3) Шэринг библиотек в анонимной памяти становится невозможным.
Да ладно. Просто очевидным путём забыли предусмотреть. ;)
> А линкер и оптимизацию не завезли, которые не используемое не линкует?Почему ты решил, что оно неиспользуемое? У тебя вполне себе программа, дергающая пару вывозов OpenSSL, например, может легко по графу вызовов половину библиотеки заюзать. Если учесть ещё и то, что далеко не весь мертвый код можно вычислить, так как это может сильно зависить от рантайма. Например, ты OpenSSL анонсирует какой-то ciphersuite и peer может теоретически его выбрать. Тот факт, что ни один peer не согласится на этот ciphersuite в реальной жизни, никак не поможет линкеру выпилить его из бинаря.
> Какие проблемы? Ну пересобрал. А проблема в пункте 1.
Проблемы с этого, дружок, такие, что если ты делаешь дистрибутив линукса, например, то тебе нужно пересобрать всё говно на всех платформах, а потом ещё и юзерам раздать. Всё это время, вычислительные мощности и трафик. На своей малинке в подвальчике ты, конечно, никаких трудностей с этим не испытаешь.
> Да ладно. Просто очевидным путём забыли предусмотреть. ;)
Каким образом можно предусмотреть шеринг статически влинкованных библиотек? Тебе бы Танненбаума почитать не мешало бы прежде чем вумные каменты писать на опеннете
>> А линкер и оптимизацию не завезли, которые не используемое не линкует?
> Почему ты решил, что оно неиспользуемое?Вы дукака включаете?
Выявлять не используемое, это не мои заботы, а заботы компилятора и оптимизатора. И удивитесь, для многих языков давно работает.
И при статической то линковке.
> нужно пересобрать всё говно на всех платформах,С таким отношением к коду, и на выходе будет говно.
>вычислительные мощности и трафик.
На чем Вы компилируете? Я удивлен подобной отговорке.
> На своей малинке в подвальчике ты, конечно, никаких трудностей с этим
> не испытаешь.Шерлок, а как Вы догадались?
Да, я использую и Распберри, и мелочёвку, и даже в "гараже", только для сборки в "гараже" есть... кластер из "мусорных" Ксеонов, и когда количество потоков перевалило за вторую сотню, отнощение к перекомпиляции меняется навсегда.>> шеринг статически влинкованных библиотек?
А это точно не ересь?
> Вы дукака включаете?
> Выявлять не используемое, это не мои заботы, а заботы компилятора и оптимизатора. И удивитесь, для многих языков давно работает.
> И при статической то линковке.Это вы дурака включаете, наперед утверждая, что линкер там своё не отрабатывает. Если уж отверждаете - ссылку на godbolt, где по бинарю после линковки видно, что функции есть, а они никем не используются.
> С таким отношением к коду, и на выходе будет говно.
Всё говно. Кроме мочи! Не цепляйтесь к словам. Очевидно, что среди 60000 пакетов, которые есть в Debian, многое - это оно самое. И его всё равно надо будет пересобирать.
> Да, я использую и Распберри, и мелочёвку, и даже в "гараже", только для сборки в "гараже" есть... кластер из "мусорных" Ксеонов, и когда количество потоков перевалило за вторую сотню, отнощение к перекомпиляции меняется навсегда.
В счастью дистрибутивы не собирают у вас в гараже, неговоря уже про то, что куча говна из этих 60000 пакетов в Debian не умеет собираться кросс-компиляторами, а поэтому потребуется не только куча мусорных ксеонов, и всего остального мусорного, если творить дистрибутивы в вашем гараже.
> А это точно не ересь?
Это ересь, конечно, ещё какая. Но это вы же утверждали о том, что её просто не предусмотрели эти рукожопы )
> Это вы дурака включаете,Если в других инструментах опухания бинарников не наблюдается, логично предположить, что причина в несовершентсве инструмента. А то, что несовершенно, если на него не забьют, или будет исправлено, или объявлено уникальной фичей.
Сам излишний размер бинарников не только перерасход места на диске, но и, что хуже, перерасход кэшей процессора.
Можно написать громоздко, и если это значительно подняло быстродействие, то это оправданно. Но если ресурсы потрачены напрасно, не стоит ждать похвал.
И аналогично, при существенной надёжности, тоже можно пожертвовать ресурсами,но.. если это уместно.В упомянутом переписывании, недопереписали, то что проблем не вызывало, и в итоге и склонно к распуханию, ещё и по функционалу стало хуже оригинала.
>> А это точно не ересь?Подвох был в варианте статической сборки, когда скармливается не готовая библиотека, а собирается вместе с исходником, теряя при этом в объёме, но сохраняя быстродействие и переносимость бинарника. Для всего подряд так, действительно, излишняя компиляция, но для чужеродного ПО в системе, переносных бинарников, и критичного ПО.
Для тестов надо показывать ПО лицом.
>для сборки в "гараже" есть... кластер из "мусорных" Ксеонов, и когда количество потоков перевалило за вторую сотню, отнощение к перекомпиляции меняется навсегда.Вот когда из своих денег каждому пользователю ПК купите по кластеру, и оплатите его энергопотребление и обслуживание, тогда и приходите. Балаболить о том, что каждый, у кого нет кластера может идти на *** каждый может. Только это непрофесспонально. А непрофессионалов самих посылаем туда же.
Не всякому разработчику требуется пересобирать системное ПО.
Пользователи, точно, не занимаются пересборкой.
Эксперты как всегда показывают свою экспертность.
Можете динамические библиотеки подключать и пользоваться.
Вам дали такую возможность.
Скоро нейросети будут анализировать программы на Си и делать их безопасными, так что можете уносить свой раст.
... и переписывать на раст
> ... и переписывать на растА смысла не будет - раст чисто от человеческих косяков защищает, нейросетям он просто не нужен.
При этом половина тестов будет переставать проходить
:-)
вот тут нейросеть как раз прекрасно справится, убедительно обосновав что они больше неактуальны.
Ты наверно не в курсе как работают нейронки, но они именно что и делают что подгоняют результат под тесты, т.е. под ожидаемое поведение. Тесты нейронка будет проходить топовым образом причём любая.
> Ты наверно не в курсе как работают нейронки, но они именно что
> и делают что подгоняют результат под тесты, т.е. под ожидаемое поведение.
> Тесты нейронка будет проходить топовым образом причём любая.Для того что бы смочь проходить тесты нейронка должна на ком-то учится. А все - на ком можно учится свои переписывания по тестам прогнать не могут.
Конечно, шутка. Но в каждой шутке...
Нейросети обучат на текущей кодовой базе на Си и... они будут писать такой же код как и там.
Их не писать обучат - писать будут программисты, а анализировать код - т.е. будет мощный статический анализатор на нейросетях.
> Нейросети обучат на текущей кодовой базе на Си и...... и базе CVE-шек и их патчах, образцах, как делать не надо и надо.
Так изначлаьно можно было бы в Си сделать всякие блоки в памяти fat-указателями и не было б проблем,
но нет ребята решеили походить по лезвию ножа...
Показательная новость. Я понимаю что coreutils не студенческая лабораторка, но всёж... Rust годный язык с негодным сообществом. Только вот нельзя отделять экосистему от языка, следовательно язык не такой уж годный.
Сообщество, как и мир, меняется. Сегодня одна мода, завтра другая. А язык останется.
Язык не существует сам по себе, какое у него сообщество - таким он и будет через некоторое время.
Что можете сказать про сообщество GNU и С основываясь на успехах Hurd?
А что можете сказать основываясь на успехах GNU/Linux и еще сотен успешных проектов?
Если бы раст был чем-то хорошим все бы уже давно его использовали без всяких фанатских выкрутасов в комментах и даже не было бы никаких споров.А тут фанатики явно увидели что их язык никому не нужен и пытаются в комментах, что тут, что на реддите, что на гитхабе пропихнуть язык хоть куда-нибудь лишь бы всем показать что смотреть какой он нужный. Но ведь все понимают даже сами фанатики что этот язык нафиг никому не нужен.
Ну тут ты не (совсем) прав. Где-то в комментах тут уже писали, что это очень похоже на проталкивание Java во все дырки.
А дальше принцип пирамиды - тебя поимели, ты выложил свои денежки (ресурсы на обучение), и хочешь чтоб все остальные тоже остались в дураках.
Если бы Rust был чем-то плохим, никто бы уже давно его не использовал, без всяких хейтерских выкрутасов в комментах и даже не было бы никаких споров.
>В отличие от GNU Coreutils реализация на Rust распростраеяется под пермиссивной лицензией MIT, вместо копилефт-лицензии GPL.У некоторых прям свирбит подстелиться под проприерастов.
Да. У всяких FSF, Linux Foundation и прочих.
А тебе прям покоя не дает, что люди живут НЕПРАВИЛЬНО =)
Истинна только в копилефте. Запомни это мальчик. Держись по жизни за Столлмана.
А тебе покоя не дает, что у кого не такое же мнение как у ТЕБЯ!
Давно пользуюсь, полёт нормальный, работают без нареканий.
Да ну?!
Пятилетку назад "на слабо" сравнил grep vs ripgrep. Ripgrep убедительно победил, разгромно. Если бы не --охрененноДлинныйКлючДляРегулярок вообще бы без Но. Если так смогут sed & awk повторить, то это довод.
переписывание идет своим чередом, скоро весь софт будет неподдерживаемым гномом с невозможностью делать security update'ы
Нупочему же: https://security-tracker.debian.org/tracker/CVE-2022-21658
На сколько процентов упала производительность?
А уже есть версия rust написанная на языке rust ?
Да.
Наибезопаснейшая версия раста :)
Конечно есть. https://github.com/rust-lang/rust - держи пруф.
"Since the Rust compiler is written in Rust, it must be built by a precompiled "snapshot" version of itself (made in an earlier stage of development). As such, source builds require an Internet connection to fetch snapshots, and an OS that can execute the available snapshot binaries."Цитата из официальной документации
В качестве оффтопа: кто-то видел сравнение busybox с gnu по тестам?
busy поддерживает меньше опций чем гну, и гарантировано не пройдет часть тестов. Но прамое сравнение быстро не нашлось.
> В качестве оффтопа: кто-то видел сравнение busybox с gnu по тестам?
> busy поддерживает меньше опций чем гну, и гарантировано не пройдет часть тестов.
> Но прамое сравнение быстро не нашлось.Еще бы тойбокс или бсдшные утилиты вспомнили! Вы там че, совсем не понимаИти что ЭТО ДРУГОЕ!!?
Евангелисты rust'а, лучше бы вместо новости про очередное незавершенное переписывание написали новость про выход Slint 1.0.С помощью него, можно GUI для программ на rust'e делать.
Ну так не успели еще. Эта uutils релизнулись 2+ дня назад, а Slint - вчера.
Штука конечно интересная, но с отстойной лицензией.
А для тех, кому это мешает - есть Dioxus, Tauri, egui.
Dioxus - имеет версию 0.3. Что говорит, о намерении перелопачивать API.
Tauri - хоть и написан на rust, но логика работы приложения определяется на JavaScript, HTML и CSS. У таких приложений, конечно, есть своя ниша, но это не gui для rust.
egui - имеет версию 0.21, опять же, говорящую о намеренеии ломать API.Лицензия у Slint - GPL или коммерческая. Для opensource проектов подойдет, для коммерческих проектов подойдет.
Прошелся по этим поделкам тоже... согласен полнейшее барахло все.Кто-то просто сильно очень хочет Web на десктоп,
но Slint как раз дает возможность сделать классические приложения
а в подарок ещё и кодогенратор и поддержку Embedded это
просто супер предложение, а так же есть шанс, что перетащат все
контролы Qt что дает в целом очень широкий простор для интерфесостроительства