Опубликован релиз языка системного программирования Rust 1.58, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=56506
раст рулит!сишники - минусуйте !
---
// Ранее поддерживались конструкции:
println!("Hello, {}!", get_person());
println!("Hello, {0}!", get_person());
println!("Hello, {person}!", person = get_person());// теперь можно указывать
let person = get_person();
println!("Hello, {person}!");
---C in RUST is for Consistency.
(мысль в следующем: какой уровень костыльности пришлось нагородить для обработки специального оператора в аргументе...)
Это же макрос (восклицательнй знак на конце это показывает),
какие специальные операторы и аргументы?
Вы видите восклицательный знак в "person = get_person()", или он в хрусте воображаемый?
И... вот это макрос?
"Hello, {person}!"
То есть там {}! и он выведет "Hello, motherfucker", а не "Hello, motherfucker!", и для последнего надо писать "Hello, {person}!!"?
Это кошмар.
(я бы понял {person!}, но если вы не ошиблись и там всерьёз {person}! - это просто адешник)
Что сказать то хотел?
что если выполняется условие, то это просто адешник.
внимательнее читайте комментарий.
А ты что сказать хотел? Я не пойму, откуда столько ненормальных на опеннете.
Нет, восклицательный знак есть просто в примере.
И кто додумался сделать такой пример, чтобы вводить людей в заблуждение?(
> кто додумался сделать такой пример, чтобы вводить людей в заблуждение?Растаманы, однако.
Да неужели?
Он выведет "Hello, motherfucker!".https://play.rust-lang.org/?version=stable&mode=debug&editio...
О, прикольно, Онаним один восклицательный знак от другого отличить не может... Это же контекст понимать нужно
Ну я и говорю - C is for consistency.
На самом деле речь шла про синтаксис x = y в аргументе, и я это явно выделил.
И даже контекста понимать не нужно, но видимо даже это слишком сложно оказалось.
Прямо как именованные параметры в kotlin и python.
Ну там они везде, а хрустанутые их прикостылили к принту каким-то таким исключительным образом, что даже переменные для подстановки использовать не получалось - до этой версии.
println! -- это макрос. Макросы расширяют синтаксис языка. Ну, типа, чтобы не костылить в язык эллипсис только ради printf, и чтобы не закостыливать в язык целиком writeln (как в паскале), можно этот особый случай не трогать, и дать программисту макросы на такие случаи. Макросы собирают AST кода, из тех аргументов, которые ты им всовываешь.println! разбирает форматную строку и генерит AST нескольких последовательных вызовов для вывода кусков строк и аргументов. Аргументы все должны иметь трейт Display или Debug, каждый из которых сводится к одному методу.
В макросе есть аргумент "person = get_person()", но это не значит, что этот код реально потом останется после раскрытия макроса, потому что макрос может паттерн-матчингом сопоставлять AST этого выражения с $ident = $expr (выкидывая ошибку компиляции, ежели аргумент не подпадает под допустимые паттерны), и потом искать $ident в форматной строке, и вставлять код для вывода $expr.
То есть, в некотором смысле, это и не раст вовсе -- это стандартная библиотека и её стандартные расширения синтаксиса.
> Ну, типа, чтобы не костылить в язык эллипсис только ради printfкак минимум переменное число параметров есть не только в *print*(), но и в *scan*(), *exec*() и даже open(). Да и так, бывает очень удобно использовать и в своих функциях (которые не только обёртки над printf()).
> как минимум переменное число параметров есть не только в *print*(), но и в *scan*(), *exec*() и даже open().Есть не только в printf, да. Но если в printf/scanf без этого сложно обойтись, то в exec и open без проблем вообще. Я вот чесслово не понимаю, нахрена нужно было плодить десяток функций exec*, вполне достаточно было бы одной execve.
> Да и так, бывает очень удобно использовать и в своих функциях
Например когда и зачем? Ты можешь привести последнюю функцию такого рода, которую ты писал? Я по-моему ничего не писал с эллипсисом, кроме обёрток над printf. Во всех остальных случаях можно как-нибудь иначе, типа передать массив с аргументами, например. Массив удобнее: его легко прокинуть куда-то ещё, а va_list -- это очень специальная хрень, которую надо специальным образом прокидывать, и поэтому специально под неё запиливать декларации функций, и весь код обрастает этими va_list, преобразованиями va_list в массив, причём в обратную сторону ты замучаешься преобразовывать, и только системно зависимо, и... короче это безумие.
На самом деле, если посмотреть на код glibc, или даже на документацию, то безумие становится явным:
man 3 printf:
PRINTF(3) Linux Programmer's Manual PRINTF(3)
NAME
printf, fprintf, dprintf, sprintf, snprintf, vprintf, vfprintf, vdprintf,
vsprintf, vsnprintf - formatted output conversionSYNOPSIS
#include <stdio.h>int printf(const char *restrict format, ...);
int fprintf(FILE *restrict stream,
const char *restrict format, ...);
int dprintf(int fd,
const char *restrict format, ...);
int sprintf(char *restrict str,
const char *restrict format, ...);
int snprintf(char *restrict str, size_t size,
const char *restrict format, ...);#include <stdarg.h>
int vprintf(const char *restrict format, va_list ap);
int vfprintf(FILE *restrict stream,
const char *restrict format, va_list ap);
int vdprintf(int fd,
const char *restrict format, va_list ap);
int vsprintf(char *restrict str,
const char *restrict format, va_list ap);
int vsnprintf(char *restrict str, size_t size,
const char *restrict format, va_list ap);А в glibc ещё есть asprintf и vasprintf. А ещё есть исторические *wprintf*. А, ещё в ncurses есть *printw, тоже дублированные. Функций было бы в два раза меньше, если бы аргументы передавались бы указателем на массив. Истинно говорю -- это путь к безумию.
> типа передать массив с аргументамиПередача на стеке экономичнее создания списка. Ну и кромей сей, в других языках есть такое, в джаве например, и там даже меньше телодвижений, чем с массивом, код лаконичнее и возможно чуток эффективнее.
> Передача на стеке экономичнее создания списка.Не список, а массив. И никто не мешает тебе этот массив создать на стеке: если ты заполняешь эллипсис до компиляции, то в компайл-тайме уже известно количество аргументов, размер массива известен. Создать его на стеке -- элементарно.
> Не список, а массивМассив каких типов нужно создать, чтобы передать int32, int64, float и char[]? Это ж придётся где-то отдельно под каждый элемент выделить память, а потом создать массив из ссылок? Костыль.
>> Не список, а массив
> Массив каких типов нужно создать, чтобы передать int32, int64, float и char[]?
> Это ж придётся где-то отдельно под каждый элемент выделить память, а
> потом создать массив из ссылок? Костыль.А, ну да. Ты прав. Я когда тот пост писал, у меня к концу execl попутался в голове с printf'ом. В printf'е как массивом не удастся выкрутиться, потому что аргументы разнотипны, как ты и говоришь. То есть весь тот мой аргумент, скорее про execl.
Эллипсис как раз создаёт на стеке структуру, которая как бы массив, но с разнотипными элементами. И вот это как раз костыль. Если ты запиливаешь в язык такую возможность, то запили её как следует. Возьми и дай возможностей такую структуру создавать, дай методов для работы с ней, типа добавления элемента в конец или перечисления этих элементов. Так, чтобы результат можно было бы использовать везде, где это нужно, и так как это нужно: например создать такую структуру на куче, или внутри другой структуры. Но тут у Ритчи возникла сложность: у него на уме был ровно один use-case для эллипсиса -- printf. Но невозможно с одного use-case'а сделать грамотное обобщение и запилить вменяемый API под это. Поэтому он, будучи грамотным инженером, запилил костылик, который умеет ровно то, что нужно ему. При этом, способы работы с va_list вовсе не были стандартизованы хрен его знает сколько времени. Я не знаю, как там Ритчи с этим справлялся, не удивлюсь, если он научил компилятор складывать произвольное количество аргументов на стек, а извлекал их оттуда ассемблерными вставками.
Но есть же другой способ -- макроязык. Пускай программист пилит такие костыли, какие ему угодно. Зачем костыли совать в спецификацию языка? Костыли сложно сопровождать, но когда ты выкидываешь их в библиотеку, то когда они тебе начнут мешать, ты сможешь взять и выкинуть. А пользователи этих костылей, если им так надо, будут иметь выбор -- либо переписать свой код, либо подобрать выкинутые костыли, собрать их в отдельную библиотеку и продолжить ими пользоваться. И если мы гипотетически предположим выкидывание println! из rust'ового std, то это приведёт лишь к появлению на crates.io крейта println. Если мы попробуем выкинуть эллипсис из C, то поднимется такой вой, что... ненене, пускай этот костыль лучше будет вечным.
> Например когда и зачем? Ты можешь привести последнюю функцию такого рода, которую
> ты писал? Я по-моему ничего не писал с эллипсисом, кроме обёрток над printf.ну, если Вы это не делали, не значит, что этого не делает никто. В моих трёх самописных библиотеках, которые активно используются в моих проектах вполне себе имеются функции с переменным числом параметров, которые не являются при этом чем-то, аналогичным printf(). Одна - это функция проверки пути в XML DOM, вторая - функция установки значения макроса в макробиблиотеке, третья - обобщённый поиск сведений по специфичной базе сведений.
> А ещё есть исторические *wprintf*.
не совсем, это *printf*() работающий с wchar_t.
>> Например когда и зачем? Ты можешь привести последнюю функцию такого рода, которую
>> ты писал? Я по-моему ничего не писал с эллипсисом, кроме обёрток над printf.
> ну, если Вы это не делали, не значит, что этого не делает
> никто.Да, я понимаю, поэтому и спрашиваю: "как ты используешь эллипсис".
> Одна - это функция проверки пути в XML DOM,
Это в смысле элементы пути передаются отдельными аргументами? Если так, то в чём была мотивация использовать эллипсис, если эллипсис ограничивает длину пути, который возможно передать: если в коде вызова такой функции три аргумента-элемента пути, значит она проверит путь длиной в три элемента. То есть длина проверяемого пути должна быть известна на этапе компиляции. Это ограничение никак не мешало? Его при этом легко снять, передавая массив элементов пути:
int check_path(size_t length, DOMElement path[]);
Или я не правильно понял, в чём собственно идея эллипсиса в такой функции? Если так, то в чём?
> вторая - функция установки значения макроса в макробиблиотеке,
Непонятно совершенно. Что значит "установка значения макроса"? Что такое "макробиблиотека"? Какое это отношение имеет к эллипсису?
> третья - обобщённый поиск сведений по специфичной базе сведений.
А тут при чём эллипсис?
Видишь в чём фишка: я уверен, что Ритчи совершил ошибку добавляя эллипсис в C. И я сильно сомневаюсь, что кто-то может придумать применения эллипсису, которые будут лучше, чем другие способы проектирования API. И более того, я уверен, что все кто думает иначе, просто не понимают как надо писать программы на C. Поэтому когда ты заявляешь "я использую эллипсис", я делаю вывод, что ты не умеешь писать на C. Именно поэтому мой вопрос не о том, как часто ты используешь эллипсис, а о том, как ты его используешь: в конце-концов я могу ошибаться в отношении эллипсиса, и мне было бы интересно пофиксить свою ошибку. Но для этого мне нужен вполне реальный конкретный пример, в котором эллипсис будет действительно лучше всех остальных способов. Если тебе интересно в этом поучаствовать, ты можешь сочинить пример, или позаимствовать из чужого кода -- я не против. Но это должен быть реальный пример. Лучше конечно несколько, чтобы можно было бы оценить частоту того, как часто такое может быть нужно.
>[оверквотинг удален]
>> Одна - это функция проверки пути в XML DOM,
> Это в смысле элементы пути передаются отдельными аргументами? Если так, то в
> чём была мотивация использовать эллипсис, если эллипсис ограничивает длину пути, который
> возможно передать: если в коде вызова такой функции три аргумента-элемента пути,
> значит она проверит путь длиной в три элемента. То есть длина
> проверяемого пути должна быть известна на этапе компиляции. Это ограничение никак
> не мешало? Его при этом легко снять, передавая массив элементов пути:
> int check_path(size_t length, DOMElement path[]);
> Или я не правильно понял, в чём собственно идея эллипсиса в такой
> функции? Если так, то в чём?интерфейс:
int xml_check_path(struct xml_node* xr, struct xml_node** xn, unsigned int nt, ...);вызов:
if (xml_check_path(x.x_tree, &xr, 3, "root", "tpl", "config") != 3)Да, ничто не мешало сделать:
int xml_check_path(struct xml_node* xr, struct xml_node** xn, unsigned int nt, char* attr[]);
и вызывать:
char* attrs[] = { "root", "tpl", "config" };
...if (xml_check_path(x.x_tree, &xr, sizeof(attrs) / sizeof(attrs[0]), attrs) != 3)
но согласитесь, код в таком случае не такой наглядный. В варианте с ... принципе можно было и без nt обойтись, а последним передавать NULL.
>> вторая - функция установки значения макроса в макробиблиотеке,
> Непонятно совершенно. Что значит "установка значения макроса"? Что такое "макробиблиотека"?
> Какое это отношение имеет к эллипсису?Есть библиотека, реализующая собственный макроязык. В частности у неё есть API:
int macro_set(MACRO m, const char* macro, int lmacro, unsigned int flags, ...);
Макросы бывают разных типов (строковые, целочисленные, с плавающей запятой).
>> третья - обобщённый поиск сведений по специфичной базе сведений.
> А тут при чём эллипсис?При том, что есть одна функция поиска по такой базе (это не СУБД, а просто набор сведений о блоках, каналах, датчиках с определённой иерархией):
int pod2_GetInfoBy(CONF2 h,
struct pod_block* InfoConfigTypeBlockV,
struct pod_channel* InfoConfigChannelV,
struct pod_gauge* InfoConfigGaugeV,
unsigned int field, ... );и куча удобных обёрток:
#define pod2_GetBlockInfoByTypeBlk2(h, tb, ib) \
pod2_GetInfoBy2((h), (ib), NULL, NULL, 1, (tb))#define pod2_GetBlockInfoByCodTypeBlk2(h, cb, ib) \
pod2_GetInfoBy2((h), (ib), NULL, NULL, 2, (unsigned int)(cb))#define pod2_GetBlockInfoByTypeBlkTypePSO2(h, tb, tp, ib) \
pod2_GetInfoBy2((h), (ib), NULL, NULL, 5, (tp), (tb))#define pod2_GetBlockInfoByCodTypeBlkTypePSO2(h, cb, tp, ib) \
pod2_GetInfoBy2((h), (ib), NULL, NULL, 6, (tp), (unsigned int)(cb))#define pod2_GetBlockInfoByTypePSO2(h, tp, ib) \
pod2_GetInfoBy2((h), (ib), NULL, NULL, 4, (tp))>[оверквотинг удален]
> использую эллипсис", я делаю вывод, что ты не умеешь писать на
> C. Именно поэтому мой вопрос не о том, как часто ты
> используешь эллипсис, а о том, как ты его используешь: в конце-концов
> я могу ошибаться в отношении эллипсиса, и мне было бы интересно
> пофиксить свою ошибку. Но для этого мне нужен вполне реальный конкретный
> пример, в котором эллипсис будет действительно лучше всех остальных способов. Если
> тебе интересно в этом поучаствовать, ты можешь сочинить пример, или позаимствовать
> из чужого кода -- я не против. Но это должен быть
> реальный пример. Лучше конечно несколько, чтобы можно было бы оценить частоту
> того, как часто такое может быть нужно.Естественно, можно и без "...", так и без многих вещей можно жить и заменять их каким-либо другими, которые есть.
> Естественно, можно и без "...", так и без многих вещей можно жить
> и заменять их каким-либо другими, которые есть.Суть в том, что использование эллипсиса во всех этих случаях имеет существенные недостатки, а вот преимущества сомнительны, если вообще есть.
Тут, насколько я вижу, эллипсис создаёт ненужных ограничений, в том смысле что мы при вызове должны знать статически, что именно передаётся и в каком количестве, но это никак не помогает вызываемой функции знать статически чего и сколько ей передали, соответственно все надежды на какую-либо оптимизацию основанную на этом идут прахом. При этом, совершенно определённо, эллипсис отменяет проверку типов аргументов во всех случаях. С xml_check_path, например, ты хочешь, чтобы &rest аргументы были бы типа char*, но xml_check_path с радостью сожрёт всё что угодно. С последним примером, мне вообще непонятно, зачем всё это, если всё равно ты пишешь обёртки: сделай обёртки инлайн-функциями, которые соберут массив из аргументов и присунут его в pod2_GetInfoBy. И её тоже сделай inline-функцией, если это возможно, тогда компилятор и от массива избавится, если он тебя напрягает. Но заметь: все типы каждого аргумента будут чётко и строго проверяться.
А наглядность кода -- там можно выкрутиться и без эллипсиса:
#define ATTRS(...) ((char*[]){__VA_ARGS__, NULL})
xml_check_path(чёта-там, ATTRS("one", "two", "three"));Опять же: типы всех аргументов будут проверяться статически, только что терминировано нулём, что дальше потребует именно последовательной работы с аргументами. Можно xml_check_path сделать макросом, и передавать массив с длиной его, но я не знаю хорошего способа посчитать количество элементов __VA_ARGS__, возможно придётся дважды из них делать массив -- один раз, чтобы передать указатель на него, второй раз чтобы посчитать его размер sizeof'ом. Да и в конце-концов, твой "наглядный код", всё равно явным образом указывает количество, так что, если писать:
xml_check_path(чёта-там, 3, ATTRS("one", "two", "three"));
то в сравнении с твоим это хуже только тем, что добавляется ATTRS.
> А наглядность кода -- там можно выкрутиться и без эллипсиса:
> #define ATTRS(...) ((char*[]){__VA_ARGS__, NULL})
> xml_check_path(чёта-там, ATTRS("one", "two", "three"));да, одна проблема, что используется C89 в варианте от Microsoft, в котором нет __VA_ARGS__ и много чего ещё.
>> А наглядность кода -- там можно выкрутиться и без эллипсиса:
>> #define ATTRS(...) ((char*[]){__VA_ARGS__, NULL})
>> xml_check_path(чёта-там, ATTRS("one", "two", "three"));
> да, одна проблема, что используется C89 в варианте от Microsoft, в котором
> нет __VA_ARGS__ и много чего ещё.Ну и кто тут ССЗБ?
>>> А наглядность кода -- там можно выкрутиться и без эллипсиса:
>>> #define ATTRS(...) ((char*[]){__VA_ARGS__, NULL})
>>> xml_check_path(чёта-там, ATTRS("one", "two", "three"));
>> да, одна проблема, что используется C89 в варианте от Microsoft, в котором
>> нет __VA_ARGS__ и много чего ещё.
> Ну и кто тут ССЗБ?К сожалению такая область деятельности, в которой приходится сопровождать аппаратное и программное обеспечение по 20+ лет.
Это не меняет того, что эллипсис тебе нужен только потому, что ты пользуешься устаревшим компилятором, в котором эллипсис был запилен костылём, потому что разработчики языка не знали других путей.
"person = get_person()", но это не значит, что этот код реально потом останется после раскрытия макроса, потому что макрос может паттерн-матчингом сопоставлять(!!!!!!!!!!!!!!!!!!!!!!)
Вот именно об этом уровне костылинга и речь.
Мало того синтаксис неочевидный сам по себе, так ещё и вот это.
Ты что, наркоман?
у тебя есть 3 варианта:
- просто {}
- {N}, где N - порядковый номер аргумента чтобы переиспользовать их в строке
- {string_id}, где string_id - named argument
Все просто и логично.Раньше named argument можно было создавать только внутри print!
Сейчас добавили возможность использовать внешнюю переменную как named argument (https://github.com/rust-lang/rfcs/pull/2795)
В примере ! у "{person}!" это вообще часть строки, оно никаким боком не относится к макросу.Читайте маны, если не понятно https://doc.rust-lang.org/rust-by-example/hello/print.html
Ещё один не осиливший. Хотя нет, почти осилил."Раньше named argument можно было создавать только внутри print!"
Вот именно об этом и речь - какой уровень костылинга должен иметься, чтобы вот специально в print! засунуть такой синтаксис?
То, что поправили - понятно, видимо единицы адекватных среди пилителей этого добра имеются таки.
До добавления этой штуки было только такое:format!("{}, {}, {}", "a", "b", "c")
// Либо с явным указанием позиций аргументов
format!("{1}, {2}, {3}", "a", "b", "c")В случае если форматированная строка большая - то это было неудобно и запутанно, однако инфраструктура для макросов не позволяла реализовать полноценный захват из внешнего контекста (Не было нормальной гигиены для proc macro), поэтому передачу именованных аргументов сделали явной, и на месте:
format!("{a}, {b}, {c}", a = "a", b = "b", c = "c")
Теперь же реализована возможность неявно захватывать внешние переменные
let a = "a";
format!("{a}");Однако не всегда нам нужны такие переменные, если мы собираемся использовать лишь в макросе форматирования, поэтому во многих случаях остаётся полезен синтаксис со внутренней передачей именованных аргументов, нововведение помогает лишь в тех случаях, когда раньше приходилось писать a = a, b = b, c = c
> format!("{1}, {2}, {3}", "a", "b", "c")только, как я понимаю, индексация начинается с нуля
>> format!("{1}, {2}, {3}", "a", "b", "c")
> только, как я понимаю, индексация начинается с нуляДа, опечатался)
> Вот именно об этом уровне костылинга и речь.Макроязык, по-определению, костыль, подпирающий недостатки синтаксиса. Ну, точнее, нехватку синтаксиса для очень специальных случаев, которыми не хочется уродовать логичность синтаксиса языка. Макроязык -- это даже специальный инструмент для вытачивания таких костылей. Не разработчики компилятора заботливо выточили тебе костыль, который в некоторых специальных случаях тебе поможет, в других случаях будет не совсем то, что нужно, а в третьих -- совсем не то, что нужно, а разработчики компилятора дали в руки инструмент, чтобы ты сам себе выпиливал таких костылей, под любые свои специальные случаи.
Бггг, спасибо, ребята, я уж лучше на что-нибудь менее костыльное посмотрю.
> Бггг, спасибо, ребята, я уж лучше на что-нибудь менее костыльное посмотрю.Такое ощущение, что я тебя уговариваю посмотреть на rust. Ты сам зашёл в новость, и сам смотрел на него, более того ещё и вопросы начал задавать, чтобы посмотреть повнимательнее. А теперь ведёшь себя так, будто тебя кто-то уговаривал.
Лавры log4j не дают покоя.
>> разворачивающиеся в компайлтайме макросы
> Лавры log4j не дают покоя.Какой занятный ламеризм.
Лёньке ещё не предлагали переписать systemd на Rust?
Он пишет свой systemd-rustd, чтобы переписывать systemd на rust
Скорее rust перепишут с использованием systemd
Не. Сейчас модно переписывать на wasm и запускать инсталятор в node.js
И все это запускать через snap, который жестко зависит от systemd.
Написать эмулятор systemd на node.js
И запускать на виртуальной машине внутри браузера.
зачем? systemd и так идеален
чтобы он окончательно схлопнулся под весом возросшей идеальности.
На опеннете в параллельном треде предложили, запость клич в твиттере или где там синеволосые пони обитают с вафелями лапкиными.
Здесь на opennet.ru предлагали.
Вряд ли, а вот добавить в systemd web ui на nodejs - идея хорошая. Не отключаемый естесственно
Дошутишься, сделают
Какая то смесь басика и си. Так глядишь и скоро круг замкнется и вернемся мы к басику, в который все в свое время плевались.
На самом деле тот же visual basic намного стройнее вот этого вот костылеподелия.
я потолок белил
Погодите ка, но visual basic тоже памятебезопасен. Зачем тогда нужен раст?
васик и безопасность ?
Могу сказать, почему VB не нужен - неприемлемо низкая скорость вычислений.
Различаем проблемы языка и реализации
Ты ебобо чтоли?У DotNet языков примерно одинаковая скорость исполнения кода на одной и той же своей виртуальной машине. Хоть VB.NET, хоть C#, хоть IronPython, разница для схожих конструкций будет очень незначительная, если вообще будет.
Одно время во всяких рейтингах Visual Basic был язык топ-3 в мире.
Только и Basic и C и Pascal сами по себе во всём лучше Rust. Вот кстати если бы Pascal вышел бы СЕЙЧАС, он бы запросто реально мог претендовать на место безопасного и простого языка для работяг. В нём в отличие от лицемерного Rust даже UB нет by design. Я неиронично скорее возжелаю возрождения Pascal, чем Rust. Если уж на то пошло, то можно взять Оберон, допилить ему асинхронность и многопоток, доработать правила, связанные с областью видимости и УЖЕ получится язык лучше и проще для практического применения, чем Rust который только и делает, что вечно куда-то "собирается".
> во всём лучше Rust.
> в отличие от лицемерного Rust
> чем Rust который только и делает, что вечно куда-то "собирается".Какой оналитический онализ ...
> даже UB нет by design.
Ну-ну.
% cat hello.pas
program Hello;
var res:word;
inp:integer;
begin
readLn(inp);
res := 65534 + inp;
writeln (res);
end.% fpc -vw -Co hello.pas
...
Compiling hello.pas
Linking hello
8 lines compiled, 0.3 sec
./hello
1
65535
./hello
2
0
Во-первых пример с переполнением не является UB в Pascal, об этом ПРЯМО УКАЗАНО В СТАНДАРТЕ размером менее, чем в 100 страниц в разделе правил целочисленной арифметики. Так что ты пойман за руку как дешёвка!
Во-вторых - и это лучшее что ты мог придумать? Классический пример с integer overflow? Жалкое зрелище. Если это была единственная проблема Pascal, то приведённый нелепый пример скорее наоборот аргумент В ЕГО ПОЛЬЗУ.
> Во-первых пример с переполнением не является UB в Pascal, об этом ПРЯМО
> УКАЗАНО В СТАНДАРТЕ размером менее, чем в 100 страниц в разделе правил целочисленной арифметики.Какой из двух-то, Экспертус Опеннета?
Ссылка на стандарт (впрочем, ISO 7185 у меня есть) плюс цитата где? Или как обычно "читал давно и не глазами, но вы все равно все врети!"?
Заодно расскажи поподробнее о присвоении излишне большого результате ариф. операции поддиапазону (subrange), а то ж тоже - классический пример UB для паскаля.> Так что ты пойман за руку как дешёвка!
Еще один "аргументативный аргумент".
> Во-вторых - и это лучшее что ты мог придумать? Классический пример с integer overflow? Жалкое зрелище.
> И вообще, ЭТО НИСЧИТАИЦА!НИСЧИТАИЦА Я СКАЗАЛ!Какой унылый юлеж и отмазки. Жалкое зрелище.
a) All integral values in the closed interval from maxint to +maxint shall be values of the integer-type.
b) Any monadic operation performed on an integer value in this interval shall be correctly performed according to the mathematical rules for integer arithmetic.
c) Any dyadic integer operation on two integer values in this same interval shall be correctly performed according to the mathematical rules for integer arithmetic, provided that the result is also in this interval.
d) Any relational operation on two integer values in this same interval shall be correctly performed according to the mathematical rules for integer arithmetic.Всего доброго. Можете к психиатру сходить на досуге.
> Во-первых пример с переполнением не является UB в Pascal, об этом ПРЯМО УКАЗАНО В СТАНДАРТЕ...
> a) All integral values in the closed interval from maxint to +maxint shall be values of the integer-type.
> b) Any monadic operation performed on an integer value in this interval
> shall be correctly performed according to the mathematical rules for integer arithmetic.Monadic - это об унарных операторах, так что мимо.
> c) Any dyadic integer operation on two integer values in this same
> interval shall be correctly performed according to the mathematical rules for
> integer arithmetic, provided that the result is also in this interval.Т.е. ты с английским не дружишь или как обычно - даже свою копипасту не читал?
> d) Any relational operation on two integer values in this same interval
> shall be correctly performed according to the mathematical rules for integer
> arithmetic.А relational operation - это о сравнении, если что.
В общем, я так понимаю, что накопипастил для "солидности" побольше, но прочитать не удосужился?> Всего доброго. Можете к психиатру сходить на досуге.
Еще одна унылая попытка спрыга.
В общем, как и ожидалось - никаких аргументов, лишь вопли, сопли, спрыги, попукивания и прочая унылая демагогия.
Это скорее вы без понятия что такое integer arithmetic, это как раз ВЫ разводите демагогию и вырываете слова из контекста, сами при этом не привели ни единого аргумента. Для ASM переполнение регистра/ячейки памяти обычное дело и оно входит в стандартный комплект целочисленной арифметики, которая кстати в свою очередь описана в других стандартах. Pascal в свою очередь опирается на правила целочисленной арифметики, они строго регламентированы и правила переполнения здесь не баг, а фича. Почитайте Кнута на эту тему отвлекаясь вообще от языков и поштудируйте CS. И вопли и сопли здесь только у вас, вы вообще не в адеквате. Может и вовсе коробит от того что древний и уже умерший Pascal по дизайну превосходит Rust. Если целочисленное переполнение вызывает у вас проблемы и приступы необоснованной агрессии, вам вообще нечего делать в индустрии. Если уж на то пошло, то в C++ это считается UB, но на практике все значимые компиляторы работают по принципу целочисленной арифметики. Можно регламентировать это явно и тогда это перестанет быть UB, круто да? А ещё вы явно не различаете undefined behavior и unspecified behavior, но это уже мелочи в вашем случае.
> во всём лучше Rust.
> в отличие от лицемерного Rust
> чем Rust который только и делает, что вечно куда-то "собирается".-
> Во-вторых - и это лучшее что ты мог придумать? Классический пример с integer overflow? Жалкое зрелище.
> Это скорее вы без понятия что такое integer arithmetic, это как раз
> ВЫ разводите демагогию и вырываете слова из контекста, сами при этом
> не привели ни единого аргумента.Самокри^W Аргументация аж и прет, ага
> Для ASM переполнение регистра/ячейки памяти обычное
> дело и оно входит в стандартный комплект целочисленной арифметики, которая кстати в свою очередь описана в других стандартах.Это штеудские ADD with overflow / Add with Saturation / Add with Carry?
А о 1-complement (PDP или актуальные на момент написания паскалевского стандарта UNIVAC), 2-complement - Опеннетные Экспертусы не слышали ...
В Си оно осталось без определения совсем не по "глупости".В принципе, после "переполнения ячейки памяти" далее можно не читать - уровень бреда начинает зашкаливать.
> Pascal в свою очередь опирается на правила целочисленной арифметики, они строго регламентированы и правила переполнения здесь не баг, а фича. Почитайте Кнута на эту тему отвлекаясь вообще от языков и поштудируйте CS.
Уныленькая отмазочка с повторным фейлом. "Знатокам" на заметку: в тематическом CS, btw. практически _всегда_ упоминают и уточняют, какие именно правила подразумевает автор(ы).
> И вопли и сопли здесь
> только у вас, вы вообще не в адеквате. Может и вовсе
> коробит от того что древний и уже умерший Pascal по дизайнуЭтот Знаток подорв^W сломался, вносите следующего!
> Если уж на то пошло, то можно взять Оберон, допилить ему асинхронность и многопоток, доработать правила, связанные с областью видимости и УЖЕ получится язык лучше и проще для практического применения, чем Rust который только и делает, что вечно куда-то "собирается".У тебя проблемы с логикой. Ты готов ждать (неизвестно сколько), пока допилят Оберон (ничего против него не имею, если что), но не готов ждать, пока совершенствуют Раст, хотя у последнего есть и асинхронность, и многопоток, и продвинутые работающие правила с областью видимости. Какой-то поток сознания, в общем.
Внимание вопрос: чего тебе не хватает на самом деле?
Вообще-то мне как раз ВСЕГО хватает и БЕЗ Rust :). Оберон вообще никогда не допилят, здесь скорее важна сама концепция. Все что может предложить Rust в том или ином виде существует в C++ уже давно. При желании, используя move-семантику и умные указатели можно даже писать в стиле Rust на плюсах. Rust идейно не привнёс в индустрию ВООБЩЕ НИЧЕГО НОВОГО. Предыдущая "революция", когда активно форсились функциональные языки и LISP, мне нравилась больше. Там хоть в обсуждении были не PR-технологи.
>Все что может предложить Rust в том или ином виде существует в C++ уже давноВообще-то нет. Модулей в плюсах не было, недавно только выкатили. Времени жизни тоже - до сих пор пилят. Стандартной инфраструктуры до сих пор нет. Раст исповедует композицию, плюсы - ООП. Но тебе ведь просто выговориться надо было, тебя факты не интересуют.
>Rust идейно не привнёс в индустрию ВООБЩЕ НИЧЕГО НОВОГО
То же можно сказать о C++. Но ты же им пользуешься,тем не менее.
>>Все что может предложить Rust в том или ином виде существует в C++ уже давно..
> выговориться надо было, тебя факты не интересуют.Меня как раз интересуют только факты, более того я прагматик, с удовольствием приму Rust если он когда-нибудь будет реально удобен и производителей (в плане скорости разработки). Только вот это так не работает, то что вы перечислили в несколько ином виде реализовано в ML (oCaml, F#), но и они не очень то взлетели, хотя по дизайну они лучше и прозрачнее.
>>Rust идейно не привнёс в индустрию ВООБЩЕ НИЧЕГО НОВОГО
> То же можно сказать о C++. Но ты же им пользуешься,тем не
> менее.Кстати C++ всё же кое-что внёс, а именно ссылочный тип (не указатель). (Это не тоже самое что ссылки на объекты в true OOP).
В остальном C++ с переменным успехом дёргает идеи других языков, НО чёрт возьми, C++ сам уже старый язык. Rust же не внося ничего принципиально нового обеспечивает иллюзию безопасности. Ну давайте ещё 10 лет подождём. Дискуссии то за предыдущие 10 лет не особо поменялись. Вот серьёзно, лучше бы LISP в очередной раз откопали, он по крайней мере идейный, макросы и метапрограммирование вообще лучшее.
> с удовольствием приму Rust если он когда-нибудь будет реально удобен и производителей (в плане скорости разработки)Единственная проблема у Rust со скоростью разработки - это жалобы на медленную компиляцию. Но это решаемо со временем.
> Только вот это так не работает
Что, это? Rust уже используют сугубо в прагматичных целях. Кто? Да спонсоры проекта же: Google, Microsoft, Amazon, Huawei, Mozilla и многие другие.
> в несколько ином виде реализовано в ML (oCaml, F#), но и они не очень то взлетели, хотя по дизайну они лучше и прозрачнее.
Надо анализировать, почему не взлетели. То ли мало пиара было, то ли всё-таки какие-то существенные недостатки есть. Так или иначе, аналогии подобным образом строить - некорректно. Типа, раз такие-то фичи были в языке A, и он не взлетел, то язык B, в котором такие же фичи, только несколько иначе реализованные, тоже не взлетит.
> Rust же не внося ничего принципиально нового обеспечивает иллюзию безопасности.
Опять двадцать пять. Как это не внося? Очень даже внося, если сравнивать его с языками своей ниши. Таких в системном программировании ещё не было. То, что вы перечисляли до сих пор, к системному программированию не имело отношения.
> обеспечивает иллюзию безопасностиПочему иллюзию? Если писать код с нуля на Rust, не используя сторонние библиотеки на других языках, то эта безопасность (работы с памятью) вполне себе реальная. Кроме того, в Rust практически нет UB, чего не скажешь о плюсах или C.
В Pascal вообще нет UB (демагог в другой ветке выдавил из себя только integer overflow, который допускается стандартом). При этом он проще, а косяки выходят из его "академичности" и нацеленности на обучение (в исходном варианте вообще все переменные глобальные). А иллюзию хотя бы потому, что Rust создаёт впечатление контроля над памятью, а в реальности на нём не так уж и сложно допустить утечку. И из-за хитрой семантики владения отлавливать их сложнее. Rust гарантирует разве что безопасность в отношении работы с данными, но эти проблемы уже давно решены в C. Более того само понимание работы с данными работает на повышение квалификации разработчика.И кстати Rust на далёкую перспективу не станет системным языком, по двум причинам. Во-первых на нём неудобно работать с памятью, а если везде использовать unsafe, то написание кода превратится в переусложнённую на ровном месте аналогию с C. Вторая причина более фундаментальная: rust разрушает восприятие железа и в систмном программировании это решающая роль. ANSI C же в свою очередь вопроизводит копию фоннеймановской архитектуры и разработка на нём очень органична.
Единственная удачная с точки зрения computer science альтернатива - это LISP-машина, поэтому я считаю, что LISP во-первых вернётся, а во-вторых его невозможно убить, потому что это идея, а не язык.
По поводу ML и почему они не взлетели. Пиара действительно мало, но это второстепенное. Разработчикам прагматикам часто хочется чтобы их язык мог без труда делать что угодно. Поэтому C# и Java несмотря на их банальность всегда уже будут на плаву. Автор языка V кстати поступил очень грамотно в своём творении обеспечив максимально бесшовное взаимодействие с C. Страуструп, которого к слову есть за что покритиковать также уловил суть и также добивался полной совместимости с C без лишних телодвижений. Говоря о функиональщине получается конфликт парадигм и даже если его можно разрешить, это всё слишком усложняет. Rust кстати рискует повторить те же ошибки, он УЖЕ их допускает, учитывая что на него тратят тонны средств, его продвигают, а реальных проектов как не было так и нет. Whatsapp на erlang написан, популярный язык? Да не очень то. Упомянутый аутичный V во всю используется его автором, и довольно успешно (см. проект Volt). у Rust же проблем нет только в его рекламе, а если это не так, то будем ждать реальных проектов. Но скорее дождёмся уже третьего прешествия LISP.
Вот что пишется на Rust прямо сейчас: https://github.com/topics/rust?l=rust&o=desc&s=stars
> В Pascal вообще нет UBА вот это всё есть (цитата Анонима)?
"гугление показывает что в нем возможны use after free, double free, nullable pointers, memory aliasing, потеря константности за ссылкой. Дальше не смотрел."
А в Rust этого всего нет. Ну и кто тут в дамках?
> в реальности на нём не так уж и сложно допустить утечку
Называется, слышал звон, да не знаю, где он. В самой книжке по Rust об этом целая глава (есть и на русском, если по-английски сложно). Утечка памяти - не есть фатальная ошибка при программировании, в отличие от двойного освобождения или обращения к неинициализированному участку.
> Во-первых на нём неудобно работать с памятью
Умные указатели Box, Rc, Refcell не осилил? Что там сложного и неудобного?
> rust разрушает восприятие железа. ANSI C же в свою очередь вопроизводит копию фоннеймановской архитектуры
Что за бред?
> computer science альтернатива - это LISP-машина
На LISP-машине будешь драйверы писать?
> Поэтому C# и Java несмотря на их банальность всегда уже будут на плаву.
Java увядает (см. индекс Tiobe). Что значит "банальность", кстати, в применении к ЯП?
> Автор языка V кстати поступил очень грамотно в своём творении обеспечив максимально бесшовное взаимодействие с C
У Rust с этим нет проблем от слова "совсем".
> у Rust же проблем нет только в его рекламе
Не услышал пока ни одной внятно сформулированной проблемы у Rust. Сплошной поток сознания.
>В нём в отличие от лицемерного Rust даже UB нет by design.В Pascal не ногой, но гугление показывает что в нем возможны use after free, double free, nullable pointers, memory aliasing, потеря константности за ссылкой.
Дальше не смотрел.
Паскаль сейчас это "одноглазый змей Питон"(хотя вообще это Common-Lisp сделаный через одно место и на 30 лет позже).
Только у питона кастрация в виде GIL(всё плохо с многопоточностью), прилеплено дофига костылей на си и прочем(шоб быстрее), ну и как "для обучения" он никакой.
Ну и пробелы, тысяча их. Они не решают того чем их обосновывают(код один фиг может быть не читаем и уродск), но за то проблемы в виде "чото гдето уехало", "в табы вкрался пробел(или наоборот)"(и гадай лезя на сервер по SSH таб жать или пробел).
Ну и нет помпиляции.
Стандартный питон он сволочь такая по сути интерпретатор.На Паскале делали коммерческое которое можно было дать конечному пользователю и не бояться что изменит.
Вот у нас в ВУЗике были программки для тестирования по матлогике и прочим графам.
С Питоном уже не прокатило бы, будь они на питоне - их бы еще студенты учившиеся до нас модифицировали так что-бы результат всегда был верен(по нажатию комбинации клавиш).
Да, можно на питоне городить серверную часть и клиент, но зачем(плюс эти работали вне зависимости от того работает или упала сеть\сервак).
> без использования ... runtime
> (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)Определитесь уже!
они уже 15 лет не могут самоопределиться.
Они давно уже определились. Но люди с невысоким уровнем когнитивных способностей этого понять не в состоянии, увы.
>> без использования ... runtime
>> (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)
> Определитесь уже!Вы тоже, а то с такой "логикой" рантайм и в freestanding C есть.
А по ссылке, указанной в новости, сходить не смог? Там всё на простом английском буквально на пальцах объясняют. Помочь перевести или сам справишься?
>Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation.Не под покровительством, а под контролем.
Или вообще, "развиваемого некоммерческой организации Rust Foundation".
Кстати, от чего она независима?
> Кстати, от чего она независима?да прост
она от опен-нета независима
она не знает, что о ней тут думают
Она не знает - я знаю.
От мозиллы. Простыми словами Мозилла больше не платит зарплату этим фанатикам. И исключительно потому что они сами облажались.
https://foundation.rust-lang.org/members/
> "Founding platinum: mozilla"
> От мозиллы. Простыми словами Мозилла больше не платит зарплату этим фанатикам. И
> исключительно потому что они сами облажались.А точно они, а не ананимные экспердусы?
Не ананимный не экспердус, а можешь в конкретных цифрах, сколько конкретно платят? А не списочек с неясными критериями включения, может там за прошлые заслуги.
> Не ананимный не экспердус, аТочно-точно? Ведь по ссылке пройти не осилил:
-
Platinum 300,000 USD
Gold 150,000 USD
Ну ты малайца, ссылку нашел!
То есть деньги есть, люди есть, а язык все равно стагнирует. Все с ним ясно.
150 000 долларов это зарплата одного программиста в год. Проспись уже наконец. Хватит, твой хруст обoсрaлся.
Забавно, как Воены АнтиРастового Сопротивления воюют друг с другом :)> 150 000 долларов это зарплата одного программиста в год. Проспись уже наконец.
Это минимальная сумма для зачисления в ранг. 5 платиновых = минимально 1.5млн. Что уже хватает на 10 разрабов.
> Хватит, твой хруст обoсрaлся.
Пока что обделался тут только ты, увы.
от мозилы(и не только), но не потому что они им не платят деняг, а потому что мозила не может диктовать что этому руст фандейшену что делать. также это значит что руст фаундейшн юридически не являеся структурой аффилированной в другую структуру.
>Автоматическое управление памятью в Rust избавляет разработчика от ошибок при манипулировании указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью,Я что-то может путают, поправьте меня, но разве в расте автоматическое управление памятью?
в плюсах тоже, шабат шалом
Указатель - это табличка из ПДД. А в расте набор юникодных символов, смотри не перепутай, кутузов!
Да. Например потому, что тебе не надо явно вызывать drop, на каждое значение, компилятор сам расставит эти вызовы. Автоматически.
Оговоримся, что при желании drop можно вызвать и самому - например, если нужно где-то посередине срочно почиститься.
Тогда это полуавтоматическое.
да, окончательно название не устоялось, поскольку такого больше нигде нет
Умные указатели в плюсах?
Ну куда ты лезешь со своим "это уже 20 лет как есть в плюсах" в тему раста?
Ты еще скажи что раст не нужен.
20 лет назад (C++98 ) создали уродский std::auto_ptr, который оказался таким говеным, что даже наяривающим на обратную совместимость плюсовикам пришлось его вначале депрекейтнуть (C++11), а потому выпилить вообще (C++17).
Нормальные smart pointers появились только в С++11. Так что не 20 лет.
А перешли они туда из boost, так что все же 20
Здравствуй, неосилятор.auto_ptr никогда не был уродским - ни когда его только придумали, ни когда его решили объявить устаревшим ввиду более эффективного unique_ptr (благодаря move семантике).
Нет, оно немного по другому сделано и работает. Тебе не нужно дополнительно что-то создавать и засовывать туда переменную. На этапе компиляции рассчитываются времена жизни и вызывается деструктор.
А аналог smart pointer в Rust - это Box, Rc, Ref/RefMut/RefCell.
нет
https://en.wikipedia.org/wiki/Rust_(programming_language)#Memory_management
>Rust does not use automated garbage collection. Memory and other resources are managed through the resource acquisition is initialization convention,[57] with optional reference counting. Rust provides deterministic management of resources, with very low overhead.[58] Rust favors stack allocation of values and does not perform implicit boxing.
>Rust provides deterministic management of resourcesРаст предоставляется детерминистическое управление ресурсами.
Тут проще написано если хочешь понять, хоть и длиннее https://habr.com/ru/post/350372/Можно и так сказать - в расте реализованы афинные типы. Что это значит на практике:
let mut f = File::create("foo.txt")?;
f.write(b"some bytes")?;
drop(f); // Освободить объект f
f.write(b"some bytes")?; // Тут будет ошибка на стадии компиляции
т.е. это поведение ты получаешь для всех типов в т.ч. и пользовательских. Без проверок в рантайме, без дополнительного оверхеда, уже на стадии компиляции.f также будет освобождено если выйдет за пределы видимости:
{
let mut f = File::create("foo.txt")?;
f.write(b"some bytes")?;
} // После блока f будет освобождено
f.write(b"some bytes")?; // Тут будет ошибка на стадии компиляцииТакже нельзя например по ошибке дважды закрыть файл.
>Признак "const", определяющий возможность использования в любом контексте вместо констант,Использования чего?
Использования, например, const-функции в определении константы.
Ок статью вроде подправили. Всё равно получилось слишком сложно.
Если у местных так подгорает - значит хороший язык. Долгих лет жизни
подгорает обычно больше всего у тех, кто говорит о подгорании у других
> подгорает обычно больше всего у тех, кто говорит о подгорании у другихНакидай ему еще минусиков и повтори еще разок -- чтобы точно-точно никто не перепутал!
Подгорает тут пока что только у тебя.
>no u
Нет у тебя ты даже на английский перешел от подгорания!
> Изменено поведение структуры std::process::Command на платформе Windows, которая при выполнении команд из соображений безопасности больше не ищет исполняемые файлы в ...И ЭТО --- в язык?
Всё в традициях Python, не зря предлагали совмещать Python и Rust, вон, f-строки Python в Rust уже появились.
питоноподобный хруст ?
PythoRust же
Минусуйте-минусуйте, растоманьки :))
Под Линукс это хорошо, ибо там у процесса своя копиия переменной PATH.
А в Виндовс переменнаые PATH глобальны для системы и пользователя. Будет весело.
В винде тоже у каждого процесса тоже свой набор копий переменных окружения. Особенный только explorer.exe, чтобы после изменения системных/пользовательских значений не надо было перезагружаться-перелогиниваться, а достаточно было только перезапустить те программы, которым нужны изменения.
Не в язык, а в std. Не хочешь использовать std - не используй. Можешь даже написать #![no_std] в main.rs и сделать свою, правильную "стандартную" библиотеку.
>Дополнительно можно отметить публикацию компанией Microsoft выпуска библиотек Rust for Windows 0.30, позволяющих использовать язык Rust для разработки приложений для ОС WindowsОни вторгаются в мой дом! Вы не готовы!
>реализована возможность подстановки произвольных идентификаторов через добавление в строку выражений "{идентификатор}"C++ - нечитаемый язык, говорили они.
и тормозной. но теперь есть раст, по сравнению с которым даже плюсы вроде бы ничего так
Они создали Rust чтобы люди сильнее полюбили C++ и ценили то что имеют :peka:
Смех смехом, а со мной так и получилось. Тем более стандарт C++ не стоит на месте, заимствует полезные фичи у других языков.
Ну с развитием и стандартизацией C++ можно поспорить, ровно как и с нововведениями. Тем не менее в C++ философия становится следующей: не нравится - не используй. В итоге это "меньшее зло" худо бедно работает, в компаниях пилятся гайдлайны, которые что-то разрешают, что-то запрещают и с этим как-то живём. Rust же нелепо позаимствовал всё самое странное и неоднозначное из ML и C++, при этом они уже и сами не знают что им со всем этим делать. Я уже неиронично Pascal привожу в пример, который во всём лучше Rust, включая надёжность. О простоте и читаемости кода и вовсе говорить не приходится.
>Rust же нелепо позаимствовал всё самое странное и неоднозначное из ML и C++Например?
>>Rust же нелепо позаимствовал всё самое странное и неоднозначное из ML и C++
> Например?Семантически в rust достаточно много идей из ML. Кстати даже "модную" концепцию констант по умолчанию позаимствовали оттуда же, уж не знаю насколько это оправдано в Rust, учитывая как часто приходится видеть тонны мутабельных переменных. Вообще многим цивилизованным Растоманам лучше было бы потыкать ML, но тут правда проблема в том, что технологически более опрятный F# слишком связан с Microsoft, но из академических (а может и прагматических) интересов можно потыкать и его. В MONO он есть, под linux можно тоже поиграться. F# кстати фундаментально написан на F# (без "удобных" оговорок), первая версия его компилятора была написана на общем подбмножестве OCaml, а затем переписана на самом F#. И писать на нём можно хоть и не всё (удобно, так то язык конечно тьюринг полный), но вещи, связанные с обработкой данных - одно удовольствие. Попробуйте как-нибудь.
>Семантически в rust достаточно много идей из MLТак какие из них странные и неоднозначные всё-таки?
> уж не знаю насколько это оправдано в Rust, учитывая как часто приходится видеть тонны мутабельных переменных
Ты о нужности/ненужности той или иной фичи судишь исключительно по частоте её встречаемости в каком-то отдельно взятом куске кода? Это единственный критерий, которым ты руководствуешься? (рукалицо).
Дальнейший бред наркоманский не распарсил, сорри.
> "модную" концепцию констант по умолчанию позаимствовали оттуда же, уж не знаю насколько это
> оправдано в RustОправданно более чем, ибо язык изначально проектировался как дружественный к многопоточности. А те самые mut явно показывают что конкретные данные не могут использоваться в нескольких потоках (без атомарности). На этих принципах целые умные планировщики пишут, которые распараллеливают системы автоматически, при отсутствии конфликтующих ресурсов. Сам недавно в эту тему погружаться начал, и такая параллелизация по умолчанию выглядит очень привлекательно, особенно учитывая современные тенденции развития процессоров. В целом, писать многопоточный код в Rust довольно легко, так как компилятор тебя постоянно направляет в нужную сторону.
Да вы, батенька, знатный мазохист, я смотрю. Любить язык, у которого спецификация больше полторы тысячи страниц, и которую в принципе невозможно выучить...
> Да вы, батенька, знатный мазохист, я смотрю. Любить язык, у которого спецификация
> больше полторы тысячи страниц, и которую в принципе невозможно выучить...По-моему где-то уже это писалось, но, у Rust вообще нет спецификации. Никакой. В общем, как в анекдоте, тьфу дура, нашла чем хвалиться. (с)
Лучше никакой спецификации, чем та что не работает. https://lkml.org/lkml/2018/6/5/769
> Лучше никакой спецификации, чем та что не работает. https://lkml.org/lkml/2018/6/5/769он там так долго ругался, а потом замержил, и сказал, что ничего не поломалось.
PS: когда компиляторов Rust будет хотя-бы в 10 раз меньше, чем компиляторов C, расскажете, как это замечательно жить без стандартов.
> PS: когда компиляторов Rust будет хотя-бы в 10 раз меньше, чем компиляторов
> C, расскажете, как это замечательно жить без стандартов.Учитывая, что tcc ты современное ядро уже не соберешь - достаточно ⅕ компилятора?
>> PS: когда компиляторов Rust будет хотя-бы в 10 раз меньше, чем компиляторов
>> C, расскажете, как это замечательно жить без стандартов.
> Учитывая, что tcc ты современное ядро уже не соберешь - достаточно ⅕
> компилятора?можно даже в 3, но при чём тут ядро? Rust-ом тоже нельзя ядро собрать, выкидываем Rust как бесполезный?
>>> PS: когда компиляторов Rust будет хотя-бы в 10 раз меньше, чем компиляторов
>>> C, расскажете, как это замечательно жить без стандартов.
>> Учитывая, что tcc ты современное ядро уже не соберешь - достаточно ⅕
>> компилятора?
> можно даже в 3,Ну перечисли 3, которыми соберется ядро. Или десяток, сумеющих собрать хотя бы 70% используемого софта. Только давай без демагогии вида "этот компилятор используют в проекте X (за скобками: и более нигде, да и вообще, проект собирается только им)" - к последним, тезис о стандартах, как бы, не очень и применим.
> но при чём тут ядро?
Потому что обсуждаем ядро?
>> но при чём тут ядро?
> Потому что обсуждаем ядро?Странно, тема называлась "Выпуск языка программирования Rust 1.58", а обсуждаем ядро. А так - ядра есть не только у Linux-а, а если посчитать сколько было других (и сейчас есть), и сколько собиралось другими компиляторами (например, тот-же Watcom C/C++), то компиляторов C, которые собирали какие-нибудь ядра ОС, будет явно побольше компиляторов Rust (которых на данный момент всего один), которые собирают какие-то другие ядра ОС.
> > Лучше никакой спецификации, чем та что не работает. https://lkml.org/lkml/2018/6/5/769
> Странно, тема называлась "Выпуск языка программирования Rust 1.58", а обсуждаем ядро. А
> так - ядра есть не только у Linux-а,Ветка-то с ссылкой на lkml.
> а если посчитать сколько было других (и сейчас есть), и сколько собиралось другими компиляторами
> (например, тот-же Watcom C/C++)Еще бы Turbo C вспомнил, да и до появления стандарта С89 компиляторов тоже было больше одного.
Я в курсе, что их было больше чем 3, но вот осталось ... Aмдшный - это форк llvm+clang, у штеудского (был, мне уже долго не присылали рекламу, а сам я не интересовался) конский ценник и оптимизация только для их же процессоров. LCC тоже "был". Ну и т.д.
>>> PS: когда компиляторов Rust будет хотя-бы в 10 раз меньше, чем компиляторов
>>> C, расскажете, как это замечательно жить без стандартов.
>> Учитывая, что tcc ты современное ядро уже не соберешь - достаточно ⅕
>> компилятора?
> можно даже в 3, но при чём тут ядро? Rust-ом тоже нельзя
> ядро собрать, выкидываем Rust как бесполезный?Смотря какое ядро, если написанное на Rust то можно, почему нет? В нем настолько я помню даже x86_64-unknown-none target есть. Тот же Redox или RustyHermit вполне себе собираются.
Внезапно согласен с тем что без стандарта не будет компиляторов больше одного.С другой стороны опеннет славится тем что "зачем такое-же когда уже есть" и "распылять ресурсы на другие Х, когда можно доработать существующий.
Теперь интересно стало, зачем Microsoft писали свой С++ компилятор, когда уже был GCC?
Кстати для GCC раст прожект пишет бэкенд - https://github.com/rust-lang/rust/tree/master/compiler/rustc...
> Теперь интересно стало, зачем Microsoft писали свой С++ компилятор, когда уже был
> GCC?Наверное за тем же, зачем и создавался LLVM\Clang, не совместимость лицензии GCC с целями определенных разработчиков...
>> Да вы, батенька, знатный мазохист, я смотрю. Любить язык, у которого спецификация
>> больше полторы тысячи страниц, и которую в принципе невозможно выучить...
> По-моему где-то уже это писалось, но, у Rust вообще нет спецификации. Никакой.
> В общем, как в анекдоте, тьфу дура, нашла чем хвалиться. (с)А зачем им представлять спецификацию, если они сами занимаются разработкой тулчейна и стандартной библиотеки? Я понимаю C++, они свой компилятор/std не пишут, они представляют спеки, которых придерживаются разработчики конкретного компилятора. Но зачем спеки Rust, чтобы были?
Для луддитов так и есть. Но мы ведь знаем из истории, что прогресс победил в итоге.
>C++ - нечитаемый язык, говорили они.
> защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобожденияПаникуя на unwarp'ах. И да половина кода будет состоять из unwarp
У хейтеров так и будет, даже не сомневаюсь.
Хейтеры не пишут на расте.
> Хейтеры не пишут на расте.Мне кажется они кроме комментариев на OpenNET вообще ничего не пишут...
Что за бред ты несешь.unwrap — метод, который вызывает панику если текущий результат не является успешным. Его используют с пониманием дела.
Так же можно сказать, что если в божественной сишке везде понатыкать что-то вроде
if (errno != 0) exit(1);
То программа при ошибках будет часто завершаться. Какой плохой язык.
> unwrap — метод, который вызывает панику если текущий результат не является успешным. Его используют с пониманием дела.Если бездумный копипаст по нескольку раз в каждой строчке считать пониманием дела, то да. А так вообще-то это эпик фейл попытки заставить программиста не игнорировать ошибки.
unwrap встречается, в основном, в hello world’ах или в примерах апишек. Там понятно, что нормальной обработки ошибок не будет. В продакшн коде unwrap — редкость. Так что нытье по поводу unwrap — явный признак, что товарищ дальше википедии не ходил.В расте вообще обработка ошибок эталонная. Нет внезапных исключений, летящих непонятно откуда, нет голанговских/сишных соплей с ифами после каждого вызова функции. Язык сразу спроектирован таким образом, что обработка ошибок происходит единообразно и компилятор задолбает тебя, но потребует хоть какой-то реакции на возможные ошибки.
> unwrap встречается, в основном, в hello world’ах или в примерах апишек.https://github.com/redox-os/coreutils/search?q=unwrap&type=code Сказочники идут гулять.
>> unwrap встречается, в основном, в hello world’ах или в примерах апишек.
> https://github.com/redox-os/coreutils/search?q=unwrap&type=code Сказочники идут гулять.
> stat.rs: let meta = fs::symlink_metadata(path).unwrap();
> kill.rs: .unwrap_or_exit(1)
> dd.rs: .unwrap_or_else(Ты бы сам по этой ссылке сходил, Экспертус Опеннетный.
Я вместо него сходил.let mut file = File::open("sys:uname").unwrap();
let meta = fs::symlink_metadata(path).unwrap();
println!("File: {} -> {}", path, fs::read_link(path).unwrap().display());
let terminal_size = termion::terminal_size().unwrap().0 as usize;
let paths = env::var("PATH").unwrap();
let arg = args.next().unwrap();
stderr.write(b"error: unimplemented outside redox").unwrap();
stderr.write(b"error: unimplemented outside redox").unwrap();
let mut last_updated_filename = files.last().unwrap().0;
return match characters.next().unwrap() {
> Я вместо него сходил.Ну ты у нас знатный Эксперд, да ...
> which.rs
> let paths = env::var("PATH").unwrap();расскажи о глубоком философском смысле далее выполнять логику утилиты "which" при недоступной переменной окружения "PATH".
> stderr.write(b"error: unimplemented outside redox").unwrap();
> stderr.write(b"error: unimplemented outside redox").unwrap();... И паника будет исключительно при невозможности вывода на stderr ...
Т.е. если при выводе ошибки не сработал сам вывод об ошибке, то нужно было попытаться вывести сообщение об ошибке невозможности вывода сообщений об ошибках?"И вот так - у вас все!" (с)
>> stderr.write(b"error: unimplemented outside redox").unwrap();
>> stderr.write(b"error: unimplemented outside redox").unwrap();
> ... И паника будет исключительно при невозможности вывода на stderr ...Причем, это выдернуто из утилит df и free, где служит исключительно для вывода сообщения об отсутсвии реализации:
#[cfg(not(target_os = "redox"))]
fn main() {
use std::io::{stderr, Write};
use std::process::exit;let mut stderr = stderr();
stderr.write(b"error: unimplemented outside redox").unwrap();
exit(1);
}
Ехал unwrap через unwrap
Видит unwrap - unwrap в unwrap
unwrap unwrap unwrap(с) rust
еще expect, assert!, panic! и тд и тп.
unwarp — это что-то про выпрямление?
Не, он просто читать не умеет, так где-то что-то слышал краем уха про rust...
Лучший!
из худших
Да, более читаемый, чем BrainFuck
Не доказано.
Лудший!
Про него ещё не забыли?
Разве что старые пердуны-склеротики.
Ну как там Rust поживает? Уже обогнал COBOL в популярности?
Если даже Хаскель не смог это сделать то расту до этого далеко.
Не надо вот, постоянно натыкаюсь на пакеты на хаскеле в репе.
По хайпу это чемпион всех времен
Что-то маловато изменений и ничего в этот раз не поломали.Это из-за того, что сообщество разoсpалось с кор-тимом?
> Изменено поведение структуры std::process::Command на платформе Windowsну да, почти не поломали...
Windows никого не интересует.
Глупости. Предвзятое и даже пренебрежительное отношение к Винде - это заведомо проигрыш. Мир существует не только на серверах. Я уж молчу про 3D графику, где даже при желании *nix не всегда возможно использовать из-за того что производители железа косячат с драйверами (это плохо, но это мир в котором мы живём), хотя в последние годы ситуация стала немного получше.
Линукс это всё. Конечно, всегда можно. Если работает в венде, работает и в линуксе, у нвидии один драйвер. Каталист тоже вроде был один, но писался в странах бывших советов со всеми вытекающими. Были некоторые вопросы в специфичных кейсах, но теперь fsync в ведро приняли и не остаётся преимуществ.
Вообще-то на драйверы nVidia матерятся постоянно, на уровне пользователей потому, что они могут сломать систему при обновлении, на уровне разработчиков потому что nVidia почти всегда кладёт хрен на стандарты, все дрова закрытые, а технологии проприетарные. Радости разбираться в этом чёрном ящике просто полные штаны. У AMD появились новые неплохие драйверы, единственная их проблема в том, что они не поддерживают старое железо. На сегодняшний день AMD под Linux лучше, если речь идёт о сравнительно современных видеокартах. OpenGL кстати AMD тоже лучше поддерживает.
При обновлении вредители из корпоративной секты пару раз сломали сломали блоб, из-за этого материться на драйверы? И то сломали для рк-ядер, тоже мне трагедия. Зато как амд год не исправляла совместимость все уже забыли.Разработчики разрабатывают под инвидию и технологии нвидии. Нвидия даже помогает своими инженерами при возникновении сложностей у крупных разработчиков. Это значит, что на нвидии будет работать хорошо, а у остальных как придётся. См. историю с тесселяцией в ведьмаке и каком-то там кукурузисе, Что касается опенгл, её драйвер является главным стандартом и законодателем, продвигая все интересные расширения в общие стандарты. Та же история регулярно повторяется с вулканом.
Аргумент тоже странный. Я сейчас уже не увлекаюсь играми, но скажем серия Hitman, кстати движок пашет на OpenGL (сейчас уже скорее всего на Вулкан переехал, но это не точно). Они разрабатывали используя оборудование и средства AMD, более того у AMD сейчас дофига удобных фишек для разработчиков и в отличие от nVidia они будут работать везде (включая эту самую nVidia). Если у вас небольшая студия, работающая с графикой, то рациональнее использовать средства именно от AMD и НЕ использовать проприетарные средства от nVidia.
При этом, не стоит забывать, что консоли это амд, а значит, если игра планирует хапнуть пирога на этом рынке, ей так или иначе придётся поддерживать амд в любом случае. Но, патченный-перепатченный драйвер амд из проприетарной фряхи и проприетарные прослойки для фряхи не имеют никакого отношения к ПК и драйверам на ПК, тем более на линуксе.
Насчёт "будут работать везде" это лицемерие кстати, на нвидии работает ощутимо хуже. Они гадят друг-другу в тапки. Точно так же очень значительная часть разработок нвидии (которая, вообще-то, в любом случае значительно выше по рангу во всех отношениях) поддерживает работу на картах других производителей. Просто не все и не всегда хорошо.
И это не в последние годы, всегда так было. Другое дело, что opengl в венде тоже не шоколад всегда был.
Абсурд. OpenGL на проприетарных дровах ровно такой, каким его сделали вендоры ПОД ЛЮБУЮ систему. Родной OpenGL на открытых драйверах Linux хорош только тем, что работает корректнее всех, но при этом он самый медленный, разрабатывать на нём тяжёлые 3D приложения нет вообще никакого смысла. +Valve не просто так запилили свою реализацию OpenGL и Vulkan, которые весьма производительные. Так что мимо.
Я не замечал проблем с производительностью открытых драйверов в линуксе, проблема совсем не в этом (если конечно не считать нуво, но нуво вообще каким-то чудом теряет всего-то 20-30% производительности относительно блоба -- не так и критично). Именно что проприетарный опенгл одинаково будет работать на линуксе и без проблем поддерживать все игры которые разработаны для вендового опенгл. У свободных драйверов постоянно проблемы то с шейдерами, то с расширениями, то ещё с чем. Не знаю насчёт валве, но гугловская реализация драйверов опенгл/вулкана является огрызком и удобной прослойкой существующей с совсем иной целью, это не драйвер для железа.
>> Изменено поведение структуры std::process::Command на платформе Windows
> ну да, почти не поломали...Поломали стандартную майковскую уязвимость (еще в мохнатые года вредонос в виде той же riched.dll клался в одну папочку вместе с документом, при открытии документа пользователем DLL автоматом подгружается открывашкой-офисом, года до 2010 это было "notabag")?
Вот же злыдни!
Давайте начинать сразу про UB. Давайте растофанатики рассказывайте почему в продкшн билдах нет проверки на переполнения переменных? А в девовых есть.Как же так безопасный язык и Undefined Behaviour?
Лучше пусть расскажут про Ashley Williams и других активистов из Core Team, которые ни строчки на Rust не написали.
Они создают облик самого языка!
Кстати этот вопрос серьёзнее, чем просто едкая шутка. Вот язык V, который на сегодняшний день всего лишь поделка ОДНОГО человека (нашего соотечественника) уже лучше Rust, т.к. автор создавал его ДЛЯ СВОИХ нужд и активно сам им пользуется. При том что там наверняка есть серьёзные недоработки и баги, но при 0 бюджете - к этому не придраться.
Ок, тогда используй V, не трогай Rust!
> Ок, тогда используй V, не трогай Rust!Я лучше буду использовать C, но если у меня был бы принудительный выбор V или Rust, то выбран был бы V.
> Я лучше буду использовать C, но если у меня был бы принудительный
> выбор V или Rust, то выбран был бы V.Могу только посочувствовать..
Ваше дело, особенно улыбнуло сочувствие тем, кто пишут на C, без вашего сочувствия ну точно никак не обойтись).+Вы так пристрастно относитесь к тем, кто хоть слово скажет против Rust (возможно даже в силу низкой квалификации на этом языке, время покажет), но сами точно также отзываетесь об инструменте, который в глаза не видели. Кстати такое же, во многом маргинальное сообщество в своё время прикончило LISP. Почему-то ни с одним другим языком (Go, ML, Haskell, Clojure, Kotlin, Scala, Erlang, Haxe) ни у кого нет проблем и срачей они не вызвают, Go (2009) и Kotlin (2011) появились позже Rust (2006). Ответьте хотя бы себе, чем же именно Rust такой особенный? Может быть разработчики C и C++ волнуются? Да нет. Go, языки JVM, C# потеснили в разных задачах C++, ЗНАЧИТЕЛЬНО больше. И кстати на Go практически СРАЗУ начали активно программировать, Kotlin неожиданно быстро вписался в JVM стек, хотя там навалом языков. Лучше бы вместо всей демагогии и тонн баксов на ветер нормальную IDE для Rust запилили и помогли СОБСТВЕННЫМ ЖЕ разработчикам. Почему-то в JetBrains выпуская Kotlin озаботились тем, что людям нужно где-то писать код так, чтобы это было просто и удобно. Абстрактные "ну настройте любую/ой IDE/текстовый процессор" срабатывают ТОЛЬКО тогда, когда язык уже общепризнанный. Бесплатная opensource IDE со всем интегрированным стеком технологий и всего того что может предложить Rust (особенно если всё это добро будет НАПИСАНО на Rust) сработала бы куда лучше, чем бесконечная чехарда версий и срачи в Инете.
>Лучше бы вместо всей демагогии и тонн баксов на ветер нормальную IDE для Rust запилили и помогли СОБСТВЕННЫМ ЖЕ разработчикам.Так вот же они помогают. https://github.com/rust-lang/rls
> особенно улыбнуло сочувствие тем, кто пишут на CЯ сочувствую не тем, кто пишет на Си, а таким фанатичным любителям кактусов, как вы. Помочь я вам уже ни чем не могу, остается только посочувствовать. Во-первых, вы совершенно слепы в плане выбора языка, для вас выбор писать на чем-то, отличном от Си, обязательно должен быть принудительным. Это фанатизм номер раз - ни за что не променяю Си на что-то другое, если только не принудят. Теперь, выбирая между Rust и V вас не интересует рациональная сторона дела, V создает только один человек, причем под чисто свои нужды, в реализации есть баги ... но вы, тем не менее, выбираете его. Фанатизм номер два - ни за что не использовать Rust, даже если он объективно лучше. Мои соболезнования.
> но сами точно также отзываетесь об инструменте, который в глаза не видели
О каком инструменте я отзываюсь? На Си я программировал, на Rust я программирую последние годы и знаю, о чем говорю. Про V я вообще ничего не говорил - то что я написал в этом сообщении о нем, это ровно то, что вы сами о нем сказали. Это ваш отзыв, а не мой. Так о каком инструменте я отзываюсь?
> Давайте начинать сразу про UB.Sanitizer из clang/llvm решат эти проблемы (скорее всего, нет).
а ты из тех наркоманов что крутят дебаг билды на релизе?:) да, у хруста много проблем, но вот про UB разрабы языка подумали очень хорошо. в принципе язык поэтому и появился и это заложено в самые истоки его философии - все возможные ошибки должны быть перехвачены конпелятором(часть в дебаг режиме сугубо из-за оптимизаций времени сборки)
По той же причине по которой и в других языках этого нет и не будет, пока процессоры не переделают.
Какой-то тухлый вброс. На уровне жалоб на утечки памяти, обход которых делает язык не тьюринг-полным.
Переполнение беззнаковых целых в Rust не приводит к UB, как в C. Более того, поведение при переполнении еще и специфицировано:> Операции +, -, * могут приводить к переполнению (overflow) или исчезновению порядка (underflow). Если проверки включены, тогда произойдёт паника. В противном случае результатом будет циклическое переполнение.
https://rustycrate.ru/обучение/2016/07/25/myths-and-legends-about-integer-overflow-in-rust.html
В дополнение, у целочисленных типов есть специальные методы:
* checked_add и т.п., возвращающие None при переполнении
* overflowing_*, возвращающие кортеж с результатом и флагом переполнения
* saturating_*, ограничивающие результат минимальным и максимальным значениями типа
И узнаешь ты о них только после того как выкатишь прогу без них в полно
... в полной уверенности что всё итак проверяется. Безопасно чо.
Так будет если ты не будешь учить язык, а сразу начнешь писать. Как делают грозные хейтеры Раста с опеннета.Вот, пожалуйста, третья глава растбука https://doc.rust-lang.org/book/ch03-02-data-types.html#integ...
Я уже неоднократно убеждался, что местные критики не считают нужным читать документацию. Зато все, как один, эксперты по C и C++. Интересно, как они это делают, не читая стандарты и доки.
>Дополнительно можно отметить публикацию компанией Microsoft выпуска библиотек Rust for Windows 0.30, позволяющих использовать язык Rust для разработки приложений для ОС Windows. В набор входят два crate-пакета (windows и windows-sys), через которые можно обращаться к Win API в программах на языке RustА раньше было нельзя? Как тогда программы работали?
Проспись не было никаких программ.
> А раньше было нельзя? Как тогда программы работали?И раньше было можно, через отдельные библиотеки-обертки над сишным интерфейсом. MS упростила доступ к Windows API для Rust, а не сделала его вдруг возможным: https://habr.com/ru/news/t/538700/
> без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки).Ну сколько можно врать?! Какая стандартная библиотека, когда паники в ржавчине реализованы на механизме исключений C++ из LLVM?!
В расте нет паник!!!11
Занесут Rust в ядро - будут!
разворачивание стека может быть отключено, например для встраиваемых систем. тут просто смотря что понимать под рантаймом. можете считать это дешевым маркетингом разрабов языка, можете более абстрактыми определениями некоторых понятий, которые скорее всего люди, пишущие не одно десятилетие на плюсах вероятно не сможет переопределить(хотя не говорю за всех)
>В огороде бузина
>>а в Киеве — дядькаЕсли это намек на скорость исполнения кода, то в рантайме накладных расходов нет.
строки 82-100: https://godbolt.org/z/Pe81K7z81Накладных расходов нет, потому что нет исключений.
если язык допиливается так часто, то о какой стабильности и переносимости может идти речь?написанный вчера код в завтрашний день не факт что можно перенести.
теперь мало какой код может это делать.
> написанный вчера код в завтрашний день не факт что можно перенести.Не "не факт что можно", а "факт что нельзя".
Я вот как-то попал на ситуацию, когда хелловолрлд с главной странички последним растом не собрался.
> Я вот как-то попал на ситуацию, когда хелловолрлд с главной странички последним
> растом не собрался.Последним стабильным растом? Вы шутите.
>> Я вот как-то попал на ситуацию, когда хелловолрлд с главной странички последним
>> растом не собрался.
> Последним стабильным растом? Вы шутите.Да какие шутки, тут все сурьезно! Перл другого Воена Антирастового Спротивления, из прошлого срача:
>>> И да, твоя программа компилируется, то есть с точки зрения языка программа правильная, но ругается при линковке, что нет "паникующей" функции....
>> попробуйте cargo build --release...
> Ничего я не запускал. Буду я еще запускать костыли"И вот так - у них все!"(с)
И я бы сказал даже больше - не только лишь все это могут сделать
если бы вы хоть немного напряглись разобраться в теме(иначе это форсированное набрасывание на вентилятор), то поняли бы что у сабжа есть механизм редакций, которы решает проблемы разных версий. старый код точно будет работать, для новых фичей нужно адаптировать под редакцию. но как правило все идет постепенно
Тебе же выше сказали - хеловорлд с главной не везде собирается. Может стоило заниматься разработкой и допиливанием вместо форсирования и рекламы ? Вот раст яркий пример как можно продавать нерабочую никому ненужную фигню.
> Тебе же выше сказали - хеловорлд с главной не везде собирается. Может стоило заниматьсяМожет стоило привести конкретику вместо извечных опеннетных рассуждизмов "ни о чем"?
А то вон, выше о подгорании местных от одного упоминания "Rust" тоже скзанно - оправдывайся теперь.
> выше о подгорании местных от одного упоминания "Rust"К глобальному потеплению идем, скоро на пляжах сибири пальмы высадим !
Этот господин (Урри) часто любит говорить о том, как у него что-то не сложилось с тем, что он не понимает, там где у нормальных людей проблем не бывает от слова "совсем". Но это же не означает, что то, что он говорит имеет хоть какое-то отношение к реальности.
Так вам же сказали, таблетки пить нужно было.
Всё завелось бы. И главный врач был бы доволен.
> если язык допиливается так часто, то о какой стабильности и переносимости может
> идти речь?Каждые шесть недель происходит выпуск следующей *минорной* версии языка, которая сохраняет обратную совместимость с предыдущими в рамках своей редакции. Так что со стабильностью и переносимостью все в порядке.
Странная фигня этот ваш раст, но столько тепла вызывает.
Ничего странного. Когда я понял, что пора валить с C++ (после 20 лет опыта), было лишь три достойных кандидата — Go, Rust и Haskell.
> валить с C++ (после 20 лет опыта),дружище, годик не досидел, С++ за 21 день надо осиливать
Пенсия же.
Сейчас еще Swift есть, и D тоже можно вспомнить.
Есть Nim неплохой кандидат.
Раковая клетка Rust-а продолжает делится и приобретать все более уродливые формы
завидно что эволюция обходит сторонкой?
Дустом такую эволюцию.
Разве что в разыгравшемся воображении луддитов.
>> Раковая клетка Rust-а продолжает делится и приобретать все более уродливые формы
> Разве что в разыгравшемся воображении луддитов.Тут почему-то вспоминается "Ем грибы, смотрю ковер!".
Переставай уже грибы есть. А то странные у тебя ассоциации какие-то.
Замечательный язык. Очень рад что его выбрали для проекта. Довольны все.Разработчики - можно нифига не делать, срать в коменазх и ссылаться постоянно на новую версию и ахи вздохи как всё когданибудь будет классно
Начальство - можно бесконечно тянуть деньги с заказчика потакая всеобщему хайпу о том как когданибудь всё будет офигенно.
Заказчик - он читает идиотские статьи и верит что когданибудь у него будет супер продукт который захвати весь мир и будет совершенно безопасен и без ды.
Спонсоры. Они думаю что вложились в офигенную штуку и разбогатеют на трилионы.
И только финансовые директора сидят и смотрят на этих плоумных и планируют куда и как свалить. Потому что они то видят когда закончатся деньги у этих идиотов.
Ах да, адекватные разработчики тоже довольны.Сидят и ржут.
> срать в коменазх
> Ах да, адекватные разработчики тоже довольны.
> Сидят и ржут.А ты самокритичный, однако.
Ну да, самокритика признак адекватности.
Проблески разума пробиваются наружу. Это хорошо. Но этого недостаточно, чтобы считаться полностью адекватным.
Любопытная заметка про раст, не про его качество, а про его так называемую "открытость"
https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...
>> In short, Mozilla won't be happy with us applying patches and modifications to their trademarked language without “explicit approval”, except for non-commercial usage, so it is a freedom issue.
>> freedom
> Любопытная заметка про раст, не про его качество, а про его так называемую "открытость"Любопытная попытка манипуляции.
>> In short, Mozilla won't be happy with us applying patches and modifications
>> In shortИ он еще рассуждает о манипуляциях.
>>> A rebranded version of Rust maintained by the GNU Project and FSDG-compliant distros could be the way.
>>> In short, Mozilla won't be happy with us applying patches and modifications
>>> In shortТ.е. ты просто не умеешь в английский?
Нет, ты просто не умеешь в логику.
> Любопытная заметка про раст,тор жалко конечно. может быть будет возможность сделать безрастовый форк, но скорее это будут похороны тора.
Ну как же, похороны. 5 лет без двух месяцев переписывают, и оно уже вот совсем почти, но еще немного "not ready for production use". А разгадка проста - https://grants.zfnd.org/proposals/215972995-arti-a-pure-rust... . Этак можно и до пенсии успешно переписывать. Учись, анон.
Если разрадятся - запрошу грант на сишную версию
> Любопытная заметка про раст, не про его качество, а про его так
> называемую "открытость"
> https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...А в чем проблема-то? Хочешь пропатчить язык до неузнаваемости - назови его по-своему, делов-то.
>Хочешь пропатчить язык до неузнаваемости - назови его по-своему, делов-то.Где там сказано, что до неузнаваемости? Не передергивай. Просто парни хотят все держать под контролем.
Ну представь что кто-то форкнул твой проект и называет его так же как и ты. Такого нет в практике никаких нормальных лицензий, и в коммьюнити ни кто так не делает.
А представь нет. Представь пропатчить надо только, а бежать за разрешением надо к растаманам.
> Опубликован релиз языка системного программирования Rust 1.58Смотришь на перспективные проекты критичные к безопасности а они бац на С как раньше
https://github.com/mz-automation/libiec61850
специалисты в предметных областях не бегут на поводу у изобретателей смирительных трусов
Смирительные трусы мы и сами можем написать или готовые взять. Изобретать для этого отдельный язык совершенно необязательно. К тому же как мы видим из новости, он с каждым релизом меняется - самое то для надежных программ!
> а они бац на С как раньшеСколько-сколько проекту лет? С чего бы его с нуля переписывать на другом языке?
> Сколько-сколько проекту лет?
> Rust Появился в: 23 июля 2006Rust-у уже 15 лет и ничего серьёзного на нём не пишут. А ответ прост
> The basic library is written in C (C99 compliant to provide maximum portability). Due to its > hardware and platform independent design it can easily deployed on any platform.
Не переписывают, ты хотел сказать.
А так - пишут. Иначе спонсоров бы не было.
> А так - пишутпокажи хоть один life-safety critical проект на rust
> Иначе спонсоров бы не было
спонсируют те кому нужны массы дешёвых рабочих с приемлемым качеством кода, ничего серьёзного они не напишут никогда
>> Сколько-сколько проекту лет?
>> Rust Появился в: 23 июля 2006
> Rust-у уже 15 лет и ничего серьёзного на нём не пишут. А
> ответ простПосмотри в английской Википедии, когда появился Rust.
Там пруфов нет, а в русской написано в 2006.
> Там пруфов нет, а в русской написано в 2006.А какие пруфы в русской Википедии? Там просто ссылка на GitHub репозиторий, в котором, кстати, первые issue и PR появились в 2010 году.
Лучше, чем никаких в англоязычной. В 2010 язык был представлен и разработка уже шла несколько лет.
>>> Rust-у уже 15 лет и ничего серьёзного на нём не пишут.
> Лучше, чем никаких в англоязычной. В 2010 язык был представлен и разработка уже шла несколько лет.https://mail.mozilla.org/pipermail/rust-dev/2012-January/001...?
> [rust-dev] The Rust compiler 0.1 is unleashed
> Fri Jan 20 14:34:26 PST 2012И правда, никто ж не мешал разрабатывать на расте еще 6 лет до выхода версии 0.1!
Опеннетная оналитека во всей её красе ...
> никто ж не мешал разрабатывать на расте еще 6 лет до выхода версии 0.1никто не мешал на 0.01, разницы никакой - оно и 1.58 такое же нестабильное
> никто не мешал на 0.01, разницы никакой - оно и 1.58 такое
> же нестабильноеRust был стабилизорован с версии 1.0 вышедшей в 2015 году. С этого времени каждая новая минорная версия языка в рамках одной и той же редакции сохраняет обратную совместимость. Редакции же меняются один раз в три года и совместимы между собой на уровне "линковки" крейтов.
> Rust был стабилизорован с версии 1.0 вышедшей в 2015 году.через 10 лет будете говорить "по настоящему Rust был стабилизирован с версии 2.0 вышедшей всего пару лет назад" в ответ что никто так ничего и не написал серьёзного на нём. Непортируемый, нестабильный, сырой, негодный. Остаётся ждать годные современные инструменты а пока пользоваться старым добрым С.
> через 10 лет будетеРеальные аргументы кончились и остались только фантазии?
Тут тяжелый случай, объяснять бесполезно ему.
> объяснять бесполезно емуприведи пример safety critical проекта на rust потом пытайся что-то объяснять
>> Rust-у уже 15 лет и ничего серьёзного на нём не пишут.
>> Лучше, чем никаких в англоязычной. В 2010 язык был представлен и разработка уже шла несколько лет.
>>> > [rust-dev] The Rust compiler 0.1 is unleashed Fri Jan 20 14:34:26 PST 2012
> никто не мешал на 0.01, разницы никакой - оно и 1.58 такое же нестабильноеКакой неуклюжий спрыг.
> В компиляторе требования к минимальной версии LLVM подняты до LLVM 12.С этим всё нормально:
% pkg info -x llvm
llvm12-12.0.1_7
llvm13-13.0.0_3
% cc --version
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/binВон уже Firefox 96.0.1 вышел, а в портах FreeBSD всё ещё rust-1.57.0 и firefox-95.0.2_1,2. Обновление Firefox с задержкой портирования Rust-1.58 как-то связано?
http://rustmustdie.com/
чтиво для просветления разума от раста
автору самому бы полечиться
или базу подучить, прежде чем писать чернуху
Согласен, что чтиво. Иначе эти потуги и не назовёшь. Сплошные манипуляции, которые здравомыслящий человек видит сходу. Жаль, неокрепшие умы могут повестись на этот "креатив". Автор всю статью только и делает, что брызжет слюной, пытаясь слепить из мухи слона. Получается очень и очень плохо. КГ/АМ, в общем.
очень слабенькая статейка от фанатика и хейтерка. автор - представитель "токсичного сообщества", о котором сам же пишет.Вроде как даже не разобрался в вопросе, но уже имеет собственное мнение.
У него и это есть
http://cmustdie.com/
но я, всё-таки, не понимаю зачем нужен был такой сложный синтаксис, ведь по задумке он программирование более легким должен был сделать
> но я, всё-таки, не понимаю зачем нужен был такой сложный синтаксис, ведь
> по задумке он программирование более легким должен был сделатьА точно сложен именно синтаксис? А не семантика?
> чтиво для просветления разума от растаО, ученики самого Столярова подъехали! Это уже диагноз.
Вот в блоге маэстро пытались уже обсуждать эту писульку - http://www.stolyarov.info/node/342
Только бесполезно, потому что там премодерация и толковые разъяснения по ошибкам в статье так и не опубликовали. Я сам туда писал сообщения в максимально вежливой форме - их тоже нет.
У Столярова вечные комплесы. Он как-то п*?данул, что "абитурьентская"/ВУЗовская математика не нужна, мол где вы видели столько тригонометрии и неравенств? Я этому придурку выложила тонны ПРАКТИЧЕСКИХ примеров начиная от радиотехники, заканчивая задачами в геймдеве и CG, стоит ли говорить про премодерацию тоже не прошло. Но с такими загонами никто его всерьёз воспринимать не будет, даже несмотря на то что некоторые вещи, которые он излагает могут быть вполне рациональные (например, хейт к js).
В программировании математика не нужна. Изучение академических глубин высшей математики - это потеря времеени. В геймдеве математика не нужна, да, при программировании геометрических примитивов нужна линейная алгебра. Столяров прав.
> В программировании математика не нужна.В программировании чего она не нужна?
В реальной практике программиста математика ограничивается начальным уровнем 5 класса. Нефик учить диффуры.
И как ты собрался оценивать сложность алгоритмов без математики, интересно?
А как быть с ИИ, который сплошь и рядом на дифференциальном исчислении и линейной алгебре строится?
Как обойтись без математики в CAD-системах?
Как любую графику (2d, 3d) кодировать без математики (в том числе высшей)?
Как строить прогнозы погоды без высшей математики?
Как запросы писать на том же SQL, не владея основами теории множеств?
Как программировать полёты в космос?Конечно, есть много сфер, где вышка не нужна. Но ведь этими областями человеческая деятельность не ограничивается. Следовательно, обобщение Столярова (если он действительно такое говорил) неверно.
>если он действительно такое говорилПрямая цитата с его сайта в последней (11.01.2022 16:54) теме: "Известно, что абитуриентская математика — это совершенно отдельный вид спорта, к реальной математике никакого отношения не имеющий (где вы в реальной математике видели столько тригонометрических неравенств и, скажем, неравенств с модулями)."
Что такое "реальная математика" в его понимании вопрос открытый... Но даже просто из вашего списка несколько пунктов требуют сложной тригонометрии с неравенствами и модулями, которые так не нравятся Столярову.
Реальная математика - это уровень начальных классаов, которая реально пригодится в жизни. остальное туфта.
Прими таблетки. Ох уж эти старые пердуны. Если потребуется нужную часть математики мы быстро выучим. А дp*чить мозги этой абстрактной наукой точно не стоит.
>> чтиво для просветления разума от раста
> О, ученики самого Столярова подъехали! Это уже диагноз.О, фанаты самого Раста подъехали! Это уже диагноз.
Правильней будет не "фанаты Раста", а сторонники здравого смысла и прогресса. И в таком ключе непонятно, какой здесь может быть поставлен диагноз.
> http://rustmustdie.com/
> чтиво для просветления разума от растаВ принципе, достаточно прочитать первый абзац.
Безграмотная каша, приправленная тоннами демагогии:
>> #[rustc_builtin_macro]становится вдруг "непосредственно в языке есть конструкция вывода", ну и заодно, типа "рантаймом"
>> Сказки о невероятных удобствах и возможностях макросов, якобы позволяющих перенести в компайлтайм любое вычисление, рушатся уже на этапе написания первой программы на этом удивительном языке!Еще Rust оказывается "уникален" неизменяемыми по умолчанию переменными (это вообще придумали задолго до рождения аффтыря)
>> Rust уникален не только в способе вывода строки. Приведём пример с использованием переменного и неизмянеямого значений,"const времени компиляции:
const fn sum_test(xs: [Point; 3]) -> Point {
xs[0].add(xs[1]).add(xs[2])
}
оказывается просто аналог сишного #define
>> Константами в Rust именуется ещё одна, третья сущность, обозначающая константы времени компиляции, те что в Си обычно определяются через defineОткровенное вранье:
>> как следствие, необходимо знать, понимать и помнить правила вывода типа, которые невероятно сложны, в силу чего задача определения, может ли тип быть выведен и какой тип будет выведен, также сложна.натягивание совы на глобус:
>> На самом деле это конструктор объекта итерируемого типа из стандартной библиотеки. Вновь мы наблюдаем привязку языка к стандартной библиотеке, которая в таком случае теряет своё значение как библиотека и становится просто-напросто частью языка — вновь рушатся иллюзии о нулевом рантайме.откровенная оторванность от реальности:
>> объявления верхнего уровня в Rust могут идти в любом порядке, то есть мы можем использовать функцию, определённую позже в коде программы. Это требует многопроходности, а с учётом обильного использования макросов и статического анализа делает процесс компиляции неожиданно медленным: даже небольшие программы порой компилируются часами.Безграмотность (впрочем, как и полное неосиляние концепта владений)
>> По сути техника владения и перемещения была придумана, чтобы не копировать сложные значения, для которых это может быть очень трудоёмкой задачей.Демагогия с передергиванием:
>> Мы можем написать такую программу, отдав строку во власть встроенного в стандартную библиотеку сборщика мусора методом подсчёта ссылок:
>> use std::rc::Rc;...
>> Особо стоит подчеркнуть, что сборщик мусора встроен в стандартную библиотеку, которая неотделима от самого языка, а потому заявления, что Rust — это якобы язык без сборки мусора, — лживы
>> разумный человек
>> Сообщество Rust — это мир фанатиков.
>> Каким-то чудом в сообществе Rust умудряются выжить единицы адекватных программистов, и мне больно видеть, как их разъедает ржавчина.сравнение жопы с пальцем:
pub fn magic() { /* 4300 */
let v: Vec<i32> = vec![1, 2, 3]
.into_iter().map(|x| x + 1).collect();
}
void magic() { /* 20 */
int v[] = {1, 2, 3};
for (int i = 0; i != 3; ++i) {
v[i]++;
}
}
(причем "получаемый машиннй код" для раста - "естественно" дебагсборка без оптимизаций)
там еще куча всего по мелочи (например,
>> при этом, в отличие от макросов языка Лисп, макросы Rust пишутся на ином, отличном от базового языке — поэтому для их написания надо изучить по сути ещё один язык вдобавок к базовому языку Rust.(o Scheme аффтар благополучно не слышал)
В общем, вброс на уровне Опеннетных Военов Антираста.
Узнаётся почерк растамана - тонна никчёмного мусора, который читать-то сложно.
> Узнаётся почерк растамана - тонна никчёмного мусора, который читать-то сложно.Учитывая, что основная часть - это цитированные "перлы" очередного "критега", узнается безграмотность очередного опеннетного икспертуса.
Знаете что смешно? брызги слюны во все стороны и отсутствие аргументации.какой бы не был автор, он пытался аргументировать свою точку зрения.
У вас же, одни тезисы. Что почему и куда я должен знать сам.
У важаемый, вы эту пасту для себя выложили? Да бы укрепить в себе уверенность в расте.Я на расте не программирую, а пачка утверждений в комментах на опеннете от анона - так себе тянет на релевантный источник информации, извините.
> Знаете что смешно? брызги слюны во все стороны и отсутствие аргументации.
> какой бы не был автор, он пытался аргументировать свою точку зрения.
> У вас же, одни тезисы. Что почему и куда я должен знать сам.Знаете что смешно? Отсутствие элементарных знаний у опеннетных "Военов Протои Раста".
Ну и навыка чтения.
Вам какой еще аргумент к заявлению
>> Константами в Rust именуется ещё одна, третья сущность, обозначающая константы времени компиляции, те что в Си обычно определяются через defineнужен, помимо приведенного примера функции, вычисляемой во время компиляции? Краткий курс "Си за 21 день"?
А к цитатам "Демагогия с передергиванием"?
Не, ну я могу объяснить, что взятый в качестве примера тип данных Rc/Arc, реализующий _указатель_ с подсчетом ссылок (reference counting pointer, shared_ptr из С++) - это, как бы, далеко не "сборщик мусора" (что автоматом делает вывод аффтыря
>> потому заявления, что Rust — это якобы язык без сборки мусора, — лживыто ли демагогией, то ли просто безграмотностью (тогда и C++ - ЯП с неотделимой сборкой мусора, ведь там есть shared_ptr).
Но вот "лживы ... мир фанатиков ...разъедает ржавчина" - тоже в объяснениях нуждаются?
А к "(причем "получаемый машиннй код" для раста - "естественно" дебагсборка без оптимизаций)"?
У аффтыря там ссылка, как бы. Но да, подразумевает чтение далее заголовка.Или: "Еще Rust оказывается "уникален" неизменяемыми по умолчанию переменными (это вообще придумали задолго до рождения аффтыря)
>> цитата аффтыряЭто вообще классика - ладно там Miranda/Clean, но не слышать краем уха о Haskell/Prolog/ML/Scheme?
> У важаемый, вы эту пасту для себя выложили? Да бы укрепить в себе уверенность в расте.
Для людей с базовыми знаниями, вестимо. Большей частью абсолютно не требует какого либо знания ржавчины. А остальным оно как-то и не интересно должно быть.
Впрочем, навык оценки формы подачи материала кое-кому тоже бы не помешал - ведь их не насторожила куча "аргументов к человеку" и прочей манипуляции, которая абсолютно недопустима в мал-мальско серьезном обсуждении.
> Я на расте не программирую, а пачка утверждений в комментах на опеннете
> от анона - так себе тянет на релевантный источник информации, извините.Ну да, то ли дело целая страничка в интернете, ага.
> У вас же, одни тезисы. Что почему и куда я должен знать сам.Внимательно следите за руками:
утверждение автора:
>> Да, исходный код стал значительно меньше, вот только получаемый машинный код на порядки вырос, да ещё и стал существенно медленней. Предлагаемая тут сущность, передаваемая в filter, и вовсе является замыканием из мира функционального программирования и представляется в машине весьма нетривиально; желающим предлагается посмотретьссылка на код и результат компиляции в асм (где-то 2700 строк)
https://rust.godbolt.org/z/9fsjocjx3 (короткая версия, оригинал режет опеннетный движок)его "вывод"
>> Как видим, сообщество Rust поощряет своих разработчиков писать медленные и громоздкие программы, обильно использовать запутывающие абстракции, что они на самом деле вынуждены делать из-за карающей природы самого языка — писать на нём буквально больноТот же код, с флагом -О (оптимизацией)
https://rust.godbolt.org/z/vvnrzrzT1 (50 строк)
и для провекри, с _добавленным_ выводом результата:
https://rust.godbolt.org/z/5foncW8Gf (95 строк)комментарии, как говорится, излишни.
это пять, спасибо.
> http://rustmustdie.com/
> чтиво для просветления разума от растапасиб анончик, классное чтиво. Вспомнились записки мыщъха о сишечке, только наоборот :-D
"This issue of slow adoption of Rust programming language was first noticed in Stack Overflow’s 2019 survey. There we saw that majority of developers had a positive outlook towards Rust, but 97% of them had never actually used it."
https://fossbytes.com/developers-reveal-why-rust-programming.../Хахахахаха! Многим нравится Раст, но мало кто программирует на нем.
"Interestingly, Google once used Rust programming language in several components of Fuchsia, which is touted to be the replacement for Android. However, after reassessment, it decided not to support Rust anymore because none of its current end-developers were using it, and it was neither a widely-used language."
Ну все.
> Многим нравится Раст, но мало кто программирует на нем.Не все могут себе позволить начинать новый проект с Rust, увы. Я уж молчу про поддержку существующих проектов - переписывание с нуля будет дорогим удовольствием.
> Ну все.
Что именно? Гугл до сих пор платиновый спонсор Rust Foundation (или как там эта организация называется правильно).
Если гугол что-то спонсирует, надо бежать оттуда подальше.
Беги, страус, беги. Прячь голову в песок поглубже. :)
> Если гугол что-то спонсирует, надо бежать оттуда подальше.https://www.linuxfoundation.org/press-release/google-becomes.../
Уточни пожалуйста, ты с яблока пишешь или с венды?
Вы ссылаетесь на статью двухлетней давности. А весной 2021 г. Google добавило Rust в число языков, которые допускаются для разработки платформы Android.
И много уже написали приложений на Расте для Android?
Как я этой новости ждал - libc на Rust под линух: https://blog.sunfishcode.online/port-std-to-rustix/Можно будет себе статически все вкомпилировать и получить монолитный бинарь который только к ядру обращается. Мечта троянописателя. Плюсом еще все знают что статическая линковка позволяет ускорить приложение.
Да-когдаж-ето-прекратится.JPG https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...
Один из первых компонентов что стоило на Раст переписывать, хотя бы частично, самые критичные места.И главное проект спонсируется (https://bytecodealliance.org/), значит не загнется на 1,5 потухших энтузиастах.
Почему растаманы не развивают свою редокс, а только лезут в чужие проекты?
> Почему растаманы не развивают свою редокс, а только лезут в чужие проекты?Почему нерастамын не развивают свой нередокс, а только лезут указывать в чужих проектах, кому и что делать?
Они и развивают, и не лезут.
Я хочу поблагодарить своих родителей таньку и володьку. За то, что они меня заставили изучить Rust.
У таньки есть разъём типа "папа"?
хороший, годный анонимус. :-}
Когда C# введут в ядро? Он такой же безопасный как раст, даже ещё безопаснее.
C# потянет виртуальную машину. Как C# работает в нейтиве, как он при этом выглядит в плане синтаксиса все уже видели - называется С++.А раст в ядре будет пользоваться ядерными примитивами, и стандартной библиотеки там не будет.
> виртуальную машинуebpf? Не, не слышали...