Опубликован релиз 1.46 языка системного программирования Rust, основанного проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53610
> Для повышения информативности сообщений об ошибках стабилизирована поддержка атрибута "#[track_caller]", полезного для функций, подобных unwrap, в которых не исключается возникновение сбоев (panic) при некорректном использовании типов. Указанный атрибут будет использован обработчиком panic для вывода местоположения вызывающего в сообщении об ошибке.Полезная штука. А то обработка паники накидывает несколько стековых фреймов, поверх того места, где panic! был вызван, при этом, часто мне не интересно где был вызван panic!, мне интересно где был сделан unwrap, приведший к панике, и приходится этот бектрейс глазами сканировать, выискивая нужное место. А тут можно сразу пропустить кучу неинтересных стековых фреймов и начать втыкать глазами туда, куда собственно нужно.
А вот и констэкспрешшены из плюсов подвезли. Глядишь, лет через 30 будет новый нескучный С++.Зачем, только, если уже есть один...
У Раста нет ниши, они даже нишу языков для браузерных движков занять не смогли.
Ниша - замена легаси вроде C/C++ + веб-разработка. Отличные ниши.
Но ведь си это не легаси. Это модерн. Сказал я, только вчера выяснял почему в программе происходит какая-то дичь, оказалось на этой строчке int ret=execvp(args->argv[0], args->argv); argv не был инициализирован. Упс. Да, конечно, санитизеры без проблем нашли это в рантайме, но компилятору было норм. Копипаста до добра не доводит. Там ещё с фоновым тредом развлекуха была. Помог бы тут руст? Ну, вряд ли. Смысл как раз в том, чтобы иметь минимальный оверхэд в рантайме.
Ps. но я что-то не понял чем санитизер сейчас не доволен, кто-нибудь может пояснить мне? 223 ему нравится, а меньше нет. У меня там стояло 16 и больше 12 быть не может.
void get_vals(char **buf,unsigned *var)
{
char varbuf[223];
char *varbufp=varbuf;
unsigned char vari=0;
for(char *bufp=*buf;*bufp!='\0';bufp++) {
if (*bufp==' '||*bufp=='\n') {
if (varbufp==varbuf) continue;
else {
*varbufp='\0';
var[vari++]=atoi(varbuf);
varbufp=varbuf;
continue;
}
}
*varbufp++=*bufp;
}
*varbufp='\0';
}
Ошибка здесь скорее всего
var[vari++]=atoi(varbuf);
вместо
var[vari++]=atoi(varbufp);Думаю, не ругается, потому что при таком размере стека его не пробивает.
Кстати, почему передаётся **buf, но используем только первая строка? Думаю, будет лучше
void get_vals(char * const buf,unsigned *var)
EDIT: Наглядный пример, что санитайзеры не всегда дают ответ, на какой конкретно строчке проблема. Как и то, что уж лучше с ними, чем совсем без них.
Там buf байты на хипе (да, теоретически может быть переполнение, там их 256, но практически этого не случится никогда и 16 байтов на одно значение за глаза -- там UINT_MAX ограничено), var инты на стеке. Я так и не понял, как передать инты на хипе, выдаёт note: expected 'unsigned int *' but argument is of type 'unsigned int (*)[3]', но на стеке вполне работает.varbufp вместо varbuf выдаёт одни нули, а не значения, это явно не то что мне нужно.
А какая разница, на чём buf? Да хоть из общей памяти, зачем передавать указатель на указатель на строку, чтобы тут же его разименовывать?Как ты создаёшь это buf в таком случае?
Принтами или дебаггером, проверь, что воообще у тебя в varbufp сразу перед atoi(varbufp). то что вообще в *buf в этот момент, может, там не только цифры и пробелы с новыми строками. Да и новые строки не всегда на '\n' оканчиваются, может, там '\r' затесалось. Чёрт, да там сам buf может быть не тем, что ожидаешь.
EDIT: ОК, я ожидал, что это учебный или одноразовый код, и там заранее известно, что есть в строках, чего нет. Теперь я ничего не понимаю.
Так что мне нужно как можно больше информации.
Не-не, там всё в порядке.
char *fbuf=malloc(256);
rlen=read(fd,fbuf,256-1);
unsigned varvals[3];
get_vals(&buf,varvals);При этом varbufp нужен только чтобы занулять последний байт, в buf всегда числа разделённые пробелом и завершающиеся \n, ничего иного там быть не может (никогда не было и не будет).
get_vals(&fbuf,varvals);
Если точнее.
>
> get_vals(&fbuf,varvals);
>
> Если точнее.Ответил чуть ниже. И тогда ты должен изменить тип первого аргумента. Сейчас поясню в деталях.
char **buf -- это массив массивов по факту.
Если бы код был
const int N = 10
char **buf = malloc(N*sizeof(char *));for(int i=0; i < N; ++i){
buf[i] = malloc(256);
}
fbuf = buf[0];то всё было бы норм. А так у тебя переход в случайный участок памяти, и как оно всё работало -- вообще загадка. И выходит, санитайзер такое не словил, учту на будущее.
> char **buf -- это массив массивов по факту.это переданный в единицу трансляции указатель на выделенные в хипе байты, что такое &fbuf?
> Если бы код был
Вообще не релевантно ведь, нет? Тут просто строка с байтами, адрес которой мы разыменовываем "где-то там".
Ух. Надеюсь, ты сейчас в процессе обучения. Тогда ошибки -- это нормально, а ругаться за незнания -- зло и неправильно, поэтому не буду.Итак,
char *fbuf=malloc(256);
Не инициализорован, последний символ не факт, что '\0'
rlen=read(fd,fbuf,256-1);
Тут всё верно, читаем 255 символов. Но вот потом нужно обязательно
fbuf[rlen]='\0';
unsigned varvals[3];
Магические константы, а максимальный размер нужно обязательно проверять внутри get_vals. И передавать туда же.get_vals(&buf,varvals);
Это всё круто, но где собственно &buf инициализируется? И нах он вообще нужен, передавай сразу fbuf и измени сигнатуру get_vals, чтобы он принимал указатель сразу на char * const вместо двойного указателя.Сорян, но None прав, C не Питон, ошибок не прощает и требует всё проверять самому.
Edit: ну и сразу, всё верно, нельзя просто взять и передать массив в функцию в C. Хотя можно передать указатель на массив и уже в теле разименовывать. Что то в духе
void random_func(int (*varname)[3]){ (*varname)[0] = 1; (*varname)[1] = 2; }
Или передать указатель на структуру, внутри которой массив. Но обычно просто передают указатель и размер отдельной переменной, так проще.
В чём твоя проблема? Последний символ факт что \0 потому что я пишу
if(-1==(rlen=read(fd,fbuf,256-1))){perror("can't read");_exit(EXIT_FAILURE);}
else {fbuf[256-1]='\0'; fbuf[rlen-1]='\0';}
вместо calloc>Магические константы, а максимальный размер
3 инта, и не изменится в обозримом будущем, если когда-нибудь через годы изменится, то это будет меньшая из проблем.
>Это всё круто, но где собственно &buf инициализируется?
Это fbuf и есть, ошибся при написании поста.
>Сорян, но None прав, C не Питон, ошибок не прощает и требует всё проверять самому.
Всё отлично и никаких ошибок в этом коде у меня нет, просто я не понимаю, чем санитизер не доволен.
> Всё отлично и никаких ошибок в этом коде у меня нет, просто
> я не понимаю, чем санитизер не доволен.Хех. Ладно, троллинг засчитан, спокойной ночи.
> Хех. Ладно, троллинг засчитан, спокойной ночи.Ну нет. Этот код успешно работает в продакшене больше года, и если бы с ним были проблемы, уже заметили бы.
>> Хех. Ладно, троллинг засчитан, спокойной ночи.
> Ну нет. Этот код успешно работает в продакшене больше года, и если
> бы с ним были проблемы, уже заметили бы.После уменьшения malloc и увеличения varbuf компилятор успокоился (и гцц и шланг), но теперь выдаёт некорректные значения. Т_Т Где я туплю? Чёрт, ладно, пора спать давно, потом разберёмся. Я просто знал что это прекрасный образец кода на UB в лучшем случае, и потому его не трогал. D:
Алсо, шланговый мемори санитайзер пожаловался на неинициализированную память в unsigned varvals[3];, ну, тут я согласен, хотя в гцц она и инициализируется нулями.
>Edit: ну и сразу, всё верно, нельзя просто взять и передать массив в функцию в C. Хотя можно передать указатель на массив и уже в теле разименовывать. Что то в духеНу не знаю, я передавал указатель на указатель на байты, чтобы отправить в функцию чужой объект на хипе, я не вижу где там const, кроме самого указателя. Я всегда так делаю и всё нормально, лучше меня не научили.
>передать указатель на структуру
Ну тут я хотел передать 3 инта (с выделенной под них памятью, естественно) на хипе, аллоцированных в чужой единице трансляции, но компилятор меня обломал (аж несколько раз). Массив передать таким образом можно, и поскольку там всего 3 значения, я не стал заморачиваться и пихнул на стеке.
> Edit: ну и сразу, всё верно, нельзя просто взять и передать массив
> в функцию в C. Хотя можно передать указатель на массив и
> уже в теле разименовывать. Что то в духеМожно. Глянь:
#include <stdio.h>
#include <stdlib.h>void fill_array(int arr[3]) {
for(int i = 0; i < 3; i ++) {
arr[i] = i;
}
}int main() {
int arr[3];
fill_array(arr);
printf("%d, %d, %d\n", arr[0], arr[1], arr[2]);
return 0;
}Можно в аргументах написать:
int arr[3]
int arr[]
int *arrВсё это разные записи для плюс-минус одного и того же, но первый способ даст возможность статическим анализаторам ругнутся, при очевидных выходах за границу массива. Последний способ даст возможность менять arr, а не только *arr.
Эммм... а что, готовой функции распарсить не нашлось? тот же scanfНу и тут санитарзер особо не нужен - из исходного buf идёт копирование без каких-либо проверок, вписались в выделенный размер или нет. Так на C нельзя писать. Что вы выиграете? Некую производительность ценой порчи стека в непредсказуемой ситуации?
В непредсказуемой ситуации мы уже потеряли ядро, это единственный вариант. Или космические лучи, я не знаю.
Какой п****ц. Кто-то реально так пишет, или это толстый траллинг был?
Вы удивитесь, но куча народу пишет именно так. Даже если в конкретном случае это троллинг.
А потом мы удивляемся - "ачигосишечкатакаядырявая". Это не сишечка дырявая, это головы дырявые.
Шоко... т.е. Си ни в чём не виноват!
А можно поинтересоваться для повышения образованности? Что за схема именования переменных? У меня эти имена вообще в голове не укладываются, я не могу читать код, потому что они путаются у меня в голове. Не вижу схемы, не вижу смысла => они все одинаковы для меня. Мне кажется, что рандомно-сгенерированные наборы букв были бы читаемее.var, buf, p, и всё возможные комбинации из трёх. Зачем? В латинском алфавите 26 букв, можно было бы под каждую переменную выделить свою букву, и было бы читаемее чем это. И, кстати, короче.
Суффикс p использован для указателя, вполне читаемое, если видеть, что varbuf это максимум 1 инт в виде текста (до 10 байт по-моему), buf это весь текст прочитанный из файла, а var и vari это искомые значения в виде интов и текущий индекс в массиве. Мне так удобно. Я бы мне смог воспринимать это в виде i j k l m.
strtok_r + atoi ?
А вот это правильный ответ! В данном случае оверкил, мне кажется, но этот вариант намного лучше альтернатив.
>++=руки бы тебе оторвать за такое
>>++=
> руки бы тебе оторвать за такоеСебе лучше оторви что-нибудь. Небось и от готу бегаешь, как от огня.
Задумка этого кода в том, чтобы прочитать три инта из строчки? Инты разделены пробельными символами?На, держи. Код совсем уж безбажен (как минимум там может быть переполнение unsigned в my_atoi), но навскидку это должно выглядеть так. Длинее чем у тебя, но зато читабельнее: проще понять и проще мейнтейнить
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
static const char *skip_spaces(const char *p) {
while(isspace(*p) && *p != '\0')
p ++;
return p;
}static const char *skip_digits(const char *p) {
while(isdigit(*p) && *p != '\0')
p ++;
return p;
}
// my_atoi: Преобразует первые len байт строки p в unsigned, и возвращает.
// NB: не проверяет корректность строки, это забота вызывающего кода
// Rationale: Библиотечные C'шные функции совершенно убоги, любят менять
// указатели, или хотят '\0' в конце, не умеют сообщать об ошибках,... У каждой
// свои косяки, нет ни одной пристойной. Проще самостоятельно проверить ввод и
// самостоятельно преобразовать.
static unsigned my_atoi(const char* p, size_t len) {
unsigned ret = 0;
for(size_t i = 0; i < len; i ++) {
ret *= 10;
ret += p[i] - '0';
}
return ret;
}
// get_vals: читает из buf три числа, разделённых пробельными символами, и
// пишет их в массив vars.
// Возвращает количество успешно прочитанных чисел.
int get_vals(const char *buf, unsigned var[3]) {
const char *p = buf;
if(buf == NULL) {
fprintf(stderr, "KILL YOURSELF MOTHERFUCKER, BUF CANNOT BE NULL\n");
exit(-1);
}
for(size_t i = 0; i < 3; i ++) {
const char *start = skip_spaces(p);
const char *end = skip_digits(start);
if(start == end)
return i;
var[i] = my_atoi(start, end - start);
p = end;
}
return 3;
}int main() {
unsigned arr[3];
char* bufs[] = {
"1 2 3", " 12\t398746 \n 2397\n\n",
"12345", "1 2, -100"};
for(size_t i = 0; i < sizeof(bufs)/sizeof(bufs[0]); i ++) {
int ret = get_vals(bufs[i], arr);
printf("ret: %d; vals: (%u, %u, %u)\n", ret, arr[0], arr[1], arr[2]);
}
return 0;
}Вывод:
ret: 3; vals: (1, 2, 3)
ret: 3; vals: (12, 398746, 2397)
ret: 1; vals: (12345, 398746, 2397)
ret: 2; vals: (1, 2, 2397)
> while(isspace(*p) && *p != '\0')
> while(isdigit(*p) && *p != '\0')На этом мог бы и закончить очередной сеанс самолюбования.
Уже из этих двух строчек твой уровень в программировании (не только в C) вполне ясен.
>> while(isspace(*p) && *p != '\0')
>> while(isdigit(*p) && *p != '\0')
> На этом мог бы и закончить очередной сеанс самолюбования.
> Уже из этих двух строчек твой уровень в программировании (не только в
> C) вполне ясен.Ну да, ну да. Как же я мог...
Да, да, спасибо. Одна строка, три инта разделённых пробелами, завершается новой строкой. Эта штука вызывается для каждого процесса (которых спавнится тысячи подряд) и инлайнится, и уж точно я хочу избежать isdigits и isspace, как и scanf (довольно вредная дрянь, 99% времени я провишу в ней). А можно же изменять инты, выделенные кем-то другим? Это именно то, что я пытаюсь сделать. Как я ни пробовал выделять инты на хипе (malloc и передать 3 указатель на 3 указателя на инты емнип), компилятор был недоволен (хотя и работало). Добавил assert(vari!=2) на всякий случай (код ожидаемо ломается, когда в конце нет новой строки, такого быть не может потому что малформед строки не случится никогда) -- теперь мы защищены от всего, а то вдруг не сможем последний байт прочитать. :3Кстати, ошибка была вот тут else {fbuf[256-1]='\0'; fbuf[rlen-1]='\0';} я не знаю зачем я поменял rlen на rlen-1 и всё сломал. :/
> Да, да, спасибо. Одна строка, три инта разделённых пробелами, завершается новой строкой.
> Эта штука вызывается для каждого процесса (которых спавнится тысячи подряд) и
> инлайнится, и уж точно я хочу избежать isdigits и isspace,Ты сначала напиши, померь скорость, а потом думай где тормозит. Если ctype.h будет слишком медленным, напишешь свои аналоги. Заинлайнишь. Будет тебе щщасте.
> и scanf (довольно вредная дрянь, 99% времени я провишу в ней).
> А можно же изменять инты, выделенные кем-то другим? Это именно то,
> что я пытаюсь сделать. Как я ни пробовал выделять инты на
> хипе (malloc и передать 3 указатель на 3 указателя на инты
> емнип), компилятор был недоволен (хотя и работало).Эмм... Ты пытаешься избежать isdigits и isspace, но при этом думаешь о динамическом выделении памяти? Если тебе нужна скорость, кучу надо выкидывать в первую очередь.
Но если тебе очень надо, то:
int main() {
unsigned *arr = malloc(3 * sizeof(unsigned));
char* bufs[] = {
"1 2 3", " 12\t398746 \n 2397\n\n",
"12345", "1 2, -100"};
for(size_t i = 0; i < sizeof(bufs)/sizeof(bufs[0]); i ++) {
int ret = get_vals(bufs[i], arr);
printf("ret: %d; vals: (%u, %u, %u)\n", ret, arr[0], arr[1], arr[2]);
}
return 0;
}УМВР
upd.Или тебе нужен массив указателей на инты? Ты в курсе что это _ещё_ хуже, с точки зрения производительности? Если да, то смотри:
int get_vals(const char *buf, unsigned* var[3]) {
/// ...
*var[i] = чему-то-там
/// ...
}int main () {
unsigned **arr = malloc(3 * sizeof(unsigned));
unsigned a, b, c;
arr[0] = &a;
arr[1] = &b;
arr[2] = &c;
/// ...
printf("ret: %d; vals: (%u, %u, %u)\n", ret, *arr[0], *arr[1], *arr[2]);
}
> unsigned **arr = malloc(3 * sizeof(unsigned));Ахаха, прекрати. С таким апломбом рассуждать об "убогих функциях библиотеки C" и второй раз садиться в лужу в простейшем коде (тут и в 132 -> 152) - это надо уметь.
Не первый раз вижу, что за Rust топит индивид, попросту не умеющий программировать на Си. Да и умение программировать вообще здесь под вопросом.
Может, тебе лучше вернуться к психологии?
> Может, тебе лучше вернуться к психологии?Не, мне больше нравится накачивать твоё ЧСВ сверх меры.
>напишешь свои аналогиИх уже есть у меня, не в этом дело, мне вообще не нужны эти вычисления совершенно никак.
Да, мне просто интересно с практической точки зрения.
> unsigned **arr = malloc(3 * sizeof(unsigned));
> unsigned a, b, c;
> arr[0] = &a;
> arr[1] = &b;
> arr[2] = &c;Емнип вот это подвержено оптимизациям компилятора, я когда-то давно напоролся.
А если я хочу вот это arr передать в другую единицу трансляции и модифицировать там? У меня получалось что-то вида **(**(**(* с указателями на инты, но я так подозреваю это тоже на милость компилятора, потому что он очень жаловался и не мог сказать на что и как его удовлетворить. Я так никогда не делал, и у меня совсем не получилось. :(
> Их уже есть у меня, не в этом дело, мне вообще не нужны эти вычисления совершенно никак.Какие вычисления тебе не нужны? Проверка на пробел не нужна? В твоём коде эта проверка тоже есть, почему ты оттуда её не выкинул, если она не нужна?
> Емнип вот это подвержено оптимизациям компилятора, я когда-то давно напоролся.
А какая тебе разница? Если компилятор может это оптимизировать, то значит ты пишешь слишком сложные вещи, и компилятор лучше знает. Если ты пишешь так, как надо, то компилятор не сможет это оптимизировать.
Бывают исключения, когда оптимизации нарушают работу программы, но они редкость и вряд ли ты с ними столкнулся.
> А если я хочу вот это arr передать в другую единицу трансляции и модифицировать там?
Тогда компилятор не сможет оптимизировать. Он и в приведённом случае не сможет, на самом деле.
Ты пытаешься решать несуществующие проблемы. Смотри, код работает? Но ты паришься об оптимизациях и о том, что в каком-то мифическом случае он не сработает. Или ты паришься о том, что в каком-то мифическом случае он начнёт тормозить. Так дела не делаются. Из мифического случая надо сделать реальный, который покажет как код не работает, тогда будет понятно с чем надо бороться. Надо померять производительность, отпрофайлить, и выяснить где и что тормозит. Может он у тебя на чтении с диска будет тормозить больше, чем ctype.h тормозит, а ты перед этим убьёшь несколько часов в то, чтобы сделать быстрее. И зачем это тебе?
Руст скорее всего не дал бы это использовать и ругнулся бы
И Руст как раз минимален, поскольку тоже zero cost abstraction
Ууу. Обращение к элементу массива без проверки его наличия и длины..Нынче за это нередко даже в JS карают
Так прелесть си как раз в том, что от таких проверок можно отказаться, если они совершенно точно не нужны никогда. На постоянные проверки уходит не мало ресурсов.
> Так прелесть си как раз в том, что от таких проверок можно
> отказаться, если они совершенно точно не нужны никогда. На постоянные проверки
> уходит не мало ресурсов.На самом деле, не так уж и много, поскольку тяжёлых вычислений и обращений к апи для этого не требуется.
Просто в вебе может происходить что угодно( даже если на клиенте абсолютно уверен, что где-то какой-то ситуации уж точно быть не может, но данные добываются с бэка, проверку лучше сделать, ведь какая-нибудь бэкендомакака обязательно запилит свой крутой бэк так, что вместо оговорённого заранее массива в т.ч пустого иногда будет прилетать null, что приведёт к вылету даже при попытке просто узнать длину массива )
У веб-кодеров свои представления о "много", это да. Процессоры слишком быстрые стали. Вообще, правило номер один это не доверять клиенту. Немного иная специфика, и если ты экономишь ресурсы тебе разнесут сервер рано или поздно. А на клиента плевать, пусть обновит страницу на актуальную ревизию и всё ок, никакого смысла проверять невозможное на нём.
> У веб-кодеров свои представления о "много", это да. Процессоры слишком быстрые стали.
> Вообще, правило номер один это не доверять клиенту. Немного иная специфика,
> и если ты экономишь ресурсы тебе разнесут сервер рано или поздно.
> А на клиента плевать, пусть обновит страницу на актуальную ревизию и
> всё ок, никакого смысла проверять невозможное на нём.Частоиспользуемые методы что на стороне браузера, что на стороне гибридных приложений, обычно JIT-ятся и проверка содержимого какой-либо переменной нередко состоит всего лишь из нескольких машинных инструкций.
Но, кроме шуток, на каком-нибудь Си можно позволить себе наговнокодить несравненно больше, чем на JS, поскольку компилируемые ЯП прощают несравненно бОльшие огрехи в оптимизации.У бэкендеров - недоверие к фронтендерам( поскольку с клиента что угодно прилететь может ), у "фронтендеров" - к бэкендерам( поскольку с бэка черти что прилететь может, нередко вообще не соответствующее договоренностям о структуре ответов ).
Поэтому в конторах, в которых ранее иногда работал, бэкендеров, которые нередко не способны были сделать корректное удаление данных( иначе, удаляется, к примеру, пользователь, а его предложения о товарах - выдаются как ни в чем не бывало, только user: null и любые попытки сделать заказ и проч вываливаются с ошибкой, но уже со стороны бэка ) или выдачу данных, согласно какой-то схеме, довольно часто под задницу выпинывали, поскольку предрелизное тестирования могло затянуться на недели из-за неведомых сбоев и ошибок, 95% которых приходилось на некорректную выдачу с сервера. Но, к сожалению, подобных бэкендеров на фрилансе больше половины.А потом - начал разрабатывать мобильные приложения, а привычки остались
Все-таки, из-за криворуких бэкендописателей не должны страдать конечные пользователи, у которых приложение "валится", к примеру, при пустой коризне( ведь "гений" выдает в качестве списка товаров null вместо пустого массива ).
Но, хотя бы какую-то минимальную проверку данных в плане соответствия структуре, особенно, тех, которые прилетают с АПИ, делать необходимо вне зависимости от ЯП и проч.
Лол, так почему он её так и не занял?
С++ развиватсяв ногу со временем, почему это легаси? а вот наоборот легаси это некогда современный взгляд на через чур абстрауцию работы с данными. это легаси.
Настолько развивается, что до сих пор нет нормальной системы сборки без позорного синтаксиса и официального пакетного менеджера
Даже модулей нигде нет и не будет ещё лет 10
C++ похож на бабулю, которая пытается одеваться в молодёжные шмотки, но в итоге косплеит колбасу
Без обид, сам пишу на плюсах достаточный срок, и до сих пор на них остаюсь из-за Qt
без официального пакетного менеджера - а что мешает либу так прикрутить? выбрал либу, скачал нужную версию. Вы хотите программу как сайт писать, в шапке указать 100500 ссылок на js и css ?Модули , хз в QT имеется.
С++ на бабулю? )) только вот работает эта бауля как юнец - спортсмен, а тот же питон как дед пирдет. но это ладно.
qt прикольная тема, если бы не она то да , кросплатверненные гуи наверное бы лучше было бы писать на электроне или флаттере. но это фрэйморк. Но если бы стояла бы задача написать бэк для хайлоад то я бы использовал си.
>Даже модулей нигде нет и не будет ещё лет 10В C++20 завезли.
Затем, что современный С++ - это лютый пипец на 2000 страниц стандарта. Такое ощущение, что туда пихают все, что приходит комитету в голову. Выучить это нереально и уж конечно на все 100% этот монстр использоваться не будет. Ну так и нафига он нужен, если есть более компактные и удобные языки?
Аминь.
Ты так пишешь, будто современный Ржавч лучше. Стандарта нет, но для языка, который кичится отсутствием UB, это только показатель его недоделанности. Синтаксис страшнее самых страшных плюсовых шаблонов, а поддержка ООП при этом даже не заявлена.
Да и нафиг не надо ООП, я в нем разочаровался, когда попробовал ФП в лице Erlang. Синтаксис нормальный, страшно только поначалу. А то что стандарта нет... Видели мы эти стандарты, 30 страниц стоит 11 килорублей, в общий доступ никто не выложил. Спрашивается, на кой х мне этот стандарт, если я его прочитать не могу.
Ага, сделать софтинку, типа какого CAD'а, без ООП - мазохизм.
И как же ж их делали до появления ООП... Наверно, мазохистами все были.
В те времена они ещё были такие, что умещались в 640 кбайт или меньше. И да, мазохисты, на разработку тратили гораздо больше человекочасов.
И при этом софт был стабильнее и шелковистее
И то, что есть в C++, Java и других монстрах - не ООП в том виде, в каком оно задумывалось. В этом смысле как раз Erlang со своей моделью акторов ближе к оригинальной идее ООП.
Может быть, но Erlang, мягко говоря, не взлетел дальше телекоммуникаций.
И, вроде, считается, что самое правильное ООП было в Smalltalk.
Расскажите это Facebook, чьи сервера WhatsApp поголовно на нем. Или тем, кто использует RabbitMQ или cowboy, написанные на Erlang. Я сейчас пишу на нем и проект настолько далек от телекоммуникаций, насколько это можно, но близок к блокчейнам.
эрланг хорош, но ведь фейсбук не выбирал его, это выбор изначального разработчика
Ну так я же и написал, кроме телекоммуникаций. Что не так-то?
> Erlang, мягко говоря, не взлетел дальше телекоммуникацийЯ привел примеры не из сферы телекома, где есть Erlang.
Еще примеры, и там тоже не только телеком: https://www.erlang-solutions.com/blog/which-companies-are-us...
Амазон и Yahoo вроде еще что-то на Erlang'е делали.
Так, блин, и не используйте что вам не надо. Туда добавляют то что не хватало. В C++14 дали возможность в lambda'ы прокидывать значения, как в std::bind, make_unique и т.д. В C++17 fold expression что очень многие вещи упрощает, плюс теже constexpr if, плюс инициализация в if'е.
> Так, блин, и не используйте что вам не надо.Вот я и не использую С++
Всех программистов уже выгнали за то что не смогли нормальный язык сделать, а они все равно новые релизы это ненужно пилят.
Мне так нравится, что старым сишникам от этого неприятно. Казалось бы ну пилят и пилят, но на опеннете каждый раз такая боль у комментаторов.
просто пользователи раста еще более помешанные паломники растоманства чем си. ну и их вечное хвастовство о превосходстве и безопасности раста, хотя если взять этот самый раст куда нибудь в системщину или похожие ниши он становится опаснее с++.)) вот и не любят их.
Если пользователи чего-либо за бесплатно хвалят и тем более защищают нечто - это очень весомый довод в пользу этого нечто, не правда ли?
Мне вот любопытно, те кто хейтят язык, они реально на С/C++ писали что-то сложнее, чем хелловорлд? И почему достаточное количество людей, которые писали -- не хейтят.У Раста есть проблемы, но они мало связаны с самим языком.
Нет простой связи c C++, нельзя просто взять и сделать замену старым либам.
Интерфейсы из коробки не умеют работать с нехваткой памяти, иногда это важно.
Нет стабильного ABI в рамках платформ, нельзя распространять бинарные либы.
Компилятор пока не такой крутой, как для C.
Выстроить код так, чтобы оптимизация под SIMD была сама собой -- такая же магия, как и для плюсов.
Наверняка есть другие реальные проблемы.Но вот этот реальный хейт на язык, для которого математически доказано, что весь безопасный код безопасен в работе с памятью, и что если с ней есть неуловимые проблемы, то искать их надо строго внутри unsafe -- я не могу понять.
Серьёзно, Майки пытались запилить свой клон, Гугол пытается понять, можно ли его плавно внедрять в свой хром, в Линукс впилили поддержку модулей на расте. Однозначно они все повелись на хайп, особенно Линус, да.Короче, мнение всех, кто не сможет сказать, чем он конкретно хуже C+± -- ничего не стоит.
>математически доказано, что весь безопасный код безопасен в работе с памятью, и что если с ней есть неуловимые проблемы, то искать их надо строго внутри unsafeАга, как скажешь. Если в программе есть UB, то оно может проявиться где угодно. Неопределённому поведению плевать safe тут код или нет.
>>математически доказано, что весь безопасный код безопасен в работе с памятью, и что если с ней есть неуловимые проблемы, то искать их надо строго внутри unsafe
> Ага, как скажешь. Если в программе есть UB, то оно может проявиться
> где угодно. Неопределённому поведению плевать safe тут код или нет.Всё верно. Но причины UB по памяти искать можно чисто в небезопасных блоках. Заметим, только по памяти. Проблемы с многопотоком компилятор ловит далеко не все. А часть штук типа signed overflow так и не считаются за UB, но если не знать -- ничто не поможет, кроме отладочной сборки, которая не всегда возможна из-за низкой скорости.
Там только на прошлой неделе исправили уб с флоатами, какие унсафе? Компцерт больше доверия.
> Там только на прошлой неделе исправили уб с флоатами, какие унсафе? Компцерт
> больше доверия.Ну да. Исправили (если речь идёт о сведении всех флоатов больше 255.0 к 255 u8, ну и к нулю для всех меньше нуля). И добавили явный unsafe для тех, кому скорость важнее. А В C/C++ оно как было undefined, так навеки и останется: https://wandbox.org/permlink/BT5leyjGx5TZhmFh
Вопрос в приоритетах создателей, и у комитета C++ пока по ощущениям в приоритетах новые плюшки без потери обратной совместимости, в то время как у Раста в приоритете явное разделения безопасного и опасного.
> Нет простой связи c C++С C достаточно простая. А с C++ мало у кого в целом есть простая связь из-за шаблонов, классов и этого всего
> сделать замену старым либам
На Расте даже замену либы C видел)
Всё возможно, что совместимо с C> нельзя распространять бинарные либы
Разве? У меня не было с этим проблем, включая на Андроиде (интеграция либы на расте в плюсовый Qt-проект)
Можно примеры? Интересно чего стоит опасаться> Компилятор пока не такой крутой, как для C.
LLVM и в Африке LLVM)
(да, я понимаю, что речь не о том, но всё же)
LLVM и в Африке не нужен.
(да, я понимаю, что речь не о том, но всё же)
> (да, я понимаю, что речь не о том, но всё же)"Но всё же" смолчать никак не можешь? Такая острая тема, так подгорает, что даже понимая оффтопичность её, молча пройти мимо никак не можешь?
А ты для чего упомянул?
> А ты для чего упомянул?Потому что для меня больная тема -- это анонимы, которые не могут молчать. Точнее, это частный случай проявления темы: вообще забавно наблюдать, когда людьми начинают рулить их убеждения и они с этим ничего не могут поделать.
>> Нет простой связи c C++
> С C достаточно простая. А с C++ мало у кого в целом
> есть простая связь из-за шаблонов, классов и этого всегоУ Julia есть вроде.
>> сделать замену старым либам
> На Расте даже замену либы C видел)
> Всё возможно, что совместимо с CПро C я молчу, там просто.
>> нельзя распространять бинарные либы
> Разве? У меня не было с этим проблем, включая на Андроиде (интеграция
> либы на расте в плюсовый Qt-проект)
> Можно примеры? Интересно чего стоит опасатьсяОпять же, про C я молчу, там чёрт знает когда ABI стабилизировался. А вот просто так, не через С связать бинарную библиотеку раста с другой библиотекой или экзешником нельзя, сколько я знаю. Только исходники. Да, я понимаю, кому нужны либы без исходников, но такие платные штуки есть для C/C++ и микроконтроллеров. Для раста так вроде нельзя:
https://users.rust-lang.org/t/compiling-a-rust-library-as-a-...>> Компилятор пока не такой крутой, как для C.
> LLVM и в Африке LLVM)
> (да, я понимаю, что речь не о том, но всё же)Не бэкэндом единым жив компилятор. И для части чисто растовых оптмимизаций уже пилят mid-level IR:
https://blog.rust-lang.org/2016/04/19/MIR.html
Я писал и пишу. Большие диагностические вещи. Я пробовал элементарно перевести интереса ради на раст. Не то чтобы у меня не получилось. Но я не получил удовольствия от языка. В начале выглядит здорово и многообещающе. Но стоит разрастись проекту до хотябы 50-ти файлов и начинается ад.Нет инфраструктуры для раста. И не будет. Дальше микро веб сервисов и лабораторных он не пойдёт.
Ну вставочки небольшие "типа" безопасные можно.
> Я писал и пишу. Большие диагностические вещи. Я пробовал элементарно перевести интереса
> ради на раст. Не то чтобы у меня не получилось. Но
> я не получил удовольствия от языка. В начале выглядит здорово и
> многообещающе. Но стоит разрастись проекту до хотябы 50-ти файлов и начинается
> ад.О, реальный опыт, это ценно! Можешь рассказать, в чём именно был ад, что есть или чего нет в Расте и C/C++, что делает его менее удобным в работе с 50+ файлами?
> Нет инфраструктуры для раста. И не будет. Дальше микро веб сервисов и
> лабораторных он не пойдёт.Возможно. Но тоже не факт. Вряд ли кто думал, что питон как язык для data science. Чего уж там, что он вообще взлетит, он же старше Java, но долго проплывал мимо радара.
> Ну вставочки небольшие "типа" безопасные можно.
Даже это уже неплохо.
> О, реальный опыт, это ценно! Можешь рассказать, в чём именно был ад,
> что есть или чего нет в Расте и C/C++, что делает
> его менее удобным в работе с 50+ файлами?Хорошо. Поделюсь. Не тролинга ради, и не ради поливания грязью. Только то через что прошёл сам.
Прошу заметить, всё изложенное ниже моё исключительно субъективное мнение, никоим образом не претендующее на объективность.
Коротко что это из себя представляет. Это большой комплекс диагностического оборудования и софта к нему. Облать аутомотив. Куча платформ и контроллеров. On board встроенных систем и т.д. управление из Linux, Windows, MacOs, iOS, Android.
Основной код написан на C++, но да, такой код (писан до меня) показать человеку без опыта и он убежит от C++ далеко и надолго. Но не об этом.
Жизненный цикл того оборудования подошёл к концу. Т.е. его будут менять (выбирается производитель сейчас). Встал вопрос о том чтобы перенести весь этот код на новое оборудование чему я воспротивился и повезло что начальство удалось убедить. Началась разработка всего с нуля.
И вот тут на сцену выходит Rust. Не потому что я верю в его безопасность (более того я знаю что это нет) и превосходство. Я очень очень комфортно с C++. Rust я пробовал поковырять но это всё ниочём. Нельзя почувствовать язык без чего-то серьёзного. Поэтому и было принято решение. Параллельно с C++ вести разработку на Rust. Некоторые идеи из Rust мне понравились, поэтому а почему нет?
И так.
Начиная делать прототипы, проводить какие-то эксперименты с тем как представлять данные, передавать по сети, как описать порядка 500 параметров онита, однотипных, отличающихся всего-то смещением и размером (я не люблю парсинги, мне нравится мапить структуры на память, это быстрее с точки зрения ресурсов).
Тут всё было хорошо, надо понимать что думать в рамках C++ для Rust не подходит. Не привычно, но ничего, так должно быть. Даже интересно смотреть на задачу с разных сторон.
И так тут всё хорошо. Но и преимуществ перед C++ не видно. Порядка 50-ти прототипов. Прототипы не большие, по 5 - 10 файлов.
Начинаем собирать всё это в месте. И вот начинается. Это нормальное явление рефакторинг в начале проекта. Переименовать что-то сразу во всём проекте (по контексту).
И тут выяснятся что в случае с C++ это задача решается одним хоткеем. В случае с Rust я встречаю первую проблему. Нету IDE или чего-то что может это делать. Я пользовал kate для написания кода Rust. Синтаксис подствечивает и он уже не такой страшный как кажется в начале. Но понятное дело дальше оно ничего не умеет. Смотрим дальше, VSCode? Во первых это блевотня. Ну да ладно, поставлю. И так, оно тоже не может ничего кроме подсветки синтаксиса. Оказывается надо ставить плагины. Начинаем ставить, одно тянет другое, третье, десятое. Фух, поставилось. Ан нет. Конфликты, в форумах есть ответ. Я то почитал, можно решить. Но я понял что коллегам которые потом со мной будут работать я этого делать не буду. Я забуду. Не хочу. Выносите. Что там ещё? Ещё какой-то плагин к эклипсу. Спасибо, переодически падающий эклипс на плюсах, с отваливающейся индексацией и прочими граблями - нет, не надо. Ещё какие-то жавовские поделья в которых тоже только в виде плагинов. С неделю поковырялся и понял что ну просто нету ничего. Остановился на emacs, так как чуть с lisp знаком и при наличии времени и желания дописываю ту поддержку что есть сейчас. Но это медленно, времени не так много. Чуть допилил стало чуть проще. Но опять таки, это моя наколенная поделка.
Вторая проблема - компиляция. Для C++ есть куча всего что поддерживает парсинг выхлопа компилятора. Т.е. у тебя ушибка в коде? перешел на неё, нажал Enter и оказался в строчке ошибки. В случае с Rust - нет. Надо смотреть самому в выхлоп и потом открывать этот файл в нужной строке, это время, это не удобно. Да в emacs потом допилилось. Но опятьтаки, надо допиливать.
Сейчас ещё активная стадия не наступила, по этому я стараюсь держать код на Rust и на C++ в одинаково актуальном состоянии. Но по факту на C++ даже благодаря инструментам быстрее. Но бывает так что код на Rust отстаёт на неделю. Почему? тот-же рефакторинг. То что я сделал в C++ благодаря среде одним хоткеем в одно мгновение, в случае с Rust мне надо либо руками с грепом бегать, либо садиться допиливать emacs, или сидеть опять перебирать кучу недоделанных редакторов, форумов про поддержку раст в разных средах. На это просто нет времени если честно. Проект растёт. И он с нуля, и ещё не покрыл и 10% от того что должен.И проект не монолит, просто там много всего. Вот и получается, пока из чистого интереса я стараюсь держать этот проект на двух языках сразу. Кто победит покажет время.
Как минимум я узнал много нового. Но пока увы, на практике, Rust пока проигрывает. Удовольствие от создания чего-то на языке получаешь не только от языка, но и от того что его окружает. В том числе среда которой пользуешься.
Ну и да, по самому языку, честно вот функционала уровня шаблонов не хватает. Не надо тут кидать гнилыми помидорами. Я не предлагаю пихать шаблоны везде где не попадя. У них своё место. Во всём проекте что уже сделан у меня всего 3 шаблона. Но они так здорово экономят время, время на написание, время на отладку. Да и код меньше. Всего должно быть в меру. Где-то шаблоны это сила, где-то это будет фууууу.
И конечно всё это должно будет потом общаться с пользователем. Т.е. должны будут быть пользовательские интерфейсы. Увы, у Rust Ui toolkit очень печален. Я сейчас активно пробую биндинг на Qt. Посмотрим что из этого выйдет буквально через 2 месяца.
Я не говорю что я хорошо знаю Rust, более того я могу сказать что знаю его ну в лучшем случае средне. Часто приходится смотреть документацию. Кстати тоже момент, я не люблю лазить в браузер за документацией. Ну это не удобно и долго. Гораздо быстре нажать F1 и увидеть справку по команде, удобнее нажать ctrl+space и увидеть параметры с описанием. Но нет, у Rust с этим проблема пока.
Не предлогайте мне только этот ужас VSCode, эклипсы, интелиж и прочие жавовские поделья. Два тулкита в Linux, это Qt и Gtk, весь остальной мусор можете оставить себе если вас устраивает. Поэтому пока emacs, но функционал оставляет желать лучшего. Словно на 20 лет назад отбросило по возможностям.
То есть это проблемы с инструментами и библиотеками - что ожидаемо, а не с самим языком.
В Rust есть макросы - можно сгенерировать что угодно. Они чем то не подходят для замены шаблонов?
> То есть это проблемы с инструментами и библиотеками - что ожидаемо, а
> не с самим языком.Да, я об этом и говорил, не с языком, с инструментами. То что я называю инфраструктурой.
> В Rust есть макросы - можно сгенерировать что угодно. Они чем то
> не подходят для замены шаблонов?Мне пока не удалось получить той-же гибкости что в C++, я не исключаю что я не до конца понял всё. На шаблоны в C++ у меня тоже ушло много времени чтобы научиться их правильно готовить. Несколько лет прежде чем пришло понимание. В Rust я зная что далеко не всё осилил. Но мне интересно, я в embedded с головой и руками, поэтому мне интересно. Если кому будет интересно продолжение, то я расскажу и об опыте связки Rust + Qt. Таки от интерфейса взаимодействия с пользователем не уйти.
> Если кому будет интересно продолжение, то я расскажу
> и об опыте связки Rust + Qt.
> Таки от интерфейса взаимодействия с пользователем не уйти.Определённо будет!
> Определённо будет!Ок, но тогда видно это уже будет не комментарий к новости о новом Rust :)
Вот! Вот хейт^Wфрустрация здорового человека! Спасибо!Итак, проблема инструментов серьёзная, в по-настоящему большом проекте скорость разработки резко падает. Как бы и не проблема языка самого по себе, но пользоваться им пока себе и работодателю дороже.
Требуются большие компании, которые могут позволить себе всё это допилить, и для которых ключевые преимущества языка перевесят. Мелким пока рано.
В ту же канву биндинги к популярным GUI-фреймворкам. Мало, недокументировано толком.
Про язык были упомянуты нехватка шаблонов. В Rust есть дженерики и макросы, которые должны полностью покрывать область применения шаблонов. Тем интереснее узнать, что же шаблоны могут, что сочетание макросов с дженереками нет. Даже если это вопрос удобства. Особенно если это вопрос удобства.
EDIT: уже прочёл ответ в другом комментарии. Принимается.
> Не потому что я верю в его безопасность (более того я знаю что это нет)И это тоже интересно узнать. Это что-то в духе "В теории всё круто, но на практике полно unsafe-кода и ошибок в самом компиляторе"? Или "Да, можно и безопасно, но тогда производительность адски проседает"?
Ещё раз спасибо! Наконец-то конструктивная критика вместо тупого "Rust говно, патамушта не C".
> Итак, проблема инструментов серьёзная, в по-настоящему большом проекте скорость разработки
> резко падает. Как бы и не проблема языка самого по себе,
> но пользоваться им пока себе и работодателю дороже.Ну вот emacs я пилю для себя, но коллегам emacs далеко не всем зайдёт, будет время, пусть плагином но попробую к своей основной среде что-то сделать.
> Требуются большие компании, которые могут позволить себе всё это допилить, и для
> которых ключевые преимущества языка перевесят. Мелким пока рано.
> В ту же канву биндинги к популярным GUI-фреймворкам. Мало, недокументировано толком.
> Про язык были упомянуты нехватка шаблонов. В Rust есть дженерики и макросы,
> которые должны полностью покрывать область применения шаблонов. Тем интереснее узнать,
> что же шаблоны могут, что сочетание макросов с дженереками нет. Даже
> если это вопрос удобства. Особенно если это вопрос удобства.Я не говорил что я знаю всё о раст, в C++ я как рыба в воде, в Rust всего-то год. Мне не удалось пока добиться функционала того что называется variadic templates. Не думаю что сюда уместно привести какой-то мой пример который я не могу покрыть.
Я решил вопрос, но мне не показалось это так элегантно как на C++. Опять. Я далеко не эксперт в Rust. Может найду пример или что-то и смогу сделать так-же красиво и просто как в C++. Мне честно хотелось бы.
>> Не потому что я верю в его безопасность (более того я знаю что это нет)
> И это тоже интересно узнать. Это что-то в духе "В теории всё
> круто, но на практике полно unsafe-кода и ошибок в самом компиляторе"?
> Или "Да, можно и безопасно, но тогда производительность адски проседает"?Дело не в unsafe. Дело в том что в современном c++ уже нет тех проблем от которых якабы надо людей спасать. А то что у программистов голова не на месте ни один язык не спасёт. Если ты нагавнокодил ерунды, то уже не имеет разницы на каком языке. То что делает компилятор Rust, как раз пытается от гавнокода защитить, но не выйдет. Тут надо понимать, если дать обезьяне гранату..... Люди теряют бдительнось, думая что компилятор Rust их спатёт. На деле же я делал тесты, почти везде современных C++ и Rust имеют одни и те же проблемы. А именно гавнокодеры. Уже нет в современном C++ пробелм с памятью, нет проблем с выходами за границы и всего того от чего защищает Rust.
При этом как уже писал, вся реклама вокруг вводит людей в заблуждение, они расслабляются, внимательность рассеивается, перестают думать, пологаются на компилятор. Это то что я видел на своих коллегах которые решили тоже поучаствовать в прототипах на Rust.
> Ещё раз спасибо! Наконец-то конструктивная критика вместо тупого "Rust говно, патамушта
> не C".Я бы вообще с удовольствием пообщался с кем-то кто в Rust ну лет так 5, кто хорошо знаком. Фик с ними с средами. У меня опыт в C\C++ у меня ничего не падает, меня не надо защищать от этого, у языка другой подход, я люблю другие подходы, я вообще люблю разные взгляды на одну и ту-же проблему.
>>В начале выглядит здорово и многообещающе. Но стоит разрастись проекту до хотябы 50-ти файлов и начинается ад.интересно послушать в чём заключается ад, можешь рассписать?
> интересно послушать в чём заключается ад, можешь рассписать?Чуть выше написал, копипастить уже не буду.
> Мне вот любопытно, те кто хейтят язык, они реально на С/C++ писали что-то сложнее, чем хелловорлд?вот точно такие же мысли. Под каждой новостью про Rust лютый срач. И подавляющее большинство, по-моему, просто сотрясает воздух.
Дурачек, Линуса уже не спрашивали че он тпм хочет, просто взяли и запилили
Так это не сишники, а школота строчки кода ни на чем не написавшая.
Зачем школоте поддерживать си вместо чего-то нормального?
школота посмотрит на код си и код раст и скажет что код раст только для растаманов))) нет ну реально он весьма специфичен.
Та ладно, C объективно такая же мутатень, только в своем
Не принижаю достоинства ни C, ни Раста, но вот просто как есть
Так это никакие не старые сишники, а студенты с хеллоуворлдами
Интересное наблюдение. При том, что никто никого не выгнал, а перевели фактически в Rust Foundation, что как раз просто замечательно ибо зависимость от компании - ну такое себе. Go вон полностью зависим от Google и как Google захочет, так и будет развиваться. Захочет - закроет обратно, и миллионы вебмакак останутся без работы.
Это такой же отстойник ненужных проектов как и Апач Фаундейшн. У Раст Фаундейшн даже инвестора нет, а на 250 программистов им надо не меньше 25 млн долларов в год. Которые им никто не даст.
При том, что Растом активно интересуются Microsoft и Google (при всей моей нелюбви к ним), конечно, им никто не подаст.
Языку десятый год. И им только интересуются, но не используют. А все эти новости где один программист из Гугла затестил Раст сразу в среде растошкольников выливается в то что Гугл полным составом перешел на Раст.Никто на него не перешел и нигде не использует успокойтесь уже.
Детка, я спокоен как фугас. И школу закончил в далеком 2004. А то, что им интересуются (и не один программист), показывает только то, что язык наконец дорос до продакшена и что в традиционных языках интересующиеся разочаровались.
И собственно, меня мало волнует, кто и по какой причине им интересуется. Я не фанат ни мелкомягких ни корпорации зла - они уроды и лицемеры. Однако ж гугл интересуется им, а не кидается хромиум переписывать на своем Го.
Лично я интересуюсь Растом, потому что он мне нравится. Точно также как нравятся Erlang и Lisp, которыми никто не интересуется, и нравится С, чьи мнимые фанаты под каждой новостью про Раст ссут кипятком от негодования.
>Растом активно интересуются MicrosoftУ них свой Verona. Похожий, но не Rust.
когда, интересно, тип f16 добавят в rust?
А надо? Мне кажется, это что-то очень-очень специальное, не? Так ли это надо в языке, если можно сделать в библиотеке?
есть сомнения, что, как минимум, в embedded это очень актуально; в игроделании тоже используется для экономии ресурсов
> есть сомнения, что, как минимум, в embedded это очень актуально; в игроделании
> тоже используется для экономии ресурсовЯ сомневаюсь насчёт embedded: это нужна железная поддержка этих самых short float, и это должно быть лучше, чем fixed point, который реализуется на обычной арифметике. То есть, у short float есть свои перки, типа диапазона +/-65k при 11 значимых двоичных цифр, но и всё же. Мне кажется, довольно специальная ситуация нужна. Вполне возможная ситуация, но очень редкая. (Впрочем, если ты можешь привести конкретный юзкейс, с которым столкнулся, я с удовольствием почитаю, для расширения кругозора.)
А игроделам это слабо поможет, по-моему. 11 двоичных цифр точности, это примерно как три десятичных. Несколько операций над числами, и вот у тебя уже 5-7 двоичных цифр точности, то есть всего пара десятичных. Ты получишь 1.46, но 0.06 уйдёт в погрешности вычисления, то есть результат будет неотличим от 1.5. Может и можно найти какие-то задачи, где этого будет достаточно, но я чёт как-то затрудняюсь предположить. В графическом коде (куда я иногда заглядываю) я вижу чаще f64, чем f32.
> можно найти какие-то задачи, где этого будет достаточно, но я чёт как-то затрудняюсь предположить.Текстурные координаты, нормали и прочие значения, практически никогда не выходящие за пределы диапазона [-1, +1]. На стороне CPU что-то с ними считать незачем, а в шейдерах они автоматически расширяются до f32/f64 при более эффективном использовании памяти и кэшей за счёт вдвое меньшего исходного размера. Игроделы ради этой эффективности иногда и не так изворачиваются (например, для единичных векторов типа нормалей даже f16 избыточен — можно весь вектор упихать в 32 бита с отклонением менее 0.1°, сравнение разных способов упаковки единичных векторов есть в статье на http://jcgt.org/published/0003/02/01/). :)
В нейронных сетях используются
> В нейронных сетях используютсяА, да, вот этим может помочь, точно. Чисел много, но хрен его знает сколько точности не нужно.
А есть аппаратные FPU, которые могут в такие вещественные числа?
В POWER10 есть аппаратные float16 и bfloat16
The Arm architecture provides high-performance and high-efficiency hardware support for floating-point operations in half-, single-, and double-precision arithmetic.
Чисел много, и что там в этих числах - безразлично. Всё равно шум на выходе.
На выходе булева переменная - узнал/не_узнал (фейс Онанима).
Плохо ты знаешь нейросети. На выходе тебя ждёт "да нет наверное". И этот ответ сравнивая с константой выбранной программистом трактуется как 0 или 1.
Нечёткая логика тоже логика.
Женская логика это тоже логика, но сильно отличающаяся от строгой, булевой логики. Нейросети они такие же. Никогда не дают чёткого утверждения да или нет, поэтому логика построенная на них и называется нечёткой.
> На выходе булева переменная - узнал/не_узнал (фейс Онанима).И значение этой переменной соответствует в лучшем случае шуму океанов Марса.
> А, да, вот этим может помочь, точно. Чисел много, но хрен его знает сколько точности не нужно.От себя добавлю немного: в нейронках может точность нужна и повыше, но вот в научных расчётах оперируют точностью до порядка. Наверняка есть области, в которых три значащие десятичные цифры -- это вполне себе нормальное значение. Однако я давно не встречал, чтобы кому-то было f16 нужен. Учёные народ не замороченный, херачат максимальный размер как правило и ждут более производительного кластера.
>> А, да, вот этим может помочь, точно. Чисел много, но хрен его знает сколько точности не нужно.
> От себя добавлю немного: в нейронках может точность нужна и повыше,
> но вот в научных расчётах оперируют точностью до порядка.В научных расчётах _иногда_ оперируют точностью до порядка. Я часто в уме такого рода расчёты провожу, чтобы прикинуть что к чему. Очень удобно.
> Однако я давно не встречал, чтобы кому-то было f16
> нужен. Учёные народ не замороченный, херачат максимальный размер как правило и
> ждут более производительного кластера.Какая бы точность не была нужна на выходе, если ты считаешь дифуру, то в этих расчётах могут быть тысячи шагов по дискретизированному времени, например, и каждый шаг привносит ошибки округления, потому что машинное представление числа неидеально. Ошибка накапливается, и поэтому часто расчёты проводятся с заведомо большей точностью, чем требуется от конечного результата.
> Ошибка накапливается, и поэтому часто расчёты проводятся с заведомо большей точностью, чем требуется от конечного результата.Вот к чёрту теоремы о сходимости, да? В подобных расчётах смотрят не на эволюцию, а ищут стационарное решение. Можно уменьшить шаг по времени и удовлетворить тем самым условия сходимости. Можно увеличить дискретность эйлеровской сетки. Считать будешь дольше, зато на меньших ресурсах, и придёшь к тому же результату.
> В научных расчётах _иногда_ оперируют точностью до порядка.
Такие расчёты проводятся весьма часто.
>> Ошибка накапливается, и поэтому часто расчёты проводятся с заведомо большей точностью, чем требуется от конечного результата.
> Вот к чёрту теоремы о сходимости, да?Теоремы о сходимости чего? Даже если ты возьмёшь заросшую мхом проблему трёх тел, даже там есть элементы хаотического поведения, когда небольшие флуктуации вырастают в большую разницу. Не, ну ты прикинь, вот есть у тебя реккурентное соотношение (x[n+1], x'[n+1]) = F(x[n], x'[n]). Ты берёшь и считаешь 100k шагов, чтобы промоделировать поведение тел в Солнечной системе на 10 лет вперёд. И чё? Что и куда у тебя будет сходится? Твоя реккурентная формула будет чем дальше, тем больше расходится с дифурой.
> В подобных расчётах смотрят не
> на эволюцию, а ищут стационарное решение.Естественно. Никому не интересно предсказывать движение тел СС, всем интересны исключительно стабильные орбиты. Кстати, гравитационные дифуры тоже отличаются тем, что там иногда мелкие изменения приводят к большим последствиям. И это ты не решишь никак без увеличения точности расчётов.
> Можно уменьшить шаг по времени
> и удовлетворить тем самым условия сходимости. Можно увеличить дискретность эйлеровской
> сетки. Считать будешь дольше, зато на меньших ресурсах, и придёшь к
> тому же результату.Хехе. Чем меньше шаг, тем больше шагов. То есть, если бы ты считал, оперируя вещественными числами, то точность у тебя бы расла несомненно. Но поскольку на каждом шаге, после каждой арифметической операции, ты округляешь результат, то количество округлений растёт, а значит растёт и погрешность. То есть тут всё неоднозначно. Даже если при окрулениях у тебя не будет систематического bias'а, и ошибка будет случайной, то вообще-то случайные брождения, если мне память не изменяет, сдвигают на расстояние l*sqrt(n), где l -- это длина одного случайного шага, а n -- количество таких шагов. В многомерных случаях будет сложнее, но ты сам можешь посмотреть.
>> В научных расчётах _иногда_ оперируют точностью до порядка.
> Такие расчёты проводятся весьма часто.Ты пытаешься доказать мне, что эти расчёты надо проводить в f16? Где диапазон +-65k? Где 5 бит под показатель степени двойки? Не, если всё прологарифмировать заранее, перейти в логарифмическую шкалу и заменить умножения сложениями, так чтобы f16 представлял бы собой тот самый порядок, с точностью до которого мы считаем, то может и ничего так, покатит. Но не проще ли взять f64, посчитать как есть и прологарифмировать после?
Или ты знаешь примеры, где эти расчёты с точностью до порядка нагружали систему так, что имело смысл подбирать специальное железо со специальными какими-то типами данных? Расскажи о них, всем будет интересно и познавательно.
Да вообще, выкинь всё вышенаписанное и расскажи мне о тех научных вычислениях, которые ты проводил в f16.
crate halfзачем прямо в язык-то? чтобы было?
зачем i128/u128 в rust добавили?
Ну это ещё можно понять. Например, адреса IPv6 128 бит.
В сишке это обернуто в структуру.
Любому нормальному комментатору с опеннет ясно что недоязык с ужасным непонятным синтаксисом, небезопасный (потому что есть unsafe блоки), на котором даже не смогли браузер написать, не должен существовать. Все нормальные программисты пишут на Си
Лол, чем оне тебе не понятен? Сложнее чем JavaScript ты хотел сказать?
> Лол, чем оне тебе не понятен? Сложнее чем JavaScript ты хотел сказать?Не ему не понятен. Он говорит про такую мифическую личность, как "нормальный комментатор opennet".
Все нормальные программисты пишут на ассемблере.
А чего не в машинных кодах сразу? Непорядок, ненастоящие программисты. Реально крутые программисты пишут в машинных кодах.
Прикол в том, что unsafe всё еще безопаснее C
А Раст скорее конкурент C++, и в чем-то плюсы еще надо догонять. C по удобству он уже превосходит, хотя бы даже за счет трейтов (подобие ооп вместо беспощадных костылей C), карго и serde.
>и в чем-то плюсы еще надо догонятьВот это точно. Догонять ему C++ в объектности, чтобы не подобие было, а полноценно.
Ну ООП в чистом виде не надо, трейты гибче, но пока иногда немного _недостаточно_
Да фиг с ней, с объектностью. Банальные user-defined literals не помешали бы.Когда работаешь с углами и расстояниями, набивать 120_deg и 1_cm, чтоб оно само переводилось в радианы и метры очень удобно. Была инициатива, но уже 1,5 года как заглохла:
https://internals.rust-lang.org/t/pre-rfc-custom-suffixes-fo...
А в чем проблема сделать такой атрибут и положить во внешний крейт. Кому надо, тот подключит. Зачем это тащить в язык?
> А в чем проблема сделать такой атрибут и положить во внешний крейт.
> Кому надо, тот подключит. Зачем это тащить в язык?А что уже ввели саму возможность? Как именно сделать аналог этому:
constexpr long double operator"" _deg ( long double deg )
{
return deg * 3.14159265358979323846264L / 180;
}Если что, в плюсах этих _deg и _mm нет, да и литералы времени (1s, 1000ms, 1000000us) или преобразования C-строки в std::string ("пример"s) тоже в стандартной библиотеке, а не прям нативно.
Не надо. ООП в том виде, в каком оно есть сейчас давно пора закопать.
Мне Раст казался непонятным, пока не начал вникать. Теперь понимаю, что всё более чем на своем месте и сделано с умом.
Только вот писать на нём не удобно и не приятно.Ни одной нормальной и полнофункциональной IDE нет. Те плагины что есть в vim или emacs - да, подсветка синтаксиса. Ну плюс ещё какой минимум. Чувствуешь себя в 90-х когда пишешь на rust.
Где вот это всё? Контекстный поиск, контекстный рефакторинг, встроенная справка, способность разобрать doxygen на лету и выдавать короткую справку по фонкциям, поддержка отладки с навигацией по коду. Где вот эта автоматическая навигация по коду при ошибках компилятора? Где это всё?
Ну да, лабу написать можно, но начинаешь серьёзный проект и фуууууу.
https://www.jetbrains.com/rust/
Ну так сделай. Сообщество спасибо скажет. Лично меня устраивает rust-mode + racer.
rust-analyzer посмотри, активно развивается и уже много чего умеет, есть интеграция в разные редакторы.
Мне неясно. Нормальный язык с нормальным и вполне понятным синтаксисом. Unsafe тебя из-под палки никто не заставляет использовать. Браузер написать смогли бы, если б не эффективные манагеры Мозиллы, у которых видение поменялось.
И да, я пишу на Erlang, по-твоему я ненормальный программист?
Раст нужен только неосиляторам нормальных ЯП.
Раст сложнее большинства языков, дурилка)
> Раст бесполезнее и неудобнее большинства языков, дурилка)Поправил.
Фигню спорол и рад)
Раст удобен и быстр, zero cost abstraction, и конкурентов по сути нет
Самый сложный — это C++. Учитывая темпы его развития, никто не сумеет перегнать этого монстра.
Что-то у нормальных людей в плюсах всё просто, логично и понятно. И нормальная инфраструктура. В отличии от этого ни на что не годного выкидыша.Как не написали на нём ничего, так и не напишут.
А я и не спорю. Я, лишь хотел сказать, что C++ никак не ограничен. Программист самостоятельно думает, как решать задачи. У растоманов же многое предопределено и закостылено.
+1
Т.е. все CVE по памяти подлые растоманы в плюсовые проекты накоммитили?
Только на этом сайте в месяц пара-тройка новостей про то что тут буфер переполнился, там за границы массива вышли (и рут получили) и это по большим проектам, на которые обратили внимание.Может это все неправда и происки хейтеров-злопыхателей? Или это все наделали "ненастоящие С++ программисты"™ потому что "настоящие С++ программисты"™ такие ошибки не допускают?
Вы можете ненавидеть раст всеми фибрами своей с++ной души, но отрицать проблему стабильно повторяющиеся багов с памятью на плюсах в разнообразнейших больших проектах... это просто непрофессионально.
Вот заметил такую штуку.У приверженцев Rust всё время проблема с C/C++. То у них с памятью всё плохо, то ещё что непонятное и сложное. То они вечно себе в ногу стреляют.
Зачем вы стреляете себе в ногу? Мазохисты? Вспоминается сразу две вещи:
1) Доктор, когда я делаю вот так, мне больно. А вы так не делайте.
2) Старая добрая игра Fallaut 2: "Вы стреляли в златоящеря и попали в себя, вы потеряли 20 пунктов жизни"Этакие люди неудачники.
Но и приверженцы C/C++ не отстают. Но другая ситуация немного. У тех кто знает, понимает и умеет писать на C/C++ проблема не с языком Rust, у них проблема с фанатами Rust. Что-бы не случилось, фанаты Rust вылазят везде и поносят всех. При этом не осилив даже элементарных правил работы с памятью. Они не могут.
Вот честно, очень токсичное общество любителей Rust. У них все плохие, кругом дыры. Одни они умные. Всех надо обосрать.
Приведешь им два аналогичных кода, с аналогичным поведением (вылетанием проги) на C++ и на Rust - Плюсовеки молчат, потому что понимают.
Что слышно от любителей раста? - "Ты де.....л, ты ничего не понимаешь, ваш C++ от....ой." А поведение то одинаковое.
Мне интересно. Откуда столько желчи и РЖАВЧИНЫ у приверженцев Rust.
Тот кто его назвал так что-то подозревал?
Так проблема не в языке, а в людях. Пользователи С++ в большинстве своем люди среднего или выше возраста, набившие на нем шишек, пробовавшие другие языки и прекрасно знающие о достоинствах (по-моему их нет, потому что есть С и Rust) и недостатках плюсов. А в Rust в основном (по крайней мере, в русскоязычном сегменте) молодежь, особо пороху не нюхавшая, зато кровь у них кипит.
А еще у меня подозрение, что большая часть комментаторов тут ни на том ни на другом никогда не писала и просто сотрясает воздух: "Все ругают Rust, ну и я поругаю до кучи".
Молодежь аха? У меня целая куча знакомых, как раз среднего и выше возраста. Они не то что программировать, а просто включить пк целое достижение. Не говоря ещё о бабульках. Так что нечего гнать на молодёжь.
И вот что это было? При чем тут выключить/выключить? Речь-то было про то, что срачи устраивают в основном молодые.
просто дедушки и бабушки с успехом программируют на Rust
> Что-бы не случилось, фанаты Rust вылазят вездеВот только в этот раз ты вылез и начал хейтить Раст в теме про Раст. Так что фанатики С++ ни чем не лучше
Сами же себя и дискридитировали, не прочитав до конца и побежав строчить комент =) Фанат раста не умеет читать.
Пруфы будут или только общими фразами умеешь разбрасываться?
Т.е. все CVE по памяти подлые растоманы в плюсовые проекты накоммитили?
Только на этом сайте в месяц пара-тройка новостей про то что тут буфер переполнился, там за границы массива вышли (и рут получили) и это по большим проектам, на которые обратили внимание.Может это все неправда и происки хейтеров-злопыхателей? Или это все наделали "ненастоящие С++ программисты"™ потому что "настоящие С++ программисты"™ такие ошибки не допускают?
Вы можете ненавидеть раст всеми фибрами своей с++ной души, но отрицать проблему стабильно повторяющиеся багов с памятью на плюсах в разнообразнейших больших проектах... это просто непрофессионально.
пока студент то за 3-4 года приучиш себя пользоватся указателями как скальпилем для нерохирурга (с), как пулиметом для рэмбо (с++). да за месяц обучения программированию научится писать безопасный код скорее получится на php, js, но что может спроектировать такой скороучка? хеллоу ворд в браузире разве только что отобразить.
Мне понравился на опеннете пару месяцев назад достаточно адекватный коммент, что Rust по факту энфорсит бест практизы C++ (RAII) через синтаксис, следуя уже бест практизам некоторых функциональных языков (типа Idris), что некорректное состояние должно быть формально невыразимым. Тот же Idris достигает это через зависимые типы, в Rust такого нет и формальная корректность гарантируется только для овнершипа по памяти.
Собственно, хороший специалист в С++ с набитой рукой будет пользоваться смартпоинтерами практически безошибочно, но даже у него может замылиться взгляд.
Rust vs C++ это примерно как Go vs Java, т.е. просто новый язык, призванный снизить порог входа и удешевить разработку, за счет снижения сложности некоторых областей до неприличия (Go имеет крайне скудный и неудобный синтаксис, отсутствие дженериков, но работа с многопоточностью в нем шикарна).
>Собственно, хороший специалист в С++ с набитой рукой будет пользоваться смартпоинтерами практически безошибочноесли вообще будет ими пользоваться, а не указатели гонять как все настоящие программисты.
Оверхед от того же unique_ptr нулевой.
Это не отменяет того, что безопасная работа с кучей в С++ реализуется, по факту, через паттерн. Плюс еще неудобная возня с циклическими ссылками в shared_ptr, которые можно разбить только через weak_ptr. В С++ на уровень "человеческого фактора" выводится очень многое и без статических анализаторов в проектах, где больше сотни классов, просто не уследить за всем. У Rust не очень удобный синтаксис, но в целом идея вынести RAII на уровень синтаксиса и семантики позволяет исключить утечки памяти по невнимательности, при этом не пользуясь сборщиком мусора. Если в Rust программе память и утечет, то это будет осознанная диверсия, когда сотрудник с доступом к мастеру для кучи короткоживущих, но относительно "жирных" объектов выставит lifespan, равный времени жизни долгоживущего объекта.
>В С++ на уровень "человеческого фактора" выводится очень многоеДа, к сожалению. Но программист должен быть программистом, а не макакой, полагающимся на компилятор и магию.
Монтажник должен быть монтажником, а не тупым жлобом, полагающимся на каску, страховку, изолированную проводку, строительные леса и прочие глупости.
> Если в Rust программе память и утечет...Вообще, утёкшая память в расте не считается за неопределённое поведение. Течёт всё, даже сборщик мусора дотнета легко обмануть банально не отписавшсь от события
Ну что сборщику мусора легко устроить протечку в Java/C# - это и так очевидно, достаточно иметь долгоживущий объект-коллекцию, хранящую strong ссылки.
В C++ легко устроить протечку, потому что в языке нужно 99% вещей делать руками, а там, где ручная работа - там ошибки от невнимательности/усталости/лености/недостатка скилла.
Rust тоже может потечь при неаккуратной работе с циклическими ссылками в растовых смартпоинтерах, но большую часть времени можно обойтись обычными ссылками и явным связыванием лайфспанов.
Да простят сравнение такое, но С++ это как обычный уровень, а Rust - как лазерный. Просто более навороченный инструмент, сглаживающий болезненные в повседневной разработке места другого, более раннего, инструмента.
Думаю, никто не будет поливать помоями Javа-истов, что они без своей супервумной IntelliJ IDEA с автокомплитом на машинном обучении имена методов и классов помнят ну очень смутно.
иногда лучше молчать
>Зачем вы стреляете себе в ногу? Мазохисты?Хуже, это sjw, которые в большинстве своем кодить не умеют.
хорошо сказал про то что с++ молчат, потому что знают что так не нужно делать )). Вот например топор, юнец колол дрова, обух отлител и прямо в ногу, юнца в больничку, выписали, ходит юнец и рассказывает что нужно заменить топор на бензопилу и приводит свой случай, взрослые мужики молчат, слушают и молчат ибо чо им сказать то еще не окрепшему разумом юнцу? про эллементарные правила колки дров? про то что в руках в общем то оружие которым можно и себя поколечить и соседа? А молчат еще и потому что этому юнцу и бензопилу в руки давать нельзя, максимум пластмассовый нож, и то, глаз себе может выколоть.
Ты 100% прав. И вообще, настоящий мужик дерево свалить может и острым камнем, а топор для слабаков и баб.
нет, про настоящих мужиков это уже юмор, сейчас то и нет таких, все вон полу-бабы, но это совсем другая истоия. Тут речь об идиотах и об отсутствия внимательности при написания кода. речь о вполне понятных проблемах инструумента которые могут привести к последствиям, но леквидировав эти проблемы - мы фактически уничтоаем сам инструмент. Вот взять острый нож, им можно порезаться, можно предложить пользоваться ножом для масла, да это решают проблему, ноги руки на месте, но о боже, им можно выколоть себе глаз! так же в ряде случаев масленного ножа хватит, но вот уже теряется универсальность, с этим ножом уже нельзя разделывать рыбу, мясо, даже хлеб начинает крошится.
Т.е проблема не в языке, а в том что 1. есть руки кривоопые. 2. специализированные скриптовые языки необходимо воспринимать как узко-спецализированную.
Взять к примеру QML, он как тот самый нож для масла, описывать гуи на js как объекты, параметр - значение и так далее - это прекрасно, удобно!
т.е всему свое предназначение, но когда при сравнении инструментов С++/раст говорят что одним можно себе ногу отрезать (но умалчивают что другим можно себе глаз выколоть) - я вам так скажу, это не серьезно.
Может, не стоит судить о сообществе Rust по Опеннету? И, ради бога, завязывайте со сказками про мудрых плюсовиков, которые молча всё понимают и не стреляют себе в ноги. Таких единицы, а основная масса плюсового кода написана отвратительно и не падает от любого чиха потому, что разработчики компиляторов достаточно великодушны, чтобы предусматривать защиту от дурака. Вообще, весь ваш пассаж, по сути, высосан из пальца - сплошные обобщения и домыслы, никакой конкретики. Ну пожаловались, что растоманы плохо себя ведут, обижают седых мудрецов, у которых НИКАКИХ проблем с памятью. И как же без типичных острот про ржавчину.
> Может, не стоит судить о сообществе Rust по Опеннету?Тут ты прав. За то время которое я тут провел - ...
> И, ради бога,
> завязывайте со сказками про мудрых плюсовиков, которые молча всё понимают и
> не стреляют себе в ноги. Таких единицы, а основная масса плюсового
> кода написана отвратительноИ тут прав.
> и не падает от любого чиха потому, что
> разработчики компиляторов достаточно великодушны, чтобы предусматривать защиту от дурака.
> Вообще, весь ваш пассаж, по сути, высосан из пальца - сплошные
> обобщения и домыслы, никакой конкретики. Ну пожаловались, что растоманы плохо себя
> ведут, обижают седых мудрецов, у которых НИКАКИХ проблем с памятью. И
> как же без типичных острот про ржавчину.А вот это уже эмоции.В прочем они у всех есть. то буду пользовать дальше, просто птому что интересно.
Интересные фичи. Еще бы время найти поковырять...
Бери Go. Там давно и panic есть, и функции возвращающие константы на этапе компиляции. И автоматический сборщик мусора без всякого геморроя.
Спасибо, Go я ковырял 2 года, хватит с меня. Когда надоело материться и блевать с этой корявой поделки Гугла, вернулся к Erlang'у.
Тогда на окамл.
Хоть брэйнфак лишь бы не раст?
Пишу на Си и на asm, зарабатываю на жизнь в embedded.
Хочется вкатиться в rust но не знаю, откуда и главное как начать.Хотелось запустить с отладкой mips(pic32mm) или risc-v(gd32) в eclipse.
У кого-нибудь есть такой опыт?
>но не знаю, откуда и главное как начатьтак отсюда же: https://www.rust-lang.org/what/embedded.
А вот более детально не расскажу. Самому интересно повозиться, но времени нет совсем.
В телеге есть группа по эмбедед расту - https://t.me/embedded_rs
Поспрашивай там.
На riscv и конкретно на gd32 все очень даже хорошо. Спасибо Disasm.
А вот для mips'ов ты вряд ли найдешь что-то адекватное.
https://github.com/riscv-rust/gd32vf103xx-hal
"Автоматическое управление памятью в Rust избавляет разработчика от ошибок при манипулировании указателями" - что бы ваши ети передвигались на инвалидных креслах. Я исключительно ради заботы, ведь передвигаясь на ногах можно споткнуться , забить лоб и умиреть! поэтому пусть передвигаются на инвалидных кресах от проктэр&гэмбэл с автоматизированной головкой!
А мне лень открывать рот и жевать. Я хочу чтобы пища сама попадала в желудок. Мне лень срать хочу чтобы пища сама выводилась из кишечника.
- А вы, что, и есть, значит, за меня будете?
- Ага!
Кому какое дело на чём программисты катаются и тешат своё ЧСВ.
Дженкем у вас не менее качественный, чем юмор. Я тут тоже нюхнул и шутку придумал: а давайте светофоры уберём, а то только трафик тормозят. Выбрал удобный момент - и перебежал, делов-то. Просто нужно быть внимательным и развивать реакцию.
смузихлебы ликуют! Теперь они смогут в системное программирование, по крайне мере они так думают... Но POSIX и WinAPI смотрят на них как на говно
Вот интересно, почему странные личности с интеллектом школьников ненавидят Rust?
Да пускай. Собака лает - караван идет.
Сишный API ядра передаёт пламенный привет всем смузихлебам
Почему D не упомянули, непорядок
D
Очень живой и динамичный язык. Только за этот год вышло, кажется, больше версий "языка программирования Rust" чем ISO-IEC-14882-xxxx за всё время (лет за 25, кажется).Опять же встроенный подтягиватель updates, packages и всего остального, о чём вы не знаете, но ... --- да и не надо забивать себе этим голову.
А на нем можно делать окна, кнопочки, черепашью графику?
https://www.areweguiyet.com/
Можете, назвать меня неосилятором, но. Приходит директор и говорит. Вот тебе железка на rs485. Сделай утилиту для её конфигурации и настройки. Срок три дня. Беру я такой раст... И через два месяца меня увольняют. Берут парня, который на делфи зафигачил все за 4е часа. Все довольны. Ну кроме меня.
А если на Лазарус, то ещё и минус затраты/ворвство иде
Ну и правильно уволили, не умеешь выбирать инструмент под задачу. Rust это жирный DLL/SO собрать с развесистой core логикой, а дельфях формочки нашлепать и через FFI вызывать процiдурки.
А какой инструмент под задачу необходимо было выбрать?
На производстве нужно: управление промышлееным оборудованием, работа с базой данных, формирование всяких протоколов и отчётов, следить за состоянием и работоспобоностью узлов и, естетсвенно, вменяемый, быстрый и отзывчивый пользовательский интерфейс. Смотрю вот в сторону реакта и Node.JS. Ещё бы во всё это дело внедрить Scrum. Мастера только хорошего надо найти, что бы минимум в два раза больше $ от разработчика получал. Желательно, что бы умел кататься на баланс борде.
Командной строк достаточно. Мозг не выпаривайте.
Не знание Линукса, не означает чтопод него нету хитрых инструментов.
>Берут парня, который на делфи зафигачил
>Не знание Линукса, не означаетЕсть некоторая вероятность что в организации не линукс, а что-то другое
Растаманы читайте Эриксона. Не гипнотезера. Джона.
"Простота языка С позволяет делать приложения более эффективными и пред
сказуемыми, но ошибки, допущенные во время написания кода, порой стано
вятся причиной таких уязвимостей, как переполнение буфера и утечки памяти,поскольку не существует механизма, проверяющего, помещается ли содержимое переменной в выделенную для нее область памяти. Если программист захочет по местить десять байтов данных в буфер, под который выделено восемь байтов пространства, ничто не помешает это сделать, хотя результатом, скорее всего, станет аварийное завершение программы. "
Хакина. Искусство эксплойта. 2009 год.
Сам себе противоречит. Более предсказуемые приложения, но с непредсказуемыми уязвимостями. Книга точно 2009, а не 1989 года? Не существует механизмов, конечно. А мужики-то не знали. Это же очень сложно - рядом с указателем на буфер положить размер этого буфера, назвать сию сложную структуру данных слайсом и работать с ней вместо голого указателя. Это ж лишние байты. Уж лучше предсказуемое поведение в виде мусора в памяти и, если повезёт, аварийного завершения программы.
> "Простота языка С позволяет делать приложения более эффективными и предсказуемыми"Более" -- это по сравнению с чем?