>[оверквотинг удален]
>  * $FreeBSD$
>  */
> #define SYS_syscall 0
> #define SYS_exit 1
> #define SYS_fork 2
> #define SYS_read 3
> #define SYS_write 4
> #define SYS_open 5
> #define SYS_close 6
>

Да, это получился зачётный конфуз.

Тем не менее вопрос по размеру строки в силе. "Hello World\n" 12 байт без терминатора, а в листинге 9. В оригинале было "Hello BSD"?

> Тем не менее вопрос по размеру строки в силе. "Hello World\n" 12
> байт без терминатора, а в листинге 9. В оригинале было "Hello BSD"?

Подловил. Просто "sometext\n"

Это ещё кто кого подловил. Если бы не эта разница в длине, я бы не обратил внимания, или может даже догадался про другую систему подумать. А так нашёл лишнее подтверждение, что код какой-то "не тот". :)

Нужно понимать, что минимальный не значит быстрый. Он может быть сильно медленней при исполнении.

Можно ссылку на собираемый проектик?

10 лет назад хелло_ворд весил 5 мегабайт. 7 лет назад хелло_ворд весил 3 мегабайта. 4 года назад хелло_ворд весил 1 мегабайт. Сейчас хелло ворд весит около 100 Килобайт.

Растаманы стыдятся отвечать на этот вопрос. Больше не задавай такие вопросы.

> 10 лет назад хелло_ворд весил 5 мегабайт. 7 лет назад хелло_ворд весил
> 3 мегабайта. 4 года назад хелло_ворд весил 1 мегабайт.

У вас, криворуких - возможно все. И 100 мб.
> Сейчас хелло ворд весит около 100 Килобайт.

Врешь и не краснеешь.

>Врешь и не краснеешь.

Извини, сейчас helloworld на Расте весит 200-ти с чем-то килобайт.

>>Врешь и не краснеешь.
> Извини, сейчас helloworld на Расте весит 200-ти с чем-то килобайт.

Байт, без кило. 500 байтный пример https://www.opennet.me/openforum/vsluhforumID3/124921.html#322 для FreeBSD можно ещё сократить, если рихтануть ELF, но это уже не относится к языку.
В других системах будет примерно так же, только некоторые параметры (номера сисколов) поменяются. Сравните с вариантом на ассемблере в моём ответе.

>>Врешь и не краснеешь.
> Извини, сейчас helloworld на Расте весит 200-ти с чем-то килобайт.

Как мило, очередной болту^W Экспердус опеннета.

cat hello.rs &&  rustc -O -C prefer-dynamic hello.rs && strip hello &&  wc -c ./hello                                                                           
fn main() { 
  println!("Hello World!"); 
} 
    6608 ./hello

Приятного обтекания!

> prefer-dynamic
> 6608 ./hello

Хитрозадый очень, да?
Статику давай, или считай все те либы, которые тащит за собой этот ваш раст.

151 байт, статика: https://github.com/kmcallister/tiny-rust-demo

>> prefer-dynamic
>> 6608 ./hello
> Хитрозадый очень, да?

Если очередной опеннетный "антирастовец" не владеет предметом, то кто ему ССЗБ?

> Статику давай,

Тебе воон выше дали - с ходу 500 байт, без каких-то извращений с линковщиком.

> или считай все те либы, которые тащит за собой этот ваш раст.

Эталон давай, на труЪ языке, плюс как правильно собирать и что, как и где считать. А то знаю я вас - "тут считаем, тут ... не считаем! Не считаем, я скозал!"

> Если очередной опеннетный "антирастовец" не владеет предметом, то кто ему ССЗБ?

Ты не умеешь в статическую сборку, а не владею предметом оказывается я. Ну-да, ну-да.
Растоманы такие растоманы.

> Тебе воон выше дали - с ходу 500 байт, без каких-то извращений с линковщиком

Это не "Hello, World" на расте, это не кроссплатформенная хрень на сисколах.

"Hello, World" на расте выглядит вот так и никак иначе:
----
fn main() {
    println!("Hello, world!");
}
----

> плюс как правильно собирать и что, как и где считать.

В Си статическая сборка делается просто ключом "-static" у gcc.
В расте, начиная с версии 1.48+ должно быть с ключом: '-C target-feature=+crt-static'. Но не факт, что это будет работать.
Проверять статичность линковки нужно выхлопом ldd - он должен быть пустым.

>> Тебе воон выше дали - с ходу 500 байт, без каких-то извращений с линковщиком
> Это не "Hello, World" на расте, это не кроссплатформенная хрень на сисколах.

Опечатка то по Фрейду. Действительно, не какая-то хрень, кросплатформенная, а, внезапно, пример системного программирования. Но тут же некоторым главное передёрнуть. Если слинковаться с libc, тогда бы он написал: "глядите, у Rust есть рантайм!"

> внезапно, пример системного программирования.

Мы в этой подветке обсуждали размер бинаря "стандартного" helloworld-а со всеми его зависимостями, а не системное программирование на расте.
helloworld - это ни разу не системное программирование.

> Но тут же некоторым главное передёрнуть.

Вот подсовывание хрени на сисколах вместо "стандартного" helloworld-а и было передёргиванием.
Во-первых, вместо "стандартного" хотели подсунуть совсем другое, а, во-вторых, пытались увести дискуссию с неприятной для вас темы в сторону.

> Если слинковаться с libc, тогда бы он написал: "глядите, у Rust есть рантайм!"

Кто "он"? Разверни мысль.

>> внезапно, пример системного программирования.
> Мы в этой подветке обсуждали размер бинаря "стандартного" helloworld-а со всеми его
> зависимостями, а не системное программирование на расте.

Нет никакого стандарта на helloworld-ы. Вы это прекрасно понимаете, потому и закавычили. Исходный вопрос "Сколько весит хелло ворд на русте с зависимостями?"
https://www.opennet.me/openforum/vsluhforumID3/124921.html#293
Пример показывает, что из зависимостей достаточно ядра. Наблюдаемый результат соответствует. Задача решена.

> helloworld - это ни разу не системное программирование.

helloworld и системное программирование ортогональны и не исключают друг друга.

>> Но тут же некоторым главное передёрнуть.
> Вот подсовывание хрени на сисколах вместо "стандартного" helloworld-а и было передёргиванием.

Это хороший, годный минимальный пример. Он показывает, что сам язык в какой-то мере самодостаточен и пригоден для написания системного ПО (я не говорю, что он является заменой императивному Си -- как выяснилось, Rust исходно функциональный язык).

С другой стороны вот здесь https://www.opennet.me/openforum/vsluhforumID3/124921.html#588
пишут, что к программе на Rust проблематично прилинковать статично его стандартную библиотеку. Вот это уже звоночек. Похоже, вокруг языка крутятся посторонние люди, которые плохо понимают требования.

> Во-первых, вместо "стандартного" хотели подсунуть совсем другое, а, во-вторых, пытались
> увести дискуссию с неприятной для вас темы в сторону.

Вопрос надо формулировать соответствующим образом, или не додумывать условия за автора. Может это он и опубликовал решение с сисколами. =)

>> Если слинковаться с libc, тогда бы он написал: "глядите, у Rust есть рантайм!"
> Кто "он"? Разверни мысль.

Да хоть кто. Тема рантайма идёт рефреном под каждой новостью.

> из зависимостей достаточно ядра

Тю, спалил.
Кстати, как тут некоторые умники собрались линковать статику под венду - вопрос.
Раньше там вообще бинарник без импортов не считался валидным.

> пишут, что к программе на Rust проблематично прилинковать статично его стандартную библиотеку.
> Вот это уже звоночек.

Помимо того, что требовать беспроблемную _статическую_ линковку с любой, даже "хитровывернутой", либой на _другом_ как-то странно, glibC - ни разу не "стандартная библиотека" раста.
Но тоже очень удобная для местных:
https://man7.org/linux/man-pages/man2/syscalls.2.html
> System calls are generally not invoked directly, but rather via
> wrapper functions in glibc (or perhaps some other library).

Сделали свой дубль - "тащин ненужный рантайм", используют системную либу "Фе, зависят от сишного рантайма!". Было уже с аллокатором, тащили jemalloc - "блоатварь тащит свой велосипед!", перешли по умолчанию на системный - "фу, не осилили свой аллокатор, используют сишрный, зачем раст вообще нужен!".
Кстати, растовская стат. либа вполне себе нормально линкуется с сишными.

#[no_mangle]
pub extern "C" fn main() {
    println!("Hell world");
}
gcc -static rstest/target/release/libstatictest.a -lpthread

> либой на _другом_ как-то странно

на _другом_ ЯП
//fix

> как тут некоторые умники собрались линковать статику под венду - вопрос.

Ты всё перепутал. Я тебе предлагал просто собрать сискольно-растовый helloworld под винду, не обязательно в статике, но без модификаций исходника. И показать нам что у тебя получилось.

Я и под Бздю предлагал его тебе собрать, ибо чел выше написал, что он переделывал сискольно-растовый исходник под Линь. А я, не вдаваясь в подробности его модификаций, посчитал, что без них у него что-то не собиралось или не работало.
Но ты тут же прибежал и начал кричать что я дико обглюкался, показывая мне строчку "$FreeBSD$".

Мда уж... молодец.

> glibC - ни разу не "стандартная библиотека" раста.

Ага. Это системная библиотека на подавляющем большинстве GNU/Linux-ов.
Через неё ваш Раст и работает, если верить выхлопу ldd. И нет никаких оснований этому выхлопу не верить.

А ещё забавно, что никто так и не показал размер статически собранного растовского helloworld-а, того, который из книжки. Я уже и ключи для компилятора вам дал, но вы ни в какую.
Вангую, что там получается под пару мегабайт, а может и больше.

>> как тут некоторые умники собрались линковать статику под венду - вопрос.
> Ты всё перепутал. Я тебе предлагал просто собрать сискольно-растовый helloworld под винду,
> не обязательно в статике, но без модификаций исходника. И показать нам
> что у тебя получилось.

Хорошая отмазка но нет. У тебя претензии были 1) "не кроссплатформенно" 2) "собери статику".
Получается как обычно: "там считаем, там ... ты все перепутал!"

> Я и под Бздю предлагал его тебе собрать, ибо чел выше написал,
> что он переделывал сискольно-растовый исходник под Линь. А я, не вдаваясь
> в подробности его модификаций, посчитал, что без них у него что-то
> не собиралось или не работало.
> Но ты тут же прибежал и начал кричать что я дико обглюкался,
> показывая мне строчку "$FreeBSD$".

Конечно же обглюкался - потому что оригинал дампа и был собран под "бздю"

wc -c nostd && file nostd      
     496 nostd
nostd: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, stripped

(к чему и были "претензии" - мол, чей это у вас номера сисколов странные, не порядок!).
Но ты читал афедроном - понял что-то совершенно свое и выдвинул соотв. претензии, причем в соотв. тоне.

>> glibC - ни разу не "стандартная библиотека" раста.
> Ага. Это системная библиотека на подавляющем большинстве GNU/Linux-ов.
> Через неё ваш Раст и работает, если верить выхлопу ldd. И нет никаких оснований этому выхлопу не верить.

Ну т.е. ты не знаешь разницы между системной и стандартной библиотекой.
Или же, я правильно понимаю, что (условная) "kernel32.dll" или "winnt" - стандартная библиотека сишки, плюсов (и еще кучи языков), потому что на венде "через нее ваш X и работает", если цитировать тебя же?
Или кто-то запутался в своей демагогии?

> У тебя претензии были 1) "не кроссплатформенно"
>
>> Я тебе предлагал просто собрать сискольно-растовый helloworld под винду,
>> не обязательно в статике, но без модификаций исходника. И показать нам
>> что у тебя получилось.

Здесь легко прослеживается причинно-следственная связь. Все, у кого мозги на месте, поймут.

> Хорошая отмазка но нет.

Нет так нет. Но я теперь имею полное моральное право считать тебя токсичным г.

> Конечно же обглюкался - потому что оригинал дампа и был собран под "бздю"

Ну и радуйся, что я обглюкался. Да, я повёлся на вот эту хрень, не вдаваясь в детали:

> (... у вас номера сисколов странные, не порядок!).  

Сильно радостно от такой "великой победы"?

Ты вообще понимаешь насколько это мелко?

>> Через неё ваш Раст и работает, если верить выхлопу ldd. И нет никаких оснований этому выхлопу не верить.
> Ну т.е. ты не знаешь разницы между системной и стандартной библиотекой

А я и не указывал в каких именно местах Раст работает через (g)libc. Я этого и не знаю, и знать не хочу - не интересно.
И в твоих фантазиях на тему виндузы я тоже не стал разбираться, прости.

А вот по поводу терминологии читай цитаты из README от glibc:

"The GNU C Library is the _standard_ _system_ C library for all GNU systems,
...
the runtime facilities of other programming
languages use the C library to access the underlying operating system".

P.S. Унылый ты, анон, очень унылый.

Сисколы в Виндосе, насколько помню, меняются в пределах версии ОС. Никто в здравом уме их там не использует. Если кто-то предлагает обойтись без ntdll.dll (а в случае вывода на консоль наверняка потребуется и WriteConsoleW из kernel32.dll) -- он либо не владеет предметом, либо намеренно пытается свести дискуссию к священной войне.

> Нет никакого стандарта на helloworld-ы

Вообще-то растовский "стандартный" helloworld есть прямо в главной книжке по расту:
https://doc.rust-lang.org/book/ch01-02-hello-world.html

> Пример показывает, что из зависимостей достаточно ядра.

Практически любую прикладную программу можно написать на один только сисколах. Но так никто не делает. И этому есть много разных причин.

Вы здесь пытаетесь хитрить, но это же многие видят. И эти ваши хитрости бросают тень на всю экосистему раста. Странно, что вы этого не понимаете.

> helloworld и системное программирование ортогональны и не исключают друг друга

Это не совсем так. За helloworld-ом уже давно закрепился особый смысл.
Вот, например, его описание на Wiki: https://ru.wikipedia.org/wiki/Hello,_world!

> Это хороший, годный минимальный пример.

Возможно. Но к размеру бинаря классического helloworld-а имеет весьма далёкое отношение.

> Вопрос надо формулировать соответствующим образом, или не додумывать условия за автора.

Нормально там был сформулирован вопрос: "Сколько весит хелло ворд на русте с зависимостями?".

Но вместо прямого ответа последовали всякие плутовства. Тут тебе и сисколы, тут тебе и prefer-dynamic.  Всё это бросается в глаза.

Вы, ребята, этими своими хитростями создаёте своему любимому Расту плохую репутацию. Этот язык прямо на глазах становится "токсичным".
Я это и по буржуским форумам вижу, кстати. К RUST-евангелистам ведь не только на опеннете многие негативно относятся. Это уже общемировая тенденция, можно сказать.
Многих вы уже утомили своим Растом, да.

>> Нет никакого стандарта на helloworld-ы
> Вообще-то растовский "стандартный" helloworld есть прямо в главной книжке по расту:
> https://doc.rust-lang.org/book/ch01-02-hello-world.html

По ссылке насчитал 4 вхождения слова "standard":

"12.6. Writing Error Messages to Standard Error Instead of Standard Output

"If you want to stick to a standard style across Rust projects

"with the standard Rust distribution"

потому дальнейшую часть сообщения читать не буду, вряд ли она имеет смысл.

> Опечатка то по Фрейду. Действительно, не какая-то хрень, кросплатформенная, а, внезапно, пример системного программирования.

Ты и в этом случае, кстати, выдернул одну фразу из контекста. Такое "хитроумное" выборочное цитирование.

>> Если очередной опеннетный "антирастовец" не владеет предметом, то кто ему ССЗБ?
> Ты не умеешь в статическую сборку, а не владею предметом оказывается я.

Судя по тому, что для тебя стат. сборка "ух какой крутой скилл" и предыдущим (к сожалению, удаленным) перлам - не владеешь. Но исправно проецируешь какие-то свои фантазии.

>> плюс как правильно собирать и что, как и где считать.
> В Си статическая сборка делается просто ключом "-static" у gcc.

В последний раз:
давай полный пример, чтобы не было потом "Ты не так понял и вообще я не я и мопедолошадь - не моя!"

>> В Си статическая сборка делается просто ключом "-static" у gcc.
> ... для тебя стат. сборка "ух какой крутой скилл"

Да, знание ключа "-static" я считаю крутым скиллом. (facepalm.jpg) [нет, конечно]

> предыдущим (к сожалению, удаленным) перлам - не владеешь.

Ты свои перлы до сих пор продолжаешь извергать:

> как-то странно, glibC - ни разу не "стандартная библиотека" раста.

Собери свой растовский helloworld и посмотри наконец выхлоп ldd, что ли. Может поймёшь как оно у тебя работает. Я тебе писал это ночью, но всё потёрли.

> давай полный пример

Я не должен давать тебе никакой примеров.
Это ведь ты доказываешь крутизну Раста, а не я доказываю крутизну Си.
Есть такое общепринятое правило: "Бремя доказательства лежит на утверждающем".
Ты утверждаешь - ты и доказывай.

>> как-то странно, glibC - ни разу не "стандартная библиотека" раста.
> Собери свой растовский helloworld и посмотри наконец выхлоп ldd, что ли. Может поймёшь как оно у тебя работает. Я тебе писал это ночью, но всё потёрли.

Я то в курсе (и у меня оно ни разу не зависит от glibc),

 rustc -O hello.rs && ldd hello 
hello:
    libthr.so.3 => /lib/libthr.so.3 (0x8010af000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8010dc000)
    libc.so.7 => /lib/libc.so.7 (0x8010f3000)

а вот ты похоже то ли унылый набросчик, то ли просто очередное опеннетное ламо, то ли гибрид из того и другого.

>> давай полный пример
> Я не должен давать тебе никакой примеров.
> Это ведь ты доказываешь крутизну Раста, а не я доказываю крутизну Си.

Ссылку на "ты доказываешь крутизну Раста" или балабол?

> Есть такое общепринятое правило: "Бремя доказательства лежит на утверждающем".
> Ты утверждаешь - ты и доказывай.

Видишь ли, балабол, ты ошибся методичкой - каких-то "доказательств" требуешь ты,
фыркая на существующие - "это не то! И это тоже не считается!". Ветку начал тоже "из ваших".
При этом четко и внятно описать что вам нужно, вы не в состоянии, отмазываясь "Я не должен давать тебе никакой примеров."
В общем-то, правильно опасаетесь, что вас опят ткнут носом в лужу.

> (и у меня оно ни разу не зависит от glibc),
>  libc.so.7 => /lib/libc.so.7 (0x8010f3000)

Угу, у тебя оно зависит от другого libC. Но сути-то это не меняет.

> а вот ты похоже то ли унылый набросчик, то ли просто очередное опеннетное ламо, то ли гибрид из того и другого.

Ты вообще токсичное г., с которым противно иметь какие-либо коммуникации. О другом участнике дискуссии, кстати, я такого пока не могу сказать.

> Ссылку на "ты доказываешь крутизну Раста"

Да хоть вот это: https://www.opennet.me/openforum/vsluhforumID3/124921.html#517

>...фыркая на существующие - "это не то! И это тоже не считается!".

Конечно, потому что ты всех за л0х0в держишь. Написали "с зависимостями", а ты подсовываешь вообще обрезанный по максимуму бинарь, у которого на самом деле куча зависимостей, которых не видно. Типа, хитросделанный очень.

> В общем-то, правильно опасаетесь, что вас опят ткнут носом в лужу.

Можешь себя этим успокаивать. Но причина-то совсем не в этом.

И не думай, что у меня вообще есть большое желание вас всех размазать. Мне достаточно вас лишь палочкой потыкать, когда вас начинает слишком заносить.
А такое с вами часто бывает, да.

извините, что прерываю, но откуда вообще появилось требование статической линковки? тем паче для helloworld?

Всего лишь 200+ килобайт. А какой вес у ноды? А какой у джавы? У дотнета? У питона?

А у C++? Тоже со стандартной либой?

#include <iostream>

int main() {
    std::cout << "hello world" << std::endl;
    return 0;
}

$ g++ hello.cpp -O2 -static-libstdc++

$ du -sh ./a.out
1.3M    ./a.out

$ strip a.out
$ du -sh ./a.out
948K    ./a.out

(и 880K если Clang)

В Расте так вообще не получится.
Нужно специально устанавливать MUSL libc и выбирать соответствующий target, чтобы получить на 100% статический бинарник.

> $ g++ hello.cpp -O2 -static-libstdc++

У мну без доп. -static ldd ругается на зависимости.
А полностью стат., "пострипаный" плюсовой бинарь выходит в 1.4МБ (1.1 для шланга).

В любом случае меньше любого интерпретируемого языка,
а с учетом засилья PHP, Python, Ruby для сайтов (коих у каждой компании),
то не думаю, что это как-то сильно кого-то беспокоит.

А тебе рекомендую уже дойти до магазина и купить себе новый диск.
Сейчас уже SSD стали вполне доступными, а порнуху можно и в облако загрузить.

> В любом случае меньше любого интерпретируемого языка,
> а с учетом засилья PHP, Python, Ruby для сайтов (коих у каждой
> компании),
> то не думаю, что это как-то сильно кого-то беспокоит.

Ты его лучше спроси, как он вообще зависимости считает.
И пусть "эталонный" пример, с эталонными опциями сборки (и пояснением за эталонне окружение выполнения) на труЪ ЯП кинет, для начала.
Охренее^W Узнаешь много "нового".

> Узнаешь много "нового".

Уже узнали, что Раст не умеет в статическую линковку с glibc.
Для статической линковки ему нужна MUSL.

Это просто "праздник" какой-то.

Вроде в новых версиях линковать статически с glibc они уже научились. Но это всё нужно проверять. У них там есть оговорки.

> Инкрементальная компиляция была отключена в выпуске 1.52.1 из-за выявления скрытых ошибок

Теперь не только безопасная работа с памятью, но и безопасная компиляция.

Друг, безопасности памяти в коде и отсутствие уязвимостей в принципе - принципиально разные вещи, второе нельзя достигнуть, но лучше всё же жить без первого

Не такие уж и принципиальные, смежные. Ошибки работы с памятью запросто используют для уязвимостей.

Тогда зачем нужна эта ваша «безопасная память»?

безопасная память это физически разделенная

чтобы тратить больше времени на разработку, изворачиваясь, делая обычные вещи. как с С++ в своё время.

> безопасности памяти в коде (1)
> отсутствие уязвимостей  в принципе (2)

...
> второе нельзя достигнуть,
> но лучше всё же жить без
> первого

Так понятнее, что на самом деле написано.

"отсутствие уязвимостей в принципе" нельзя достигнуть, но лучше всё же жить без "безопасности памяти в коде".
Так понятнее, чем здец из ">"

Задним числом все умны.

>Вызов макросов внутри атрибутов может оказаться полезным для включения в документирующие комментарии содержимого из других файлов. Например, для вставки содержимого файла README и результата выполнения скрипта можно указать

Что-то я непронял совсем что тут происходит и зачем это нужно.
Макрос в коде меняет файл с кодом или что тут происходит?

Мне больше интересно, зачем вставлять в .rs файл содержимое .md файла.

Стандартный хедер "этот файл под лиценцией {0}, писан {1}, email {2}" может вставить даже не самая продвинутая IDE. Далее по идее ридми.тхт и комментарии должны наоборот, из src-файлов ИЗвлекаться, и на их основе генерироваться нормальная человеческая документация + файл ридми.

Также мне реально стало интересно, зачем пихать в .rs файл вывод .[скрипт].

Вот тут действительно, непонятно. Хотелось бы увидеть хотя бы три сценария использования, где это не натягивание совы на глобус, а глобуса - в попугая

> Далее по идее ридми.тхт и комментарии должны наоборот, из src-файлов ИЗвлекаться, и на их основе генерироваться нормальная человеческая документация + файл ридми.

Вот и я раньше так думал, а теперь не понимаю что происходит. Может нам опытные растенианци объяснят.

>Может нам опытные растенианци объяснят.

Растаманы - это растения? Растаман - это овощь?

В Расте документация генерируется на основе специально оформленных комментариев (doxigen вид сбоку). Когда документации становится много это усложняет навигацию по исходному когда.

Теперь часть документации можно вынести в отдельные файлы, а в исходниках остваить только краткую выжимку.

Но зачем для этого какие-то макросы в исходниках? В доках пишешь имя функции и комментарий.

Или я чего-то не понимаю?

Комментарии-документация чисто технически являются специальным синтаксисом для #[doc] макроса.

Я к тому что.
1 Доки собираются из исходников.
2 В исходниках слишком много доков, вынесем их в отдельный файл. Чтобы... Чтобы линковать отдельный файл в исходники откуда собирать доки?

Почему бы не собирать доки сразу из отдельного файла с доками?
Зачем в исходники то тянуть что попало из каких-то файлов?

Или я всё неправильно понимаю?

https://doc.rust-lang.org/std/pin/index.html

Вот пример выше. Подобную документацию удобнее держать рядом с кодом.

Ну или https://docs.rs/legion/0.4.0/legion/index.html в качестве случайного примера.

В дополнение: примеры кода в документации являются полноправными тестами (выполняются по cargo test).

Там подкрутили, здесь сделали удобнее, вон там ещё затюнили маленько. Мелочи, но по совокупности получаем одну из самых лучших документаций в индустрии. По крайней мере у крейтов, которые используют больше чем 1.5 землекопа.

> примеры кода в документации являются полноправными тестами (выполняются по cargo test)

Особенно удобно, если это пример кода к какому-нибудь std::fs::remove_dir_all :)

Для таких случаев есть no_run.

Да это понятно :-) Просто не люблю такое неявное поведение.
Мне видится более разумным явное указание того, что пример кода является одновременно и тестом, чем такая инвертированная логика.

>> примеры кода в документации являются полноправными тестами (выполняются по cargo test)
> Особенно удобно, если это пример кода к какому-нибудь std::fs::remove_dir_all :)

Ага, и то ли дело "make test" или ./configure_портянка_на_пару_тысяч_строк - там такое ну абсолютно невозможно!

> Суть проблемы в том, что в файле install.sh для очистки локальной копии собранных файлов вместо команды "rm -r yd-tools/usr" по ошибке была добавлена строка "rm -r /usr". Проблема появилась в коде 20 мая в ходе переработки сборочных скриптов и была исправлена несколько часов назад

Ой!

> Почему бы не собирать доки сразу из отдельного файла с доками?
> Зачем в исходники то тянуть что попало из каких-то файлов?

Потому что процесс под названием "комментировать код" является приёмом реверс-инженерии. Когда разработка прямая, сначала формулируются требования к коду, а потом уже сам код. Когда требования и код расположены рядом, проще сохранять их соответствие. Таким образом возникли doxygen и подобные системы. Потом уже в них добавили опцию "вот этот файлик хорошо бы целиком включить в документацию".

Это логично, однако.
Комментировать код, и иметь отдельный файл для хранения документации, друг другу не противоречащие вещи.

Меня смущает, что, удобно документацию в том-же файле что и код держать, а потом нам нужно часть документации отдельным файлом потому что неудобно документацию и код в одном файле держать.
Но так как нам удобно то мы сделаем макрос для всасывания отдельных файлов в файлы с кодом чтобы держать документацию и код в одном файле когда мы держим документацию и код в разных файлах.

Понятно если к такой системе пришли эволюционно и постепенно.
Но было ли абсолютно необходимо для раста набивать все шишки прошлых поколений, вопрос открытый.

И мы так и не выяснили что за выход какого скрипта нужно подключать в исходный код этим макросом.

Документация ведь делится на несколько уровней. Есть и краткое описание проекта (почти не меняется и к какому-то конкретному фрагменту кода не привязана), информация об авторе, лицензии и т.п. Вот пример титульной страницы документации на Доксиген, наверняка в отдельном файле https://www.doxygen.nl/index.html

В cargo doc появилась поддержка не только api документации, поэтому теперь не обязательно нужен дополнительный тулинг, чтобы писать гайды, туториалы и проч подобные вещи.

Тут происходит Чад кутежа во мгле ада.

Это раст, парень!

А когда перепишут Rust на Rust'e?

Он уже на расте.

Дак вон оно что, Михалыч... Потому ошибки и вылазят.

> Инкрементальная компиляция была отключена в выпуске 1.52.1 из-за выявления скрытых ошибок

Могу только предположить, но вероятно это происходило из-за логических ошибок в реализованных алгоритмах, а не из-за обращения к памяти после ее освобождения или выхода за границы буфера и т.п., что составляет 70-80 процентов ошибок в прогах на C/C++

Давайте не будем бла-бла-бла. Среднестатистически даже в релизах ПО 90 процентов ошибок - логические. А потом уже идут эти ваши обращения к освобожденной памяти и прочая фуета.
Интересно, как в расте борются с этой проблемой, учитывая то, насколько на нем неудобно выражать свои мысли, в отличие от того же питона, к примеру

Мне вот удобно выражать свои мысли на русском, чуть менее удобно на английском, поскольку не родной, а на китайском совсем неудобно, ведь я им не владею. А китайцу ровно наоборот.

С языками программирования та же ситуация.

> А китайцу ровно наоборот.

Очень удачный пример.
У китайцев новые слова для новых, выявленных в науке, понятий каждый афтор придумывает сам. И, очень часто, одному и тому же понятию соответствует десяток слов, каждое из которыйх длинной в 20 иероглифов. И не читая книг, где эти понятия вводились, ты даже приблизительно не можешь понять о чем речь. Ибо именно в книгах приводится ассоциативный ряд, который привел к возникновению данной последовательности иероглифов.

Так что да. Пример очень показательный.

Есть какой-то компилятор в котором не допускали ошибок? Или какой-то язык, на котором не допускали ошибок?

>Он уже на расте.

Это как говорить что весь веб на JS, игнорируя весь бэкенд на PHP,Java,C#,Ruby,Go и т.д.

Что конкретно вы имели в виду?

наверное, что там llvm на на расте в качестве бэкэнда

Когда успели llvm на раст переписать?

А кто сказал что rustc только llvm умеет? Кроме другого бекенда написанного на C++ (gcc, он был недавно принят), уже давно поддерживается cranelift, а он целиком на Rust написан

Пускай cranelift пока не может соревноваться по скорости работы выхлопа с llvm (Для x86, основные усилия в нём брошены в сторону wasm), он уже работает, и для дебаг билдов его некоторые используют из за его высокой скорости компиляции

> макросов, напоминающих функции (процедурные макросы и макросы, созданные при помощи макроса "macro_rules!"). От функций подобные макросы отличаются символом "!" после имени (macro!(...)) и подстановкой исходного текста макроса вместо генерирования вызова функции

Они наконец изобрели inline-функции? %D

В каком смысле? Инлайн давно есть

Или, слава ржавчине, они изобрели #define? Непонятненько...

Макросы C - худшие макросы ever, не надо их тут вспоминать, пожалуйста

Макрос это не часть языка это препроцессор компилятора и чем же макросы rust лучше чем си?

Действительно, наверное и в стандартах языков С и С++ ничего нет про макросы?

А про разницу можно легко найти в гугле.

Спецификация C или C++ описывает не только сам язык, а еще например язык макросов для компилятора

А спецификация Java или C# описывает байткод, но ты же не пишешь на байткоде?

Есть технические особенности реализации того или иного ЯП которые отражены в стандарте ЯП, имеющие коственное отношение к ЯП и прямое к его компиляции или интерпритации, тобишь исполнению

Кажется, что тебе нужно прочитать секцию Scope стандарта.

Помню был тут один поехавший который мне доказывал что язык Си это ООП язык только по тому чтт в стандарте Си имеется слово "обьект трансляции" то есть всмысле раздельная компиляция, но слово же "обьект" есть в стандарте Си значит ООП? И ты туда же? А логику как? Включить не пробывал?

Нет в стандарте С никакого "объекта трансляции", но есть "единица трансляции" -- это то, что получается в результате работы препроцессора.

Был он меня задолбал этим слово, вроде в C89 его нашел... хз погугли

Стандартная библиотека тоже отношения не имеет к синтаксису ЯП, она лишь описывает API для взаимодействия с окружением внутри ОС, но это же не мешает ей быть в стандарте

Синтаксис языка != язык.

Хм, ЯП может считаться то что компилируется напрямую в машинный код(неважно как статически, через jit или интерпритатор)

Макрос транслируется в C/C++ код, какое отношение он имеет к ЯП?

Синтаксис ЯП так или иначе имеет машинное отображение в виде исполняемого файла с инструкциями процессора... макросы этого не имеют

> Макрос это не часть языка это препроцессор компилятора и чем же макросы rust лучше чем си?

// Wrong!
#define SWAP(x, y) \
  tmp = x; \
  x = y; \
  y = tmp
// Correct!
#define SWAP(x, y) \
  do { \
    tmp = (x); \
    (x) = (y); \
    (y) = tmp; } \
  while (0)

И правда, чем же макросы, которые часть языка и "умеют" в AST, лучше примотанного на синюю изоленту независимого текстового препроцессора, которому неведомы ни имена переменных, ни области видимости, ни прочее "ненужно"?

Макросы это тупо подстановка кода из макросов в код программы, иначе говоря шаблонизатор... какое нафиг AST причем здесь оно?

Функциональный макрос это шаблон заполнения кода внутри него до этапа компиляции

Вышеприведенный тобой дефайн вычисляется только один раз на этапе компиляции после чего в место вызова дефайна просто подставляется вычисленное значение и все, то есть никакой не о какой динамической вычислимости дефайнов в процессе работы программы и речи быть не может

Ну и классическое, раз дефайн это тупо шаблонизатор подставляющих значения никакой проверки типов входящих значений в нем нет

> Макросы это тупо подстановка кода из макросов в код программы, иначе говоря шаблонизатор... какое нафиг AST причем здесь оно?

"новое определение макроса бай опеннетный аноним"

>>> чем оно лудьше?
>> классический пример, почему препроцессор - это костыль
> то есть никакой не о какой динамической вычислимости дефайнов в процессе работы
> программы и речи быть не может
> Ну и классическое, раз дефайн это тупо шаблонизатор подставляющих значения никакой проверки
> типов входящих значений в нем нет

"Папа, где море?!" (c)

Ответь умник где найти код дефайна в обьектном файле? Ах да я ж забыл что он существует лишь в памяти компилятора на момент компиляции...или ты не согласен?

> Ответь умник где найти код дефайна в обьектном файле?

Зачем мне отвечать на твои бредовые фантазии, невежда, у которого "дефайн вычисляется только один раз на этапе компиляции"?
> Ах да я ж забыл что он существует лишь в памяти компилятора на момент компиляции...или ты не согласен?

На момент компиляции никаких "дефайнов" уже нет, компилятор работает с результатом препроцессора.
man cpp, man gcc -E, man что_такое_препроцессор (да хоть man gcc вводная часть).

И не трави за подстановки дефайна, ты скажи где он как машинный код в обьектном файле?

Он не говорил, что define-ы улетают в машинный код. Он говорил, что макросы как часть AST-а языка -- это лучше чем отдельный препроцессор.

Короче разберись что такое макросы, инлайн функции и обычные функции чем они отличаются, а то у тебя венегрет какой то в голове

>> макросы, которые часть языка и "умеют" в AST
>> ... ни имена переменных, ни области видимости,
> какое нафиг AST причем здесь оно
> Функциональный макрос это шаблон заполнения кода внутри него до этапа компиляции
> Короче разберись что такое макросы, инлайн функции и обычные функции чем они отличаются, а то у тебя венегрет какой то в голове

Подсказка: для начала подтяни базовые (в смысле ВУЗа, а не школьных уроков информатики) знания по ЯП -- и многое перестанет быть "венегретом".

Хотя вычисление макроса на этапе компиляции вроде нигде не прописано, поэтому в старых компиляторах применяется обычный копипаст

Ну и не все макросы можно вычислить, тот же printf например который работает со стандартным потоком ОС

Поэтому для каноничности без особо умных компиляторов, будем считать макросы копипастой

Смотрите раздел Translation phases. Препроцессор это отдельная фаза трансляции, семантический анализ и трансляция (компиляция) идут несколько позже, после чего происходит связывание (линковка).

Макросы раста - это конструкции языка, а не препроцессора. Уместнее сравнение с темплейтами в плюсах.

Постепенно углубляюсь в этот язык, кайфую
После C/C++ совсем сказка, море возможностей и удобств, при этом высокая производительность

Советую всем, даже кого C/C++ держит и точно не отпустит. С разбором Раста приходит большее понимание, как лучше писать код вообще.

Лисп попробуйте, схему какуюнить, Racket например.
Много почерпнёте.

Спасибо за рекомендацию!
К сожалению, как-то так складывается, что не перевариваются скобочные языки с фп в чистом виде. А вот элементы фп в других языках - приятное дополнение к их возможностям.

Да нет в этих лиспах никакого чистого ФП. В scheme ФП, конечно, побольше, чем в CL, но по сути там столько же ФП, сколько его в современном Джаваскрипте.

За чистым ФП - в Haskell, ну или к некоторым языкам семейства ML.

для haskell нужно вспоминать забытый после универа матан( подзабил в своё время на его изучение

Да не надо там никакого матана. Просто он из академической среды, и потому им привычнее в терминах теории категорий рассуждать. На самом деле всё это объясняется на пальцах элементарно: http://learnyouahaskell.com/

Напоминает хаскелевский хайп надцатилетней давности. Потом как-то все устаканилось, и язык трехсот головоломных способов вычисления чисел Фибоначчи занял почетное место во главе промышленно используемых языков, но с конца.
Тем же окончится и абсолютистский подход к "безопасности использования памяти", когда без ансейфа код становится пароксизмом пи*доватизма, а безопасность страдает уже от множества других проблем, решение которых так и не удается загнать вместо линтера в компилятор ))

Напоминает.
Но все-же хаскель был немного о другом. Если я верно понимаю, фишка хаскеля это корректность и верифицируемость (ещё про ленивость много шутили)

В то время как фишка раста, это универсальность в первую очередь но с сахаром и плюшками.
Раст можно сравнить в этом плане с котлином например.

Учитывая, что раст даже вот в линукс ядро пропихивают, есть некие надежды на то, что будет он чуть более популярнее хаскеля.

Это другое!). А так история циклична, а ПО как писали на C/C++, JVM-семействе, так и пишут. Когда училась в универе функциональные и околофункциональные языки были очень в моде, с одной стороны Haskell, с другой стороны LISP'еры грозились захватить мир и было очень даже много неплохих ресурсов по LISP, Microsoft на хайпе запилили свой диалект OCaml и носились с ним просто ВЕЗДЕ! И знаете что? Все перечисленные языки во всех смыслах лучше и качественнее Rust! В каждом есть своя идея, реализация на уровне проектирования, вот почему-то F# написан на F#, то есть разработчики в кои то веки с технической точки зрения знали что делают и чего хотят достичь. Rust же до сих пор не вышел из состояния зародыша, НО УЖЕ покрылся ржавчиной (собственно правдивое название), причём язык даже не умудрился привнести вообще ничего нового. На C++ почти на всю функциональность Rust есть свои приёмы, можно без труда писать на C++ в стиле Rust и заиметь все те преимущества (не очень то и существенные) которые он даёт. То есть если Хаскель или ML-семейство или LISP или даже JVM-семейство даёт альтернативные пути и фишки, то Rust не привносит ВООБЩЕ НИЧЕГО кроме агрессивного маркетинга. Причём я никогда не хейтила Rust от чистого сердца, но разобравшись в нём получше поняла, что во-первых на C и С++ писать И ЧИТАТЬ (для меня) намного проще, во-вторых сам язык не несёт вообще никаких критических инноваций, по поводу удобств и производительности разработчика - я это слышу уже годами. Java говорила что она быстрее, удобнее и надёжнее, в итоге паттерны (а на практике чаще антипаттерны) создают настолько шизанутый код, что если бы он был тупо был написан в стиле чистого C - разобраться в нём было бы в разы легче. F# говорил что код можно писать значительно короче и сразу без ошибок. И да, там где задачу можно решить просто в функциональном стиле - F# хорош, как только дело доходит до чего-то другого, проще родить ежа и ужа, чем написать, в итоге производительность разработчика откатывается обратно в 0 или даже хуже.

Да, лучше бы типизированный лисп развивали конечно.

Я после того как осилил лисп смотрю на сиподобные языки как на ужасное нечно. Непонятно зачем вообще сделанное.

>И да, там где задачу можно решить просто в функциональном стиле - F# хорош, как только дело доходит до чего-то другого, проще родить ежа и ужа, чем написать, в итоге производительность разработчика откатывается обратно в 0 или даже хуже.

Думаю всегда можно.
Не всегда наверное нужно.

Я так понимаю F# должен интегрироваться с C# ибо всё на одной платформе, так что штука по идее крутая для дотнетчиков, коим я уже давно не являюсь.

> Java говорила что она быстрее, удобнее и надёжнее, в итоге паттерны (а на практике чаще антипаттерны) создают настолько шизанутый код, что если бы он был тупо был написан в стиле чистого C - разобраться в нём было бы в разы легче

Джава создавалась для интернета вещей, затем сан убили, а оракл натянул сову на глобус, получили в итоге корпоративную джаву с фабриками фабрик порождений парсинга XML классов.

>Rust же до сих пор не вышел из состояния зародыша, НО УЖЕ покрылся ржавчиной (собственно правдивое название), причём язык даже не умудрился привнести вообще ничего нового. На C++ почти на всю функциональность Rust есть свои приёмы, можно без труда писать на C++ в стиле Rust и заиметь все те преимущества (не очень то и существенные) которые он даёт.

Мне нужно написать на расте что нибудь достаточно объемное чтобы как-то об этом судить. Давно собирался, да руки как-то не доходили. Изис Агора Лавкрафт вроде отзывалась положительно о расте, надо в общем самому посмотреть.

А вас случайно на OSDN Conf 2021 не было?

Углубляйся. Даже, можно сказать, погружайся! Смотри только, метаном не задохнись.

Метаном пованивает, когда возвращаюсь C/C++
После Раста весьма прискорбное занятие.

Это ты просто не переоделся после погружений в раст.

Ты же понимаешь, что после Раста это и правда совершенно ниочемные языки?
Особенно пустой C, в C++ хотя бы стандартная либа более-менее что-то из себя представляет (впрочем, нетворка всё равно до сих пор нет)

А можно больше конкретики? Что именно позволяет сделать раст такого, чего нельзя (причем эффективнее) сделать на плюсах?

Вот интересно, ярый фанат раста уже полчаса ничего не отвечает на этот простой вопрос... Отчего бы?

Спать пошёл, не?

Мамка запугала, что за компутером поздно сидит

Он ищет истину! Там где ее нет... заблудшие растоманы такие

> Что именно позволяет сделать раст такого, чего нельзя (причем эффективнее) сделать на плюсах?

Ну вот представь, понадобилось тебе выделить голой памяти через new. Не знаю зачем, просто понадобилось, и ты забыл потом вызвать delete - в плюсах ты получишь ворнинг, а в расте не получишь, потому что для выделения голых байтов, тебе придется нырнуть в unsafe.

Статический анализатор для unsafe кода написать не проблема.

Просто никому не надо, поскольку в расте это исключение, а в плюсах (особенно в старом коде) вокруг и рядом.

Если не знаете зачем понадобилась память, то и ошибки, вероятно, нет: это одна из стратегий работы с памятью. При завершении процесса она вернётся к системе. Ошибкой это будет в цикле, когда и сборщик мусора не всякий справится.

Растовские маркросы - это просто песня. После них в сторону темплейты, даже с концептами, смотреть вообще не хочется.

Ну приведи же пример песни, что-нибудь такое, что заставит всех ахнуть от восхищения и навсегда забыть прочие богомерзкие ЯП! А то на поверку оказывается практически всегда, что растаманы просто не знают C++ и выдают теплое за мягкое )))))

А ты такой наивный, крошка.
Если интересно - сам найдешь.

То есть блеснуть киллер-фичей не могём, понятно. Ладно, не расстраивайся, продолжай надувать щёки...

Захочешь - сам найдешь. Не захочешь - тебе хоть двести фич под нос сунь, все равно плеваться будешь.

Да ладно, слив уже засчитан.

Ну как пример которым пользуются в любой кодовой базе на Rust (А фич у макросов намного больше) - derive макросы

Есть у тебя структура, поставил ей #[derive(Debug)] - и для неё реализован отладочный вывод в консоль (трейт Debug), то же самое с Clone, Copy, PartialEq, Eq, PartialOrd, Ord...

Такую же штуку могут реализовывать библиотеки (Это всё же макросы, а не чот встроенное и заточенное под стандартную библиотеку) - например serde имеет макросы Serialize/Deserialize, которые после добавления позволяют писать данную структуру как json/cbor/xml/bson/msgpack/... (в любой формат, для которого реализована библиотека с поддержкой serde, под protobuf правда такого нет, у него отдельный #[derive(Message)])

Например вот:

let value = json!({
    "code": 200,
    "success": true,
    "payload": {
        "features": [
            "serde",
            "json"
        ]
    }
});

Серьёзно? https://github.com/nlohmann/json

auto j2 = R"(
{
    "happy": true,
    "pi": 3.141
  }
)"_json;

> Серьёзно? https://github.com/nlohmann/json
>

auto j2 = R"( 
> { 
>     "happy": true, 
>     "pi": 3.141 
>   } 
> )"_json;

Ваш вариант - это просто строка. В случае же макросов в Rust можно DSL-синтаксис смешивать с выражениями Rust:

let full_name = "John Doe";
let age_last_year = 42;
let john = json!({
    "name": full_name,
    "age": age_last_year + 1,
    "phones": [
        format!("+44 {}", random_phone())
    ]
});

Ну тогда так, устроит?

 #include <iostream>
 #include <nlohmann/json.hpp>
  
 using json = nlohmann::json;
  
 int main()
 {
     // create JSON values
     json j_empty_init_list = json({});
     json j_object = { {"one", 1}, {"two", 2} };
     json j_array = {1, 2, 3, 4};
     json j_nested_object = { {"one", {1}}, {"two", {1, 2}} };
     json j_nested_array = { {{1}, "one"}, {{1, 2}, "two"} };
  
     // serialize the JSON value
     std::cout << j_empty_init_list << '\n';
     std::cout << j_object << '\n';
     std::cout << j_array << '\n';
     std::cout << j_nested_object << '\n';
     std::cout << j_nested_array << '\n';
 }

> json j_object = { {"one", 1}, {"two", 2} };

Это в JSON будет {"one":1, "two":2} ?

> Ну тогда так, устроит?

Сравни теперь это с вариантом на Rust и поймешь, почему разработчикам больше нравятся его макросы.

Раст переносит гарантии смартпоинтеров в компайл тайм, убирая соответствующий рантайм-оверхед. Цена за это - когнитивная нагрузка, надо вникнуть в принципы, перестроить мышление, ну и временами уговаривать компилятор, чтобы он понял, что тут все окей (поскольку полный статический анализ сделать невозможно ввиду проблемы останова).

В остальном, конечно, разницы особо нет, больше вопрос предпочтений.

Кстати, в теории возможно реализовать аналог компайл-тайм модели Раста на плюсовых темплейтах, они, как-никак, Тьюринг-полные.

Это, конечном будет полный brainfuck, для компиляции которого понадобятся терабайт памяти и пара лет, но в теории :)

> Раст переносит гарантии смартпоинтеров в компайл тайм, убирая соответствующий рантайм-оверхед.

А какой у современных компиляторов оверхед в unique_ptr<>?

У unique_ptr никакого, а вот у shared_ptr есть.

В Расте же compile time refcount.

serde.rs

> Что именно позволяет сделать раст такого, чего нельзя (причем эффективнее) сделать на плюсах?

Писать код без ошибок (инвалидация итераторов, exception unsafety, data races). А насчёт функциональности программ: что такого можно сделать в С++, чего нельзя (причём эффективнее) сделать на ассемблере?

> Писать код без ошибок

Что-то, судя по постоянным растопроблемам, нифига не получается )))) Детка, ни один ЯП не позволяет писать код без ошибок, серебряных пуль не бывает, тебя обманули.

> что такого можно сделать в С++, чего нельзя (причём эффективнее) сделать на ассемблере?

Естественно, все что можно сделать на C++, можно сделать на ассемблере. И все что можно сделать на ржавом, можно сделать на ассемблере. Как это влияет на сравнение плюсов с ржавым?

> что такого можно сделать в С++, чего нельзя (причём
> эффективнее) сделать на ассемблере?

Вычисления во время трансляции. Из ассемблеров только fasm на это способен (я не смотрел остальные, просто угадываю).

Стоп, ты сейчас написал, что C++ не умеет в вычисления на этапе компиляции? Серьезно, я тебя правильно понял? То есть ты признался, что нифига не знаешь C++? Похоже, рассказы про тупость растаманов имеют под собой нехилую основу...

Прошу прощения, неправильно понял мысль, дико извиняюсь.

Дело не в том, что Rust _позволяет_ сделать такого, чего нельзя на плюсах, а в том, что Rust _не позволяет_ делать, в сравнении с плюсами.

У C++ есть два плюса Boost и Qt, ну и сишные либы ему как родные

Буст - весьма специфическая штука и нужна именно языку C++
В Расте заменяется стандартной либой и некоторыми крейтами
Интеграция с Qt есть

А почему ты пишешь C/C++? Не видишь разницы? Еще один товарищ из криокамеры с томиком Ритчи 80-лохматого года издания?

Он как раз видит разницу и она не в пользу раст. Например, на раст невозможно реализовать даже вектор - придётся лезть в ансейф.

На Расте можно что угодно реализовать, а unsafe - часть Раста

Потому что у C++ все те же болячки C и уши из 80-90ых
Да, C++ лучше, особенно для прикладного применения, но все новинки не избавляют его от древних болячек, увы
Они даже побоялись аби нарушить ради увеличения производительности

Метан - он без вкуса и запаха.

Это он природный без запаха, а тут после интенсивной газификации малых водоёмов.

Путаете метан с сероводородом и аммиаком.

А вообще, хочешь совет? Если хочешь реально посмотреть на программирование с новой стороны, попробуй Haskell. Очень интересная, хотя и временами мозговыносящая штука.

На Rust после C++ и Haskell мне было довольно приятно перейти. Теперь на нём фулл-тайм и пишу.

Ты забыл уточнить кое-что важное - пишешь хэлворды за бесплатно. Интересно, какой в этом смысл?

Себя проецируешь, себя и спрашивай ;)

Брат жив?

Спецификация этого раста существует? Строгое описание синтаксиса, ситуации неопределенного поведения, особенности функционирование в среде, автономное функционирование? Срок поддержки текущих спецификаций какой? Вот все современные компиляторы языка С спокойно и без каких-либо проблем компилируют код, написанный в начале 80-х и содержащий кучу вызовов библиотечных функций, включая лонгджампы и сложный форматный ввод/вывод. Код не менялся около сорока лет и сегодня используется без какой-либо доработки в том виде, в котором использовался с самого начала.
Аналолгично и с C++ -- код, написанный в начале 90-х и компилировавшийся semantic C++ и topspeed C++ без проблем сегодня компилируется и собирается с помощью g++. Как обстоит дело с этим у раста? Ныне написанный код скомпилируется в 2035 году? Или нужно будет искать программиста, чтобы он апедйтил исходники от версии к версии этого раста?

Даже видео на эту тему Страуструп запи ывал))) но вы ни понимаете это другое

Правда? А чего для многих проектов указывают конкретные версии компиляторов?
Ибо на последних оно не соберется

Я тебе сектрет открою, там указывают _протестированные_ компиляторы и их версии.

Вообще-то если даже взять один и тот же компилятор Си (одной и той же версии) и попробовать собрать (и запустить) проект в других условиях (например, другая ОС), то уже вылезает тонна проблем. А если ещё и версию поменять, то ещё выползут. А если ещё и другой компилятор взять, то ещё выползут. Как минимум тупо разные UB создадут проблем. Я уж не говорю про такие мелочи, как -Werror делает тонну проектов не собираемых почти всегда (а без этого флага в коде копится ещё больше UB).

Но даже если забить на это, тут ещё проблема в том, что язык превращён в свалку (особенно последние С++).

Кстати говоря, не помню, чтобы в Go был стандарт, но там как раз без проблем можно собирать (и запускать) старые проекты.

> Вообще-то если даже взять один и тот же компилятор Си (одной и
> той же версии) и попробовать собрать (и запустить) проект в других
> условиях (например, другая ОС), то уже вылезает тонна проблем.

Э.. а они точно вылезут из-за компилятора, а не, например, наличия библиотек, или настроек, сделанных при сборке самого компилятора? У нас есть самодельная прошивка, которая собирается GCC разных версий, и при сборке под Linux пришлось только добавлять -fleading-underscore, т.к. в сборке GCC она по-умолчанию выставлена для Windows, а для Linux нет.

> А если ещё и версию поменять, то ещё выползут. А если ещё и
> другой компилятор взять, то ещё выползут.

Вы точно говорите про компилятор C?

> Как минимум тупо разные UB создадут проблем. Я уж не говорю про такие мелочи, как -Werror
> делает тонну проектов не собираемых почти всегда (а без этого флага
> в коде копится ещё больше UB).

И часто Вы встречаете эти UB? Имхо, про них обычно узнают, когда что-то падает, и в итоге выясняется - да, здесь программист положился на UB, а в другой аппаратной платформе/другом компиляторе оно работает (или не работает) по-другому.

Что только люди не сделают. Лишь нормальные языки не учить.Согласен переход с извращения на другое извращение -- несколько разнообразит боль.

А какие есть нормальные с производительностью уровня раста / c++?
И такие, чтоб популярные, а не ним или кристал

> А какие есть нормальные с производительностью уровня раста / c++?
> И такие, чтоб популярные, а не ним или кристал

При чём тут производительность? Если в С++ проблемы с текущей памятью, а в расте с концептуальной перегруженностью (и это только начало) -- как это поможет в написании надёжного софта?

Что ним, что кристалл -- одинаковые поделки любителей, попытка подражания мейнстриму.

Хочешь глоток свежего воздуха? Смотри в сторону Обероно-подобных языков. Например, MultiOberon. Если хочешь зашаливающей производительности -- посмотри на тесты варианта Оберона "Vostok". Там тебе и десктоп, и JVM, и ведроид. Ты сожешь попробовать Оберон прямо сейчас в песочнице браузера. Ссылки гуглятся на раз.

Обероны с GC  поэтому конкуренты не для раста а для Go и D.

> Обероны с GC  поэтому конкуренты не для раста а для Go
> и D.

Кто тебе такую чушь сказал? В 60% реализаций Оберонов нет никакого GC. Оберон успешно запускают (лично я, например), на STM32F4T6. Там памяти, простите за мой французский -- с гулькин нос. Какой там GC? именно в этом и сила Оберонов -- хочешь будет тебе GC, не хочешь -- не будет. Ещё обращу твоё внимание анон: в варианте "Vostok" Оберон откровенно нагибает С++ и заставляет нервничать Си. См. тесты в блогпосте от ComDiv. Ещё раз специально для тебя повторю: на Оберонах написан под десяток операционных систем. Сколько операционных систем написано на Расте, которые испольуются в боевых самолётах, типа "Еврофайтера"? Или сколько управляющих систем на Расте используется на Ростовской атомной станции? На подстанции 110 кВ (как в Калининграде)? Или при управлении БПЛА? Ты пишешь с умным видом глупости по теме, которой совершенно не знаешь.

> В 60% реализаций Оберонов нет никакого GC

Ссылку можно хоть на одну реализацию и чтобы там прямо говорилось что без GC. А то гугль наоборот больше подсовывает ссылки как оберон умеет в GC даже в ядерном коде.

> Ссылку можно хоть на одну реализацию и чтобы там прямо говорилось что
> без GC. А то гугль наоборот больше подсовывает ссылки как оберон
> умеет в GC даже в ядерном коде.

Достаточно на сайте Вирта почитать сообщение  о языке. Там ни слова нет о GC. Я тебе даже дам ссылку на русский перевод. Плохо ищешь.

https://github.com/Spirit-of-Oberon/ProjectOberon2013 -- виртовский Оберон, даже с эмулятором. Нет GC.

https://github.com/AntKrotov/oberon-07-compiler -- работает на ТРЁХ осях. Нет GC.

https://docs.google.com/document/d/14-KQD4UT0_Xd_s7kVHVKa6tx... -- перевод на русский язык, где GC даже не упоминается.

>виртовский Оберон, даже с эмулятором. Нет GC.

Есть GC https://github.com/Spirit-of-Oberon/ProjectOberon2013/blob/m...

>работает на ТРЁХ осях. Нет GC.

Тут да нет, но это не полноценная реализация оберона, код на него леко переносим не будет, сразу потечет. И из-за отсутсвия GC нет одного из самых любых пропагандистами оберон фич - динамической модульности. Про компонентное программирование тоже можно сразу забыть.

>перевод на русский язык, где GC даже не упоминается.

Тут http://www.projectoberon.com/ в pdfках много раз упоминается.

>>виртовский Оберон, даже с эмулятором. Нет GC.
> Есть GC https://github.com/Spirit-of-Oberon/ProjectOberon2013/blob/m...

Хм. Что-то новенькое. Когда последний раз смотрел -- не было. Как по мне -- даже хорошо.

>>работает на ТРЁХ осях. Нет GC.
> Тут да нет, но это не полноценная реализация оберона, код на него
> легко переносим не будет, сразу потечет. И из-за отсутствия GC нет
> одного из самых любых пропагандистами оберон фич - динамической модульности. Про
> компонентное программирование тоже можно сразу забыть.

Код будет перенесён легко. Три оси это доказывают. Динамической модульности нет, да.
Но это не функция языка -- это функция системы. Наоборот, чем меньше фич в ЯЗЫКЕ -- тем легче перенос. Компонентное программирование реализуется не через язык,а через среду. BBCB тебе в помощь.
Если ты внимательно прочитал описание -- там на нормальном буржуйском языке написано, что это не коммерческий вариант. Пацанчег его запили в одну харю. Попробую запили в одну харю Аду или ржавого. Ещё раз отдельно отмечу: существует ДВА ДЕСЯТКА реализаций Оберона одиночками. Переносимость у Оберона -- кратно выше, чем в Си. Зависимость от железа -- нулевая. Именно это главная фича Оберона, а не GC или динамическая модульность.

>>перевод на русский язык, где GC даже не упоминается.
> Тут http://www.projectoberon.com/ в pdfках много раз упоминается.

Нет. Нигде не упоминается обязательность GC. См. реализацию Оберона на основе виртовского от AIXP -- там всё также нет GC.

>Хм. Что-то новенькое. Когда последний раз смотрел -- не было. Как по мне -- даже хорошо.

Судя по пдфкам последний раз 8 лет назад обновленным, оно там всегда было.

>Код будет перенесён легко. Три оси это доказывают

Я про перенос кода с других реализаций оберона, а там GC и все на этой реализации тупо утекет.

>Попробую запили в одну харю Аду или ржавого.

В свое время в одиночку форт пилил, ничего сложного в пилении примитивных языков не вижу.

>Ещё раз отдельно отмечу: существует ДВА ДЕСЯТКА реализаций Оберона одиночками.

Фортов и лиспов еще больше было, часто плохо совместимых, похоже тут та же болезнь.

>Нет. Нигде не упоминается обязательность GC.

Это очень плохо. Теперь более понятна стала для меня непопулярность оберонов. Вообще как-то раньше ставил побаловаться xds oberon,  его умения оптимизации кода тогда впечатлили.

Если уж говорить о промышленных языках, на которых написано вот всякое такое, то это Ada.

А оберон это для узкого круга фанатов, он слишком уж вещь в себе.

> Если уж говорить о промышленных языках, на которых написано вот всякое такое,
> то это Ada.
> А оберон это для узкого круга фанатов, он слишком уж вещь в
> себе.

Нет. Ада это полукоммерческий продукт, который в ардуино ты не запихнёшь при всём желании.
Узкий круг фанатов Оберона, ещё раз для уяснения: фазированная антенная решётка основного боевого самолёта Евросоюза -- "Еврофайтер", швейцарский национальный центр управления дорожным движением. процессинговый центр "Дойчебанка", диспетчерский центр управления каскадом ГРЭС на Амазонке, подсистема резервирования телеметрии на Ростовской АЭС, управляющая программа БПЛА (в России, гуглится на раз), подсистема дорасчёта электрических параметров ПС 110 кВ "Восточная-1" Калининград, система диспетчерского управления перерабатывающих заводов в Орле(2 шт, Мираторг),символьная система расчёта проблемы дефекта массы нейтрино (объединённый центр ядерных исследований, Дубна), комплекс приборов для исследования эффекта люминисценции в биологических растворах (Новосибирск), основы преподавания программирования (клуб "Байтик", Троицк), кружок программирвоания для детей при Новосибирском государственном федеральном университете.

В каком месте это узкий круг фанатов? В каком месте тут хоть раз использована Ада? Пишешь то, о чём не имеешь ни малейшего понятия. Попробуй детям попреподавать Аду -- я на тебя посмотрю. Вот те самые детишки, что освоили Оберон -- будут программировать на нём ВСЁ, и уних не будет болеть голова от концепции владения раста (с его диким синтаксисом) и не думая о том, что такое адресная арифметика, как не поломать память, и всякие низкоуровневые вещи. Но при этом, при необходимости -- всего могут спуститься на аппаратный уровень. Один язык для всегда -- это технологическое преимущество перед всеми остальными, кто сначала учит Васик, потом Паскаль, потом С++, а когда приходят на работу -- оказывается надо было учить питон или пхп какой-нибудь. На Обероне -- для программирования железа даже ассемблер не нужен, как отдельная сущность. Собственно, как отдельной сущности -- ассемблера в Обероне и нет (в отличии от Си, который в ассемблере всё же нуждается -- в сущности, второй язык).

> На Обероне -- для программирования железа даже ассемблер не нужен, как
> отдельная сущность. Собственно, как отдельной сущности -- ассемблера в Обероне и
> нет (в отличии от Си, который в ассемблере всё же нуждается
> -- в сущности, второй язык).

Если не сложно изложите по-подробнее - как Вы без ассемблера сможете в регистре CR0 установить соответствующий бит для перехода в защищенный режим? или загрузить регистр GDTR таблицы GDT?

> Если не сложно изложите по-подробнее - как Вы без ассемблера сможете в
> регистре CR0 установить соответствующий бит для перехода в защищенный режим? или
> загрузить регистр GDTR таблицы GDT?

Оберон -- это ЯВУ. Ему плевать какие есть регистры в процессоре, потому что это уже не ЯВУ. А если таки руки чешутся добраться до железа (за что в Оберонах придётся мягко говоря серьёзно держать ответ перед тимлидом за такие выкрутасы) -- для этого во всех Оберонах есть псевдомодуль SYSTEM (который позволяет творить с железом что угодно и для безопасности -- импорт этого модуля легко детектируется анализатором исходников). SYSTEM (* если прям очень сильно хочется *) может содержать ассемблер, но в сущности -- он просто не нужен.  Манипуляцию с байтами в машинной памяти берёт на себя компилятор (у которого есть высокоуровневые сущности от железа, что существенно снижает вероятность косяков, но не даёт ложную уверенность программисту, что всё будет ништяк).

>> Если не сложно изложите по-подробнее - как Вы без ассемблера сможете в
>> регистре CR0 установить соответствующий бит для перехода в защищенный режим? или
>> загрузить регистр GDTR таблицы GDT?
> Оберон -- это ЯВУ. Ему плевать какие есть регистры в процессоре, потому
> что это уже не ЯВУ.

Ну, несмотря на то, что C до недавнего времени тоже был ЯВУ, и там для повседневной работы тоже не нужно было знать регистры, но мы вроде как про программирование железа - а там, как-раз эти регистры и есть, какие в процессоре, какие отображенные на память (иногда с хитрым поведением, когда для обнуления каких-то определённых бит надо именно эти биты записать в регистр, а иногда, которые просто обнуляются по факту чтения из данного регистра), а какие (в архитектуре 8086+) отображенные на специальное пространство ввода-вывода, к которому доступ идёт спец-командами (in/out).

> но в сущности -- он просто не нужен.  Манипуляцию с
> байтами в машинной памяти берёт на себя компилятор (у которого есть
> высокоуровневые сущности от железа, что существенно снижает вероятность косяков, но не
> даёт ложную уверенность программисту, что всё будет ништяк).

Всё-же не совсем понятно, как Вы можете не используя ассемблер, установить в регистре CR0, бит 0, чтобы перевести процессор в защищенный режим процессора. На память этот регистр не отображается. Ну или всякие взаимодействия с отладочными регистрами DR (мы-же вся так-же про программирование железа, в том числе и настроек самого процессора).

> Ну, несмотря на то, что C до недавнего времени тоже был ЯВУ,...

Си никогда не был ЯВУ.

> и там для повседневной работы тоже не нужно было знать регистры,

Поэтому Си не ЯВУ.

> Всё-же не совсем понятно, как Вы можете не используя ассемблер, установить в
> регистре CR0, бит 0, чтобы перевести процессор в защищенный режим процессора.

Откройте для себя машинные команды.

>> Ну, несмотря на то, что C до недавнего времени тоже был ЯВУ,...
> Си никогда не был ЯВУ.

гм.. вообще-то был, до того, как пошли C++/Java.

>> и там для повседневной работы тоже не нужно было знать регистры,
> Поэтому Си не ЯВУ.

перечитайте фразу на которую отвечаете пожалуйста, если Вы забыли, то я процитирую "там для повседневной работы тоже не нужно было знать регистры".

Как Вы из этого вывели, что C не ЯВУ? или под ЯВУ Вы понимаете что-то другое?

>> Всё-же не совсем понятно, как Вы можете не используя ассемблер, установить в
>> регистре CR0, бит 0, чтобы перевести процессор в защищенный режим процессора.
> Откройте для себя машинные команды.

какие-такие машинные команды, и как можно вписать в программу на Обероне? или как в старых ассемблерах, которые не поддерживали некоторые новые команды лепили что-то типа:

        db 0eah
        dw 0
        dw entry

За него уже деньги платят? Трудяг реальных для интересных и стабильных работ ищут?

> управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора

lockfree без GC, или при чем тут упоминание параллелизма?

Есть там GC, сказки растоманов про некую магию избавлющую от всех проблем это полная туфта

Приведите ссылку на строку(и) кода, благо Rust на Github есть, показывающего что в расте есть GC. Очень интересно посмотреть. Под GC имеется в виду именно runtime\времени исполнения.

Магия?

> Магия?

Да: https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

Ахахаха вот это да сильно... выдавать за ноухау подобие умных указателей C++ !!! Это фиаско братан

На плюсах с умными указателями и RAII в смысле управления памятью и получится примерно Rust.
Принципиальных отличий два (и они тесно взаимосвязаны). Первое - это (почти) нулевой оверхед, поскольку проверки в Расте делаются в компайл-тайм (да, в это сложно поверить, видя впервые, надо вникать :). Второе - невозможность нарушения RAII заложена в дизайн языка, просто не скомпилируется.

Поздравляю с разморозкой.
Лучше бы доку по расту почитал, чем время тратить на такие комментарии.

По секрету... чисто между нами... умные указатели это тоже разновидность GC...прикинь да...

Cемейство: Box, Rc, Arc, Cell и т.д. можно отнести к умным указателям, имеющим runtime overhead. Я уже говорил что говоря о GC имеется именно runtime а не механизм чистки. В основном, всё держится на механизме владения, и там никакого overhead-а нету, + ZST https://doc.rust-lang.org/nomicon/vec-zsts.html (о таком раньше вообще не слышал, если кто знает - дайте ссылку, интересно). Если что-то надо подчистить раньше чем это сделает компилятор - есть функция `drop`.

> + ZST https://doc.rust-lang.org/nomicon/vec-zsts.html
> (о таком раньше вообще не слышал, если кто знает - дайте
> ссылку, интересно).

А для чего нужны эти типы нулевого размера? Какую задачу решают?

Задач несколько, самая простая - это типизация без оберток.
Почитать можно тут
https://www.hardmo.de/article/2021-03-14-zst-proof-types.md#...
https://ferrous-systems.com/blog/zero-sized-references/#diff...

> Задач несколько, самая простая - это типизация без оберток.
> Почитать можно тут
> https://www.hardmo.de/article/2021-03-14-zst-proof-types.md#...
> https://ferrous-systems.com/blog/zero-sized-references/#diff...

Спасибо, во втором случае увидел практический смысл.

В примере имеется два блока памяти, из которых выделяются элементы. Тут есть нюансы:
1. Информация о принадлежности элемента конкретному блоку содержится в адресе элемента.
2. Для задачи "вернуть элемент куда следует" явная обработка вышеуказанной информации не является необходимой.
3. Информация доступна во время исполнения. ZST (по определению) такое не обеспечивает. Насколько понимаю, инстанциируется (я слышал, что темплейты в С++ это жесть, но они это позволяют без ZST) два экземпляра деалокатора.

Наверное, я что-то упустил?

Если честно, то я с ZST знаком теоретически, на практике в моих задачах они просто не были нужны. Но насколько я понимаю вся фишка что проверки типов идут на этапе компиляции, а не в рантайме и в момент компиляции подставится нужный вызов. Ну или просто не скомпилируется.
Так что сори что не смог ответить на вопросы. Нужно спросить кого-то более знающего.

Еще можно глянуть пример PhantomData как частный вариант ZST.
https://doc.rust-lang.org/stable/core/marker/struct.PhantomD...

> Еще можно глянуть пример PhantomData как частный вариант ZST.
> https://doc.rust-lang.org/stable/core/marker/struct.PhantomD...

Я бы дал ссылку на
https://doc.rust-lang.org/nomicon/phantom-data.html

> PhantomData consumes no space, but simulates a field of the given type for the purpose of static analysis. This was deemed to be less error-prone than explicitly telling the type-system the kind of variance that you want, while also providing other useful things such as the information needed by drop check.

там и пример для ZST более лаконичен и поняте не-рустовцам
https://doc.rust-lang.org/nomicon/exotic-sizes.html
> On their own, Zero Sized Types (ZSTs) are, for obvious reasons, pretty useless.

...
> One of the most extreme examples of this is Sets and Maps. Given a Map<Key, Value>, it is common to implement a Set<Key> as just a thin wrapper around Map<Key, UselessJunk>. In many languages, this would necessitate allocating space for UselessJunk and doing work to store and load UselessJunk only to discard it. Proving this unnecessary would be a difficult analysis for the compiler.
> However in Rust, we can just say that Set<Key> = Map<Key, ()>. Now Rust statically knows that every load and store is useless, and no allocation has any size. The result is that the monomorphized code is basically a custom implementation of a HashSet with none of the overhead that HashMap would have to support values.

> А для чего нужны эти типы нулевого размера? Какую задачу решают?

Rust ими активно пользуется в стандартной библиотеке, но в эту сторону я не сильно копал. Задача, на сколько я знаю, это Zero Cost Abstraction, примеры привели выше.

Самое большое впечатление составил этот проект: https://github.com/Rahix/avr-hal , это, грубо говоря, библиотека <Arduino> для Rust. Если посмотреть исходники, становится понятно то как используются ZST. По сути, ZST позволяют управлять потоком исполнения так, как и в случае если у тебя есть объект с данными, т.е. ты можешь обращаться к сущности, задавать или спрашивать некие свойства, хотя, под капотом, сама сущность не хранит никакой информации и её можно было бы заменить на 100500 #define\#if\#ifdef. Это как модуль или область видимости, но в виде объекта и со свойствами объекта. Короче, самое крутое, доведённое до предела использование ZST я, пока что, видел только в avr-hal (за счёт того что для embedded каждый байт на счету).

https://doc.rust-lang.org/stable/embedded-book/static-guaran... не помню где я видел класное описание того как в avr-hal пины\периферия в виде ZST создаются. Там, вроде как, смежный проект для cortex (вместо atmel), книгу написал как ZST можен это обиграть. Может где в issues есть ссылка, я просто, интерес к проэкту на время потерял, не хочу сейчас в нём копаться.

Умные указатели это разновидность автоматического управления памятью, как и сборка мусора. Путаница возникает, поскольку и там и там есть варианты с подсчётом ссылок.

То есть по твоему получается что C++ это тоже язык с GC? Ведь разницы у него с растом по подержке умных кказателей практически нет.

>> управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора
> lockfree без GC, или при чем тут упоминание параллелизма?

Судя по дискуссии, меня не совсем правильно поняли. Я не говорил о GC таком как в Java, C# или D, который прибирает за пользователем всю выделенную память. Я говорил о GC для lockfree структур.

Изначально процитированная часть (не полная) говорит о том, что в rast высокая скорость выполнения параллельных заданий достигается без использования GC и runtime. Тут я предположил 2 вещи о которых может вестись речь: выделение/освобождение памяти и lockfree структуры. Для первого сообщение в новости исключает кастомные аллокаторы, а без них мы не можем выделить памяти без блокировок, так как ходим в ядро. По этому я и спросил только про lockfree, т.к. мне не совсем понятно как можно организовать lockfree-структуру без сборщика мусора.

На пример возьмем односвязный список с 2мя полями - value и next, где next - указатель на следующий элемент, а value - значение, которое нам в примере неинтересно.

Для добавления элемента в список нам нужно создать его - записав значение и nullptr в next, после чего указатель на наш элемент надо добавить в конец списка, для этого через CAS сравниваем и заменяем nullptr поля next последнего элемента списка на указатель на наш новый элемент. Т.к. пока мы искали последний элемент списка он мог перестать быть последним, данная операция выполняется в бесконечном цикле.

Для удаления можно попробовать поступить так же, но если мы после удаления элемента из списка (замена указателя на него nullptr), удалим сам элемент (вызовем delete), то мы можем уронить приложение обращением к освобожденной памяти, из-за того, что другой поток обратился к элементу перед удалением, а прочитал поле из него уже после удаления.

По этому для удаления элементов нужен сборщик мусора, который когда-нибудь таки дернит блокировку и по удаляет элементы (вызовет delete).

О "безопасном" параллелизме в раст пишут только по одной причине. О подмножестве состояний гонки - гонки по данным. "когда разные потоки обращаются к одной ячейке памяти без какой-либо синхронизации и как минимум один из потоков осуществляет запись."

Такое в раст запрещено правилами владения/заимствования и не скомпилируется. Остальные гонки (логические) конечно приведут к дедлокам.

> О "безопасном" параллелизме в раст пишут только по одной причине. О подмножестве
> состояний гонки - гонки по данным. "когда разные потоки обращаются к
> одной ячейке памяти без какой-либо синхронизации и как минимум один из
> потоков осуществляет запись."

Если один _писатель_, то где там гонка? Запись одной ячейки атомарна. Скорее всего, вместо записи имелась ввиду модификация.

Неужели нельзя сделать не столь адовый синтаксис? Такое чувство что это C++ под веществами

Нормальный синтаксис, просто для некоторых незнакомый и непривычный, потому что нет опыта с ML-языками например.

Нормальный? В каком месте? Это же кому то взбрело в голову скрестить ML-языки в которых шарит 3,5 анонимуса и ООП вроде C++/Java/C# которое знают процентов 90... от чего получился Rust который могут понимать все теже 3,5 анонисуса

> ML-языки в которых шарит 3,5 анонимуса

То что вы не шарите, не означает, что шарит мало людей.

> и ООП

И в чём тут проблема? ООП родной подход для функциональных языков.

Аудитория OCaml, F#, Haskell, Lisp как бы намикает на популярность и понятность ФП

Особняком стоит Erlang который также непонятен но кое где взлетел

>Аудитория OCaml, F#, Haskell, Lisp как бы намикает на популярность и понятность ФП

Вы забыли Javascript и Python.

JS в котором любой базовый тип это обьект? Хммм не знал что в ФП все обьект и наследование есть через прототипы, хотя это уже неактуально в новом JS наследование правильное

С чего вы вдруг взяли что в Rust есть ООП? ООП держится на 3х китах: инкапсуляция, наследование, полиморфизм. Можете начать пояснять начиная с наследования.

Ключевое слово "Скрестить" ФП и ООП... понятное дело что нормальным ООП там и не пахнет

Т.е. ваше экспертное мнение таково, что LINQ для C# как и сам С# не состоятелет в силу того что используются 2 таких несовместимых подхода как ФП и ООП?

C# изначально спроектирован как ООП язык, различные фичи добавлялись походу, так что дефолтная концепция не пострадала

Скажи еще что у Java плохое ООП из за того что туда добавили лямбды

RTFM: https://doc.rust-lang.org/book/ch17-00-oop.html

Наследования нет))) лол

Тупо почти структуры...

А чего вы его здесь минусуете? Ну, ведь, действительно же в Rust нет нормального наследования.

Не три кита, а гораздо больше, причем главный из них -- это обмен сообщениями между объектами, чтобы передавать информацию, а не вызовы "методов". Кстати, в C++ вообще нет методов, только функции-члены классов.

> Не три кита, а гораздо больше

Нить рассуждений потеряна. Я выступил с критикой сравнения стуктур в Rust с ООП, в то время как вы.. не знаю о чём говорите.

>> Не три кита, а гораздо больше
> Нить рассуждений потеряна. Я выступил с критикой сравнения стуктур в Rust с
> ООП, в то время как вы.. не знаю о чём говорите.

О том, что "три кита" инкапсуляция, наследование, полиморфизм для ООП вторичны, а первичен обмен сообщениями. Эти три кита появились в дискурсе потому, что не смогли в сообщения.

>инкапсуляция, наследование, полиморфиз

Никакого отношения к ООП не имеет.
Это система типов страуструпа.

Бредишь истинным ООП Алана Кея на клеточном уровне? Лол конечно, но это лютые тормоза... для примера можешь написать программу где каждая функция будет отдельным процессом и любой чих будет вызывать ОС для передачи сообщений через пайпы

Концепция не имеет никакого отношения к вопросам производительности. Концепция - одно, реализация - другое.

Наследование всегда можно заменить композицией. В симула-подобных языках это неудобно, но технически ничто не мешает.

А вот полиморфизм обязателен - это просто другая формулировка принципа контрактов. А без виртуальных функций с соответствующим оверхедом никакого полиморфизма не будет, так что всегда в общем случае будет dispatch table. Называть это вызовом метода или обменом сообщениями - вопрос терминологии, суть та же. Принимать «неизвестные сообщения» (скажем, в специальный метод, как в Ruby), или не давать такое скомпилировать - вопрос дизайна языка, добавить или убрать случай «not found in dispatch table» можно всегда».

Инкапсуляция тоже обязательна, но она может быть и неявно выражена в языке.

Действительно я то думал, че смолтолк так взлетел с его передачей сообщений! Прям да, тормоз был всех времен и народов

На трёх китах держится плоская земля. А для ООП достаточно понятия контракта и объекта как чёрного ящика, поддерживающего контракты.

Способ реализации в плюсах, позаимствованный из Симулы - это лишь способ реализации. Читайте Алана Кея, короче.

ООП Кея больше подходит для сетей, в чем и нашло себя в виде микросервисов.... но в программе ООП по Кею не канает

Если воспринимать буквально, то не канает.

А если немного переформулировать, и добавить типизации (что намного чаще полезно, чем вредно), то получается:

1. Есть контракты, описывающие по сути сигнатуры методов,
2. Есть объекты, которые снаружи "черные ящики", о которых известно, что они поддерживают определенные контракты,
3. Нет привязки к конкретным объектам, есть привязка к контрактам.

Тогда внезапно получается, что:
1. Инксапсуляция нужна ("черный ящик", во внутренности которого не лезем),
2. Полиморфизм нужен (привязка к контрактам, конкретный объект не важен),
3. А вот наследование вообще мимо. И, действительно, наследование всегда заменяется композицией, и зачастую в языках, где есть наследование, композиция предпочтительнее (см. composite reuse principle).

При этом и Rust, и Go получаются вполне себе ООП.

Другими словами, представь себе, что в С++ ты можешь наследоваться только от pure abstract классов. После чего, чтобы не городить кучу микрообъектов и ручное делегирование, добавим трейты как в Scala.

Что-то принципиально изменилось? Да ничего.

> Нормальный синтаксис, просто для некоторых незнакомый и непривычный, потому что нет опыта
> с ML-языками например.

Это не синтаксис. Когда вместо return пишется просто значение - в случае ML это семантика. Получается, что Rust исходно функциональный с императивными возможностями. Отсюда все споры и отторжение его как "замены Си".

Адовый синтаксис только если использовать дженерики и указание времён жизни. Но есть секрет - можно их не использовать :-D

А ещё можно разобраться в том как это всё работает, говорят помогает. + относительно новые версии раста много чего уже делают сами (вроде как в 1.28+ много сахара добавили)

Из всех языков на выбор, ты выбрал C++ для сравнения? C++?

С его шаблонами шаблонов шаблонов, где чёрт ногу сломит понять, как и что устроено, если писал не ты? И они при этом _не могут_ полностью заменить макросы для такой банальной вещи, как определить, под какую ОС компилируем.

Язык, в котором в try catch можно упихнуть всю функцию, примерно так:

void func() try {} catch(...) {}

Язык, в котором для проброса rvalue-ссылок нужно городить огород из шаблонов и std::forward? Вместе с самими rvalue/lvalue ссылками.

Язык, в котором до недавней редакции простая конкатенация векторов превращалась в квест с двумя begin'ами и одни end'ом?

Вместе с тем в новой редакции появились концепты с ещё одним новым, интересным синтаксисом?

Да по библиотекам, unique_ptr должен был быть очень простой, очень эффективной обёрткой над обычным указателем, с буквально нулевым оверхедом. Гугловцы выяснили, что оверхед дам огого, и без поломки совместимости это не исправить.

По самыми медленными регулярками в одном из самых быстрых языков только ленивый не прошёлся.

Тут доолллго продолжать можно. Можешь Мейерса почитать, там все эти кейсы прекрасно описаны. Да, у них была причина. Да, обратная совместимость, да, исторические причины, но суть это не меняет.

Rust -- это C++ без веществ, а не наоборот. Не уверен, помогут ли эпохи остаться таковым, но очень надеюсь.

Чего мне не хватает в нём -- это пользовательские литералы, типа 10ms вместо Duration::from_millis(10). Было предложение, но что-то заглохло.

Если постараться, на Rust можно написать код который будет куда хуже того что вы привели. Много кто из новичков жалуется не неочевидность trait-ов. Библиотеки, в том числе стандартная, имеет тенденцию раскрывать потенциал структур через trait-ы, например используя `std::fs::File` нужно ещё `std::io::{Read, Write}` подключить. Обращу ваше внимание что они даже не в одном модуле находятся. И эта же ситуация возникает повсеместно во всех crate-ах, это уложняет понимание библитек без хорошой документации. В целом, ко всему есть доступ, но путаница всё равно возникает.

Ещё можно критиковать Rust за сырость и относительно частые deprecation. На С++ можно использовать последнюю версию GCC\Clang и просто ставить `std=c++11` или какую либо ещё версию, обновляется ли rustc\cargo если ставишь override на старую версию не знаю. Тот же С++ с нами уже очень давно, много проблем уже обросли костылями.

> Обращу ваше внимание что они даже не в одном модуле находятся.

В генерируемой документации есть ссылки на все трейты типа. Ты можешь вниз прокрутить, или в боковой панели посмотреть. И им не надо находиться здесь: что такое трейт Read, Write, я знаю и так. Когда используешь крейт постоянно (например std) все основные трейты его знаешь, иногда реализуешь их не консультируясь с документацией на тему того, как там в точности выглядит декларация методов. В std таких грядка -- Read, Write, Iterator, PartialEq, PartialOrd ... Их запоминаешь со временем примерно так же, как в C++ запоминаешь как перегружать те или иные операторы, и пишешь заголовок int operator+(чётотам) не консультируясь с документацией.

> это уложняет понимание библитек без хорошой документации.

Да. Но без документации разобраться сложно с библитекой на любом языке. В расте же есть гарантия документации -- может быть плохой документации, если разработчик не озаботился, но по-крайней мере иерархический html, с модулями, типами, с трейтами типов, и всякой прочей информацией ты получишь. Этим может заниматься IDE, наверное, выводя всю информацию о типах, но я пользуюсь сгенерённой документацией. Потому как не нашёл способ сделать всё это удобно в emacs -- всплывающие кстати и некстати подсказки я пробовал, мне они мешают. Может можно сделать, чтобы отдельная панель была для отображения структурированной информации, но emacs не дружит с мышью, её поддержка сделана через привычное для emacs'а место костылями, поэтому я предпочитаю браузер.

> Библиотеки, в том числе стандартная, имеет тенденцию раскрывать потенциал структур через trait-ы, например используя `std::fs::File` нужно ещё `std::io::{Read, Write}` подключить.

Да, это раздражает иногда. В качестве обходного манёвра библиотеки часто предоставляют модуль prelude, который можно импортировать все трейты сразу. Хотя я предпочитаю без этого: когда вручную импортируешь трейт за трейтом, особенно из новой для себя библиотеки, лучше понимаешь происходящее. Потом, когда происходящее стало понятно, можно и prelude импортировать.

> На С++ можно использовать последнюю версию GCC\Clang и просто ставить `std=c++11` или какую либо ещё версию, обновляется ли rustc\cargo если ставишь override на старую версию не знаю.

В расте есть эдишны. Edition 2015, Edition 2018, и тут на подходе Edition 2021. Ты можешь использовать распоследний компилятор с любым эдишном.

Не знаю, может меня не так поняли, я Rust пользуюсь, относительно, давно. Критика была не вида "в Rust нету .." а, скорее, "хотелось бы чтобы было ..". Я понимаю, что к Rust можно привыкнуть, или, как минимум, попытаться. Да и то что я им пользуюсь никак не умоляет факт наличия косяков, ну прям совсем.

Ключевое слово "Синтаксис" C++, а не детали реализации его стандартной либы или грязных костылей во имя совсестимости...

А Rust чисто синтаксис адовее C++ и это без всяких требований обратной совместимости не только с C98 но и с C89...

Казалось бы делайте с чистого листа, вы не обременены различными комитетами но все как всегда

*C++98

Серьезно, прочитайте уже https://habr.com/ru/post/532660/ а то опять про синтаксис, когда не в нем проблема. А в новых фичах, которых нет в С++ - отсюда сложность.

Хорошая ссылка. Но мне кажется не поможет. Люди лезущие на баррикады из-за синтаксиса -- это безмозглые фанатики с мозгами отутюженными идеологией. Им бесполезно что-то объяснять.

Когда люди лезут на баррикады с горящими факелами потому, что растовый борроу-чекер им не позволяет что-то сделать -- это можно понять. Человеку приходится переучиваться и находить новые для себя способы выразить свою программерскую мысль, и когда борроу-чекер непонятен, им непонятно зачем всё это, и естественно это вызывает раздражение. И в этих случах, как показывает практика, помогают подробные объяснения того, почему борроу-чекер в данном случае ругается, каких ошибок это позволяет избежать, и как можно сделать, чтобы он не ругался. Это помогает даже в тех случаях, когда в данном конкретном случае борроу-чекер не прав, когда он слишком туп, чтобы понять безопасность кода.

Но когда претензии к синтаксису -- это всё, сливай воду.

Ты ссылку на хабр кинь пацанам из Microsoft, а то они не знали как нужно  и значит сделали C# с одним из самых чистых и читаемых синтаксисов в статически типизированных языках

Как-то по последним версиям шарпа не видно что это "одним из самых чистых и читаемых синтаксисов в статически типизированных языках" там уже навортили почти как в C++. Хотя у ms есть такой чистый и очень читабельный язык - это F#.

А как же сборщик мусора в виртуальной машине? Это сильно упрощает многое по синтаксису кмк.

Даже если вручную удалять обьекты в C# синтаксис читается сразу, а не после пару банок темного нефильтрованного

> И они при этом _не могут_ полностью заменить макросы для такой банальной вещи, как определить, под какую ОС компилируем

Ты правда настаиваешь, что

#[cfg(target_os = "macos")]
fn macos_only() {
  // ...
}

чем-то принципиально лучше чем

#ifdef __linux__
void linux_only() { 
}
#endif

?
Как по мне, те же шарики, вид сбоку. Как минимум, в сишном варианте писать меньше: можно в один блок насовать много платформоспецифичного.

> Язык, в котором в try catch можно упихнуть всю функцию, примерно так: void func() try {} catch(...) {}

Да просто как жить-то теперь?

> Язык, в котором для проброса rvalue-ссылок нужно городить огород из шаблонов и std::forward? Вместе с самими rvalue/lvalue ссылками.

о, ты слышал про std::forward, молодец. а про std::move слышал?

> Да по библиотекам, unique_ptr должен был быть очень простой, очень эффективной обёрткой над обычным указателем

Он такой и есть ))

> Вместе с тем в новой редакции появились концепты с ещё одним новым, интересным синтаксисом?

Появились, и что? Полезная штука.

template<int N>
concept power_of_two = (N & (N-1)) == 0;
template<int N = 256>
auto fft(/*...*/) requires power_of_two<N> {
    cout << "Doing fast Fourier transform by " << N << " samples." << endl;
    //...
}

проделай такое на ржавом, пример в студию.

Зря спорите, по хитровыкрученным конструкциям оба хороши.

>проделай на расте

Я не тот чел, но вот константная функция которая вычисляется во время компиляции.

const fn power_of_two(n: u32) -> u32 {
    if n & (n-1) != 0 { panic!("oops"); }
    return n;
}

Нет, мне не нужно, чтобы функция вычислялась в компайл-тайме, мне нужно, чтобы компилятор проверил, что шаблон параметризуется не абы каким целым N, а степенью двойки. А работать функция должна в рантайме, выполняя N-точечное БПФ на данных, скажем, читаемых из файла.

Пока не запилили в языке, вот таким макросом можно:

macro_rules! const_assert {
    ($x:expr $(,)?) => {
        const _: [(); 0 - !{ const ASSERT: bool = $x; ASSERT } as usize] = [];
    };
}

Это ассерт статических значений - стадии компиляции. (Из крейта static_assertions)

Мои глаза.... Ты должен мне глаза!

> Мои глаза.... Ты должен мне глаза!

Как художник художнику, у нас C++ программистов в этих глазах такое бревно, что должно быть стыдно такое про раст писать.

Чем-то отличается от устаревшего?

#define STATIC_ASSERT(COND,MSG) typedef char static_assertion_##MSG[(COND)?1:-1]

Серьезно? Смотри, static_assert в C++:

template<int N = 256>
auto fft(/*...*/) {
    static_assert((N & (N-1)) == 0, "Assert message");
    cout << "Doing fast Fourier transform by " << N << " samples." << endl;
    // ...
}

> Серьезно? Смотри, static_assert в C++:
>

template<int N = 256> 
> auto fft(/*...*/) { 
>     static_assert((N & (N-1)) == 0, "Assert message"); 

"Серьезно? Смотри, жопа!"
Он привел _реализацию_ static_assert на мкаросах (а не вызов

const_assert!(std::mem::size_of::<String>() == 24);)

ты - просто вызов (реализованной где-то в недрах компилятора).

Ты не поверишь, какой магии можно накрутить в C++, но разве этим стоит хвастаться? По-моему, реализованный в компиляторе static_assert в миллион раз лучше всяких коловерчений на расте, не говоря уж про концепты. Именно эту мысль и хотелось подчеркнуть )

Какой язык выбрать новичку для изучения, чтобы потом грести бабло лопатой? rust, haskell, js, vlang, crystal, zig, java? Как я понимаю большие деньги можно заработать в кровавом энтерпрайзе, а они любят джавку, поэтому выбирать и не приходится. Только java?

Выбирать лучше предметную область, а не язык.

Бред сказал... тип ну например он выбрал веб и тут... бац!!!
PHP
Python
Ruby
Бац
Java
C#
Бац бац
Go

> Бред сказал... тип ну например он выбрал веб и тут... бац!!!

Javascript.

Typescript
Бац бац

Вжух! И в продакшен!

Вжух и в продакшен - это Electron.

Веб - слишком широкое понятие. Там например есть и фронт, и бэк. Поэтому странно просто выбрать "веб". Это как выбрать "прикладное программирование". Лучше чем ничего, потому что отсекает какое-то множество языков, но всё ещё недостаточно специализировано, чтобы остановиться на паре.

А это уже абстракция реального мира за который так критикуют ООП они могут быть сколь угодно вложенными друг в друга, совсем другое дело манямирки зумеров у них все просто и понятно... ровно до того момента написания кода

> Какой язык выбрать новичку для изучения, чтобы потом грести бабло лопатой?

Русский, английский. Язык бизнес отношений и социальных связей.

>rust, haskell, js, vlang, crystal, zig, java?

Точно не поможет.

> Как я понимаю большие деньги
> можно заработать в кровавом энтерпрайзе

Нельзя.

Какие-то особые доходы есть сейчас у "блокчейн девелоперов", криптография вот это всё.
И, чуть поскромнее в машинном обучении и ИИ.
Попробуйте поучиться контракты для эфира писать.

Когда заработаете много денег отпишитесь, дам кошелёк для доната.

У нас только в банковском ИТ секторе водятся деньги, а там Java и C#

Все остальное это или 30-50 тыщ на госконторах или кукишь в статапах из сколково

А "у нас" это где? Учитывая что сейчас можно удалённо работать примерно где угодно и деньги там отличаются на порядок. И это вовсе не говномешалки блокчейна или стартупы с "гибким графиком" на котором вас будут гнуть во все стороны в любое время дня и ночи.

Да и по ЯП особо плотного зажима в отрасли вроде как нет. Нормальным спецам платят везде.

В рфии на полную ставку официально, а так да аутсорс интернационален... но ипотеку под него не возьмешь((( таки дела

> В рфии на полную ставку официально, а так да аутсорс интернационален... но

Вы что, эникей что-ли? Сейчас на удалёнку берут в обычные организации где стандартное 5/2 и раньше все ходили в офис, но теперь то же самое из дома. Сам в такой работаю, у нас уже пол отдела в офисе ни разу не было и контора на несколько сот человек приросла с начала ковида. Понятное дело что там полный соцпакет и т.д. И таких контор на рынке вообще-то не одна и не две, а чуть более чем дофига и кадровый дефицит серьёзный.

> ипотеку под него не возьмешь((( таки дела

Мне тут недавно банк где зарплатный проект ипотеку на 25 млн. предлагал. Такие дела.

Если вбелую через ИП работать, и ИП больше, чем пара лет - никаких проблем нет.

>У нас только в банковском ИТ секторе водятся деньги, а там Java и C#

Может у вас местные "царьки" бизнеса до сих пор живут по принципу рабовладельцев рассуждая "зачем босоте платить больше если все равно ни куда не денутся", но как мне кажется таких уже давно накрыл кадровый голод. Последних несколько лет толковый бизнес всех кто хочет, умеет и самое главное может у таких увел. Сейчас бьются между собой подымая планки годовых доходов. И условия все: хочешь переезд, хочешь удаленка, хочешь особый график, некоторые идут уже дальше, например "а собирайтесь как вы всей группой и поработайте в рамках рабочего расписания пару недель из крыма, сочи или турции, заодно отдохнете, вот вам билеты и гостиница"

Ну а если сидеть вздыхать у местных "инноваторов" которые тупо перехватывают заказы за более мелкий прайс и потом ищут разработчиков-дурачков которые им все сделают дешево да так чтобы они еще и в плюсе остались. Или работать в канторе где весь зп фонд распределен между "своим" кругом под названием "управление" и слушать "сказки о тяжелом времени и так у всех" то конечно жизнь будет серой и нерадостной.

>Все остальное это или 30-50 тыщ на госконторах или кукишь в статапах из сколково

Такие предложения только для неумех от которых требуется просто занимать штатное расписание и что-то делать с переменным успехом. Сейчас даже джуны прикладывающие усилия для проф развития и способные достичь успеха претендуют на большое.

В кровавом только два языка жабка и дотнет

Пых ещё, как ни странно. Почти во всех кровавых ныне там, где нужна пристойная морда.

Пых никуда не делся и все так же монопольно властвует в сети со своими то 70% то 80%

Да. Ентерпрайзу плевать на язык, он деньги делает и время экономит, поэтому использует языки с мощными фреймворками. А инты в циклах, кто быстрее, пацаны на форумах считают ...

Английский.
В худшем случае - китайский.

Выбирай Rust и осваивай разработку под Solana или Polkadot.

Всё также полдня собирается?

Бесплатно ништяков не бывает, за всё надо чем-то платить. Был бы Rust как Go - собирался бы так же быстро, как и Go.

В чем реальное преимущество Rust над Gо?

Го не орут на каждом шагу что безопасный. Хотя куда уж более безопасный.

Ну да, они просто им пользуются... а не мечтают изобрести чудоязык

Я пользуюсь Go и всё мечтаю заиметь immutable как в Rust :(

Преимущество в одном контексте является недостатком в другом. Rust как язык мощнее Go, но если команда на 75% из джунов, то это минус. Джуны на Go напишут лучше и быстрее, чем на Rust.

Так Go лучше получается?

И кстати да, за широкими как галактика возможностями это к C++, но это вещь в себе

> Так Go лучше получается?

Го хорошо подходит для написания сетевых сервисов.
Он именно для этого и создавался.
Ну или для чего-то с интенсивным IO.

Для всего остального, уже не так интересно.

Ниша Go уже давно обозначена...

А для чего хорошо подходит Rust?

Раст универсальный, тоесть для всего.

Впрочем, время написания на нём больше чем на динамических языках вроде питона жс или лиспа. По слухам. Надо бы проверить.

Поэтому видимо не очень для прототипирования, и для каких-то наколенных скриптов.

В тоже время есть патерн матчинг, и макросы, так что может быть и с этим всё окей.

Что лучше - лопата или экскаватор?

Правильно, зависит от задачи.

Так раст - это и есть лопата, в отличие от экскаватора Го. По скорости разработки, конечно. Зато потом скорость выполнения программ будет аж в 2-3 раза выше. Это ж жуть какая производительность!! ))

Так написанно как будто го может на порядки ускорить разработку, такое видел только со скриптовыми языками и с готовыми библиотеками под задачу.

>В чем реальное преимущество Rust над Gо?

Ты ещё С++ с PHP сравни.

Не могу, PHP интерпретируемый ЯП, C++ компилируемый ЯП

А вот Rust и Go можно оба компилируемые, оба с GC в исполняемом файле, оба с недоООП, оба системные

Только вот Go показал себя как годную технологию, а Rust как манямирок для идиотов вроде тебя

> А вот Rust и Go можно
> оба с GC в исполняемом файле,
> оба системные

Все продолжаешь газифицировать лужи?

Про GC в расте это тролинг?

Там просто статический ГЦ. Кстати, он не всегда лучше динамического ))

Нет там ни какого статического GC. Там точно такой же контроль времени жизни и использование raii как и в C++. Отличие только в жестком контроле компилятора над ссылками и в перемещении вместо копирования по умолчанию.

Ты элементарной грамоте научись сначала, а потом уже будешь разглагольствовать о том, есть там GC или нет.

Если человеку нечего сказать по существу он резко становится громотеем. А настоящий статический GC конечно были попытки реализовать, но что-то реальное получилось только на регионах https://en.m.wikipedia.org/wiki/Region-based_memory_management и толком нигде не прижилось.  

Имхо конечно, но пока растоманы кричат какой ржавый отполированный и блестящий, чуваки на Go просто пишут софт

Казалось бы причём тут Go

На Go есть реальные сложные проэкты которые доказывают состоятельность разработки на этом языке... а что есть на Rust?

На Расте тоже дохрена всего, достаточно просто поискать :)

Гонишь

avr-hal имеет аналог для Go? https://github.com/Rahix/avr-hal
+100500 других проэктов разрабатываемых энтузиастами (server less на cloudflare и webassembly ещё один интересный проэкт, название ток забыл)

Замечу что Rust не соревнуется с Python или Go потому что у него задачи\возможности другие, а не потому что он хуже\лучше.

Бред какой то... кому это нужно?

Если вы о Go, я с вами полностью согласен (хотя отголоски разума всё таки говорят что на нём почти как на python код пишется, легко и непринуждённо)

Смешной

Если долго вглядываться в код на расте, скоро раст начнет вглядываться в тебя

Виджетов нет, IDE нет. Софта на расте тоже не видно, так наколенные поделки качества хуже чем на питоне

> Виджетов нет, IDE нет. Софта на расте тоже не видно, так наколенные
> поделки качества хуже чем на питоне

Есть забытое искусство писать без IDE, функциональные языки позволяют это делать продуктивно.

Ну и таки, интеграция с VScode у раста отличная. Есть и Эклипс например. Чего тебе ещё собака надо?

Есть забытое исскуство работать с памятью. Но это конечно другое.

IDE я не панацея от всего. Но элементарно хочется не просто подсветку синтаксиса, а контекстную навигацию, контекстный рефакторинг и элементарно встроенную документацию.

VSCode на минутку вообще ниразу ни IDE, это редактор текста с подсветкой синтаксиса. Он вообще ничего не умеет. Нужно тянуть васянские конфликтующие между собой плагины и мудохаться с всяки *опа сприптом. Писать код в броузере - жуйте сами.

Эклипс? Это то чудовище у которого по непонятным причинам вечно что-то слетает? То индексация то ещё чего. Спасибо, нэнадо.

Что до emacs, то опять таки, поддержка базовая. Просто поставить и наслаждаться языком не выйдет. Вечное мудохавство. Нафига оно тогда надо если есть нормальные языки где с этим всё впорядке.

C/C++ нет никаких проблем. А в современных плюсах даже не нужно забытое исскуство работы с памятью. Этих проблем там нет уже 100 лет в обед.

Так что собаки берите это ржавое и топайте в будку.

>Есть забытое исскуство работать с памятью. Но это конечно другое.

Это как искусство вспахивать поле лопатой.
И не исскуство, и хорошо никогда не получалось.

>а контекстную навигацию, контекстный рефакторинг и элементарно встроенную документацию.

Для раста этого нет?

>Нафига оно тогда надо если есть нормальные языки где с этим всё впорядке.

С емасом всё в порядке, или с эклипсом?

>C/C++ нет никаких проблем.

Ну нет так нет. Главное 3 раза по 3 перед сном повторить.

>Так что собаки берите это ржавое и топайте в будку.

Злой вы, как собака.

>Есть забытое исскуство работать с памятью. Но это конечно другое.

Это миф, до сих пор всплывают уязвимости в коде с возрастом больше десяти лет.

Idea вполне ок с растом.

>Виджетов нет

60FPS.

>IDE нет

Qt Creator + rust-analyzer

А можно подробнее про QtCreator и раст?

Скорее всего, имеется ввиду поддержка LSP. То есть QtCreator точно так же как и VSCode при просмотре исходников подгружал и выполнял код. :) https://opennet.ru/55159-rust

Растоманы советуют плюсовую RAD QtCreator для разработки на расте...Теперь я слышал все

Плюсисты давно сидят в IDE написаных на яве, шарпе и даже на лиспе.

Нет софта нет проблем...стабильность!

Барин за слова не отвечает: Rust Language Server в виде Rust analyzer 100 лет как есть. Можно что на Vim что на VS Code писать с одинаковой степенью интеграции. VS Code даже дебажить через gdb может, если напрягает запуск с терминала.

Барин тупит?

Где контекстный поиск? Где контекстный рефакторинг? Где интерактивная справка? Или у тебя ide это только подстветка синтаксиса.

Не удивительно что ты VSCode к IDE приплёл. Потому что кроме подсветки синтаксиса оно ничего не умеет. Или обмазывайся васянскими дырявыми тырящими всё на свете плагинами. Ни в одной серьёзной канторе тебе такое не позволят.

С language server. Тоже мне. Нахрена мне ещё сервер какой-то там пускать если у нормальных языков и так всё без проблем. Оно это только ржавое не хочет ворочаться нигде.

Но что меня обрадовало. Тут упомянули что QtCreator что-то может. А это уже заявка. Если доведут поддержку до ума это будет действительно прорыв для rust.

> Барин тупит?

Да, барин тупит вместо того что бы посмотреть возможности VSCode c плагинами.
Барин не понимает, что IDE это и есть редактор кода с плагинами в большинстве своем.
По крайней мере, мне не извесно ни одного монолитного (без плагинов) IDE.

>Потому что кроме подсветки синтаксиса оно ничего не умеет.

Вот тут барин просто нагло врет.

>С language server. Тоже мне. Нахрена мне ещё сервер какой-то там пускать если у нормальных языков и так всё без проблем.

А вот тут барин опять проявил свою тупость, лень и незнание. Т.к.  нормальные языки и IDE с поддержкой нормальных языков не стесняються пользоваться серверами языков. Барин может загуглить что такое clangd, например, и в каких IDE он используется.

>Где контекстный поиск? Где контекстный рефакторинг? Где интерактивная справка? Или у тебя ide это только подстветка синтаксиса.

Все это и больше, в плагине руста для иде от jetbrains. У меня например усановлен в clion и работает по моему лучше чем сам clion с С++.

нечеловечески чудовищно плюсую!

У меня VSCode всё это умеет. У нас разные VSCode?

> Где контекстный поиск? Где контекстный рефакторинг? Где интерактивная справка?

neovim + lsp + language server + конфигурация (neovim_rust, например). Всё есть, но требуется навык работы с вимом, да.

Если хочется прям IDE, то IntelliJ Rust есть.

Вариантов для создания UI полно. Вопрос в том, зачем писать тот UI на языке, который для этого плохо подходит (Rust, C, C++, Java, etc)
Оптимальнее использовать core на Rust и что угодно иное для интерфейса

По IDE:
- rust analyzer действительно мощная штука, активно развивается.
vscode, vim, etc
- IntelliJ Rust, официальный плагин от JetBrains
Интересен своим собственным парсером, не лишен интеграции cargo check

Всё отлично с IDE.

>зачем писать тот UI на языке, который для этого плохо подходит (Rust, C, C++, Java, etc)

Из перечисленных, C++ для (G)UI подходит лучше всего. Потому, что Qt, FLTK, FOX и менее известные.

Сила Qt как раз в выносе интерфейса в отдельный декларативный язык
А на виджеты они уже в целом забили

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust - это вот всё кто разгребать будет? Или они только и могут на других вину сваливать?

И это наминутку не в софте на расте. Это в САМОМ расте

> И это наминутку не в софте на расте. Это в САМОМ расте
>Deno is a runtime for JavaScript and TypeScript that uses V8
>Это в САМОМ расте

Чё?

> И это наминутку не в софте на расте. Это в САМОМ расте

В первой же дыре код на _Си_ "A flaw was discovered in GNU libiberty within demangle_path() in rust-demangle.c". В остальном дыры в unsafe-блоках  каких-то левых crate-модулей.

CVE-2020-36317, CVE-2020-36318, CVE-2020-36323, CVE-2021-31162, CVE-2021-28875 - CVE-2021-28879 тоже левые крейты? И как понять, какие крейты левые, а какие - одобренные к использованию?

Это всё дыры в unsafe-коде. Залатают.

Фишка в том, что unsafe-код базовых библиотек конечен, за несколько лет всех блох словят. Главное не добавлять нового unsafe-кода без крайней нужды.

Ничего у вас не получится - unsafe в Расте будет всегда!

Да здравствует unsafe в Расте!

Ну так в этом и смысл
В либах он есть, а программист чаще всего не нуждается

В любом случае, это лучше 100% unsafe

> Ну так в этом и смысл
> В либах он есть, а программист чаще всего не нуждается

Возможно, но пока, судя по количеству CVE, и по просмотру некоторых проектов, складывается, возможно не верное, впечатление, что что-либо сделать на Rust нетривиальное требует этого самого unsafe. Т.е. количество unsafe-кода явно больше, чем это декларируется.

> Это всё дыры в unsafe-коде. Залатают.

Ну а так - и в C, C++ и прочих языках, в библиотеках тоже ошибки исправляются, хотя это иногда кажется невероятным.

Раньше все отнекивался от раста и думал, что это очередной распиаренный проходняк. Но на днях решил попробовать на вкус, что это такое. Скачал компилятор, открыл растбук и начал писать код. И знаете, что? Мне понравилось, такого хорошего языка я еще не встречал. С первого взгляда зацепил, зараза. Поэтому желаю языку дальнейшего развития, чтобы однажды перейти на него полностью.

Какой-то п0pн0рассказ...

Похоже, что на свет уже появилась такая сущность, как "растоботы".

Дайте угадаю, вы еще ни одной строчки на расте не написали, верно?

На самом деле как только нормальные батарейки появятся, так сразу. Скорее всего, многим людям всё равно на чём писать, да и в целом люди любят нескучный синтаксис (позволяет тешить чсв), так что это единственная преграда (практически в текущем состоянии мало кому интересно для прикладных задач). Какой смысл писать на языке, на котором тебе придётся всё изобретать самому? Хотя, конечно, зависит от задач, где-то и можно впихнуть. Но скорее на расте всё равно придётся реализовывать только какую-то часть логики. Ну вот вроде сложные и опасные задачи сложения строк или перебора массивов, на остальное как видится раст не способен.

За батарейками иди в Питон. Здесь тебе делать нечего.

> За батарейками иди в Питон. Здесь тебе делать нечего.

Или в си. Или в плюсы, да.

> Какой смысл писать на языке, на котором тебе придётся всё изобретать самому?

Верно, поэтому и выбирают Раст, поскольку не хочется велосипедить на C, где ничего нет из коробки

>> Какой смысл писать на языке, на котором тебе придётся всё изобретать самому?
> Верно, поэтому и выбирают Раст, поскольку не хочется велосипедить на C, где
> ничего нет из коробки

Для си конечно нет фреймворков уровня Qt, но примерно весь код на свете это либо си и плюсы, либо джава. Если говорить о готовых, пригодных к использованию компонентах. И, что немаловажно, проверенных и оттестированных.

Я написал. И моей целью было сделать так чтобы в safe он упал. И прикинь. Он упал. Грохнулся с треском.

Пример я сюда уже кидал. Повторять не буду. И знаете что? Правиль, модератор скрыл сообщение. Потому что растоманы лицемеры. Но не удалил, так что его можно найти и раскрыть.

А пример в этом треде? Если нет, то дайте наводку, чтобы я смог найти его.

Пример не в этом треде. Наводка rust падает точно также как современный C++ в тех-же местах.

Буду дома залогинюсь и найду точно.

> А пример в этом треде? Если нет, то дайте наводку, чтобы я
> смог найти его.

https://github.com/NieDzejkob/fake-static - я найду за тебя, жертва пропаганды.

Просто баг в компиляторе, вот и всё. В C++ багов ещё больше. А уж если учесть разный уровень поддержки стандартов...

И какое отношение баги в компиляторе имеют к самой модели языка?

Баги в компиляторах есть везде. В gcc, в clang, где угодно.

Жесть какая, код максимально отдаленный от ежедневной практики

>> А пример в этом треде? Если нет, то дайте наводку, чтобы я
>> смог найти его.
> https://github.com/NieDzejkob/fake-static - я найду за тебя, жертва пропаганды.

Кстати, можно посмотреть как клоуны кукарекали "нету, покажи", а как только им показали - началось нытьё и нелепые оправдания.

> Потому что растоманы лицемеры. Но не удалил, так
> что его можно найти и раскрыть.

А может, потому что ты - очередной опеннетный невежда?
Теоремы Райса, Геделя (или если для совсем уж школьников и первокурсников: "проблема остановки")?
Не, не слышали ...

Расобот - это бывший Си плюс-плюсник перешедший на Раст. Раньше они тут, в двоём или втроём, целые разговорные спектакли устраивали. В конце каждого спецтакля человек интересовавшийся Растом клятвенно обещал перейти на Раст.

Брат жив?

IMHO, лучше всего начинать читать Книгу (The Book https://doc.rust-lang.org/book/) там 20 глав, они покрывают 100% всего что есть в раст и дают понять где смотреть то, чего в книге нет.

Только начинать надо сразу с главы 4 :)

Что ты написал? Hello wrold копипастом?

Молодец, возьми пирожок с полочки

С прозрением и добро пожаловать в лучший ЯП ближайших как минимум двух десятилетий.

> Раньше все отнекивался ... думал, что  очередной проходняк. Но на днях решил попробовать на вкус ...И знаете, что? Мне понравилось!

Напоминает: "Я сначала как и все был уверен что это развод!... Сам был удивлен когда... Это действительно работает!!!"

> Напоминает: "Я сначала как и все был уверен что это развод!... Сам был удивлен когда... Это действительно работает!!!"

Развод подразумевает какой-то ушерб, зачастую финансовый, но в этом случае я ничего не потерял, а наоборот, даже приобрел. Странные у вас разводы.

>Развод подразумевает какой-то ушерб, зачастую финансовый, но в этом случае я ничего не потерял, а наоборот, даже приобрел.

Неважно, сама суть пропоганды Раста та же, и это вызывает подсознательное неоверие. Ах да, потерянное время на изучение Раста не считается?

> Неважно, сама суть пропоганды Раста та же

+1

Отзыв по языку в новости о языке
ВЕЛИКАЯ ПРОПАГАНДА

>Ах да, потерянное время на изучение Раста не считается?

Для С++ программиста это время точно не потерянное, даже если он никогда больше не будет писать на расте, во первых очень полезно посмотреть как все работает в очень близком, но намного более жестко контролируемом языке, во вторых рано или поздно в C++ добавят аналоги borrow checker.

Сделай Redox на все ноутбуки

> Сделай Redox на все ноутбуки

Сделай Hurd на все ноутбуки.

Есть Minix, есть DFBSD из гибридномикроядерных которые уже работают... зачем нужен протухший 30 лет назад Hurd?

А у растоманов кроме Redox есть хоть что то?

>> на все ноутбуки
> Есть Minix, есть DFBSD из гибридномикроядерных которые уже работают...

Мощный пук! Респект!

> А у растоманов кроме Redox есть хоть что то?

Ты сейчас пишешь с оси конца 70х начала 80х? Или это был еще одинм мощный выброс метана?

Че там с Redox?

> Инкрементальная компиляция была отключена в выпуске 1.52.1 из-за выявления скрытых ошибок

Как так-то?! Раст же безопасный! Или раст не на расте растаманы пишут?

Раст не панацея. От неосиляторов с опеннета, вот, например, - не спасает.

И откуда на опеннете столько зумеров, считающих что здесь DTF какой нибудь где все друг друга хвалят и восторгаются хеллоуворлдами?

Любое обсуждение ЯП это ожесточенные споры, обвинения в некомпетности, троллинг и тонны лулзов причем жоских и это нормально

И когда комьюнити сливается сливается весь ЯП, в этом смысл холиваров

А с растоманами даже спорить не интересно, чуть что убегают и прячутся в своем манямирке где все безопасно и ничто не течет

> А с растоманами даже спорить не интересно, чуть что убегают и прячутся в своем манямирке где все безопасно и ничто не течет

Вот тут ты прав.

Там выше было интерересно. Человек спросил кто вот это будет разгребать https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

И что? его сообщение скрыл модератор, сделав вид что в растомире всё нормально и безопасно.

Спорим это сообщение он тоже спрячет :D

> Там выше было интерересно. Человек спросил кто вот это будет разгребать https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
> И что? его сообщение скрыл модератор, сделав вид что в растомире всё
> нормально и безопасно.

А вы сами тот список читали? Там дыры в левых проектах и в областях, не касающихся областей, в которых Rust даёт возможность поднять безопасность. В первом CVE-2021-3530 дыра в коде на языке _Си_ в не имеющей никакой связи с Rust библиотеке - "A flaw was discovered in GNU libiberty within demangle_path() in rust-demangle.c". Во втором и третьем      дыры в  левой библиотеке в логике разбора HTTP-заголовка Content-Length и расчёта размера chunk-ов. В четвёртом дыра в JavaScript-движке Deno в логике загрузки модулей.  И т.п.

Какое отношение эти дыры имеют к Rust? Если бы код тех проектов был на Си, можно предположить, что дыр бы там было в три раза больше, из-за переполнений буфера и кривой работы с указателями.

Т.е. вы тоже считаете что безопасность это просто слово, которое надо всем повторять, а не работа, которую надо делать? Безопасный язык, который на каждый чих вытягивают миллион пакетов, как какой-нибудь nodejs или php с известными уязвимостями, это просто смешно.

> Любое обсуждение ЯП это ожесточенные споры, обвинения в некомпетности, троллинг и тонны лулзов причем жоских и это нормально

Спор ради спора? А зачем? Можно и более полезными вещами заняться.

Тут другой вопрос. К нормальным людям. У растоманов память короткая из за наркотиков.

А вы помните когда они своего-же загнобили? Чувак там какой-то движок сайта на расте делал. Его загнобили что он не тру растоман и не по растомански пишет. Человека довели даже до того что он проект свернул послав всех.

Rust (ржавчина), как физическое явление, как процесс, токсичен и разрушителен. И такое ощущение что сообщство языка этому соответсвует.

> А вы помните когда они своего-же загнобили? Чувак там какой-то движок сайта на расте делал. Его загнобили что он не тру растоман и не по растомански пишет. Человека довели даже до того что он проект свернул послав всех.

Ну справедливости ради, такое на всех языках происходит. Если ты будешь писать в Си стиле на С++, то тебя тоже никто по головке не погладит.

Справедливо и ты прав. Это жутчайшая жуть писать в стиле C на C++

Тем не менее до истерики и закрытия проектов людей не доводят.

Писательство в Си стиле порой вынужденно если не хочешь городить абстракции для сишных либ и потом их тестить и отлаживать

А так да, сишный код в плюсах чреват всем известными проблемами... выходы за границы массива с битьем памяти и утечками памяти, ну и макросы будь они не ладны отчего баги можно искать вечность

Не спор ради спора, а по сути естественный отбор в ЯП и их фан базе... если их язык дно, а они толстенькие неженки с айфончиками тогда их чудотехнологию раздавят как катком адепты других ЯП вот с такими огроменными яелами

Есть забавная история, с месяц назад. Я уже писал о том как пробовал использовать Rust в automotive. Повторятся не буду.

Но был у меня на собеседовании человек заявлявший что знает rust. Честно я думал одного взять. Для следующего поколения техники, может он поможет и подскажет то что не заметил я.

Но после того как я узнал от него об инопланетных технологиях. А именно что если контроллеру не хватает памяти то он может попросить у другого через глобальные переменные.... мой интузиазм упал.

Я не говорю что все такие, я говорю что мне такой попался. О языке я по этому кандидату вывода не делал. Я вообще не делаю выводов. То что удобно - я использую, то что нет - не использую.

Лол конечно... но что с них взять?

Асм никто в глаза не видел и не понимают к примеру что такое стек или куча, где хранятся обьявленные ими переменные, что такое массив на самом деле без абстракций и почему например он не может быть динамическим в исполняемом файле, чехарда в головах насчет что такое глобальная переменная и локальная(аля автоматическая память) или например не знают почему нужно приводить типы к одну...

Короче образование уровня Уганды и все

Понимаешь, мне потом кошмары реально снились от таких инопланетных технологий.

Я аж заскринил это))) но ты хоть обьяснил пареньку в чем суть?

Нет, я не выдержал после того как он сказал что авторитетно может заявить что iOS это Linux и я ему могу верить потому что он специалист.

Мой мозг взорвался.

> Я аж заскринил это))) но ты хоть обьяснил пареньку в чем суть?

А как я мог объяснить по сути? Я даже не понимал за какую базу закрепится если там полностью инопланетяне скушали мозги. Где точка отсчёта? на основании чего эту всю кашу в голове можно разобрать? ААААААААААААААА

Зачем я про него вспомнил. Опять кошмары будут.

Или спроси по приколу почему цикл никогда не вызовет переполнение стека в отличии от рекурсии

Слушай, гениально. Всё, у меня на следующей неделе собеседование. Я обязательно спрошу. Классный вопрос. Спасибо.

Ну или такое, чем технически отличается глобальная переменная от статической?(спойлер... ничем... разница лишь в том что в функции известен ее адрес в исполняемом коде, а за ее пределами ее адрес не известен)

Такой у меня уже есть вопрос.

Значит разрабы правильно юзают возрат из функции по ссылке на статическую переменную ибо безопасно

И юзают в другом потоке?

Если статическая внутри функции или блока кода то даже в c++ 98 отличаются так как инициалируется только если был вход в функцию, а начиная с c++ 11 еще обязаны потокобезопасно инициализироваться https://en.cppreference.com/w/cpp/language/storage_duration#...

Теперь поцелуйтесь.

> Теперь поцелуйтесь.

Это ты к сладкой парочке Fracta1L и iPony обращайся, они по этому делу.

int main()
{
  for(int i = 1; ; ++i) {
    volatile int _[i];
    *_ = i;
  }
}

> int _[i]

это на каком языке? не на си++ точно, на си++ так массивы можно только с константами объявлять

>> int _[i]
> это на каком языке?

C99

> не на си++ точно, на си++ так массивы
> можно только с константами объявлять

Пффф. Ломать не строить! man alloca.

А ничего что alloca в куче выделяет память, а не в стеке?

> А ничего что alloca в куче выделяет память, а не в стеке?

ОПИСАНИЕ
       Функция  alloca()  выделяет  size  байтов  памяти  в  стековом  кадре вызывающего. Это временное
       хранилище данных автоматически освобождается после возврата из функции, вызвавшей alloca().

https://www.opennet.me/man.shtml?topic=alloca&category=3&rus...

alloca не выделит памяти больше, чем возможно

> alloca не выделит памяти больше, чем возможно

Заблуждаетесь. Например, RPM5 в Rosa Tresh падал как раз из-за alloca() при установке пакетов с количеством фалов больше определённого.

>

 
> int main() 
> { 
>   for(int i = 1; ; ++i) { 
>     volatile int _[i]; 
>     *_ = i; 
>   } 
> } 
> 

А сказать чего хотел? Или мы тут играем в телепатов как компилятор rust который на этапе компиляции предугадывает сколько я данных из файла в массив загружу? По крайней мере так любят утверждать некоторые фанаты.

>[оверквотинг удален]
>> {
>>   for(int i = 1; ; ++i) {
>>     volatile int _[i];
>>     *_ = i;
>>   }
>> }
>>
> А сказать чего хотел? Или мы тут играем в телепатов как компилятор
> rust который на этапе компиляции предугадывает сколько я данных из файла
> в массив загружу? По крайней мере так любят утверждать некоторые фанаты.

Скопирую контекст из сообщений, на которые я отвечал:
>>  Или спроси по приколу почему цикл
>> никогда не вызовет переполнение стека в отличии от рекурсии
> Слушай, гениально. Всё, у меня на следующей неделе собеседование.
> Я обязательно спрошу. Классный вопрос. Спасибо.

>[оверквотинг удален]
>>> }
>>>
>> А сказать чего хотел? Или мы тут играем в телепатов как компилятор
>> rust который на этапе компиляции предугадывает сколько я данных из файла
>> в массив загружу? По крайней мере так любят утверждать некоторые фанаты.
> Скопирую контекст из сообщений, на которые я отвечал:
>>>  Или спроси по приколу почему цикл
>>> никогда не вызовет переполнение стека в отличии от рекурсии
>> Слушай, гениально. Всё, у меня на следующей неделе собеседование.
>> Я обязательно спрошу. Классный вопрос. Спасибо.

А, вот оно что. Спасибо что контекст вернул, тут иногда его трудно отследить.

Что-ж, замечание достойное, принимается. Но поскольку мы тут стали играть в задачки со звёздочками твой пример не сработал. Давай подумаем почему?

>[оверквотинг удален]
>>> в массив загружу? По крайней мере так любят утверждать некоторые фанаты.
>> Скопирую контекст из сообщений, на которые я отвечал:
>>>>  Или спроси по приколу почему цикл
>>>> никогда не вызовет переполнение стека в отличии от рекурсии
>>> Слушай, гениально. Всё, у меня на следующей неделе собеседование.
>>> Я обязательно спрошу. Классный вопрос. Спасибо.
> А, вот оно что. Спасибо что контекст вернул, тут иногда его трудно
> отследить.
> Что-ж, замечание достойное, принимается. Но поскольку мы тут стали играть в задачки
> со звёздочками твой пример не сработал. Давай подумаем почему?

А зачем думать? У меня переполняет. Достаточно, что бы опровергнуть "никогда не вызовет переполнение". Выполнил ли кто-то ulimit -s 500000000, задал размер стека в заголовке PE образа, или же при адресации проскочили сторожевую страницу и программа завершилась "без ошибок" -- важно не это, а что она обязательно где-то упадёт. Просто изменят тип счётчика на "правильный" и она упадёт.

Она упадёт даже без цикла и с константным размером массива, потому что где-то WCHAR_MAX всего 65535, а где-то нет.

Она вообще просто так возьмёт и упадёт, потому что... смотрите внимательно за руками, что бы я не смухлевал:

Like all other architectures, x86_64 has a kernel stack for every
active thread.  These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big.
https://www.kernel.org/doc/Documentation/x86/kernel-stacks

arch/x86/include/asm/page_32_types.h:#define THREAD_SIZE_ORDER    1
arch/x86/include/asm/page_32_types.h:#define THREAD_SIZE        (PAGE_SIZE << THREAD_SIZE_ORDER)

arch/x86/include/asm/page_64_types.h:#define THREAD_SIZE_ORDER    (2 + KASAN_STACK_ORDER)
arch/x86/include/asm/page_64_types.h:#define THREAD_SIZE  (PAGE_SIZE << THREAD_SIZE_ORDER)
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

но пока везёт и "у меня на виртуалке всё работает!"

> А зачем думать?

Действительно, зачем? Ведь божественный раст все спасёт. Удачи тебе ездить на авто писанное такими думателями.

p.s. ссылки твои и аргументы я рассмотрел. Ты в чём-то безусловно прав. Замечания все достойны.

Только вот нет, не упал твой весёлый цикл, прикинь. А как так?

Тут подумать бы. Но зачем? Ведь так?

p.p.s. раст валится ещё хуже кстати говоря и на более элементарных вещах. Подумать только надо. Но тут ведь "А зачем думать?"

Господин экзаменатор, я не у Вас на собеседовании. Если Вы согласились с тезисом, который по факту оказался ложным -- подумайте над этим сами. Да, "подумаем" -- это множественное число, а не только привычная манипуляторам фигура речи. Так что Ваша очередь, и нечего тут пальцы загибать, приплетая не относящийся к вопросу язык.

> Господин экзаменатор, я не у Вас на собеседовании. Если Вы согласились с
> тезисом, который по факту оказался ложным -- подумайте над этим сами.
> Да, "подумаем" -- это множественное число, а не только привычная манипуляторам
> фигура речи. Так что Ваша очередь, и нечего тут пальцы загибать,
> приплетая не относящийся к вопросу язык.

Цетирую: "А зачем думать?"

Автора хоть узнали? ;)

>> Господин экзаменатор, я не у Вас на собеседовании. Если Вы согласились с
>> тезисом, который по факту оказался ложным -- подумайте над этим сами.
>> Да, "подумаем" -- это множественное число, а не только привычная манипуляторам
>> фигура речи. Так что Ваша очередь, и нечего тут пальцы загибать,
>> приплетая не относящийся к вопросу язык.
> Цетирую: "А зачем думать?"
> Автора хоть узнали? ;)

Естественно, я же помню контекст -- это мой ответ на предложение "давайте подумаем". Я не знаю, зачем мне думать о причине, из-за которой заведомо ошибочный пример не упал в частном случае -- запустить, что бы оно "работало", я тоже могу. Не вижу каких-либо подробностей о сборке и запуске. Не вижу других гипотез, лишь убеждения подумать. Не спорю, надо, значит надо. Давайте уже подумаем. :)

> Господин экзаменатор, я не у Вас на собеседовании. Если Вы согласились с
> тезисом, который по факту оказался ложным -- подумайте над этим сами.
> Да, "подумаем" -- это множественное число, а не только привычная манипуляторам
> фигура речи. Так что Ваша очередь, и нечего тут пальцы загибать,
> приплетая не относящийся к вопросу язык.

Не, человек, ты в принципе молодец. Отличный пример, отличное замечание. Жалко только что немного не туда и не о том. Но вообще мне понравилось и появилось дополнительно интересное.

> Жалко только что немного не туда и не о том.

Не туда -- это исходный умняк про невозможность переполнения стека в цикле, в отличие от рекурсии. Кто не знает как переполнить стек в цикле, тот просто не умеет с ним работать, благо, это редко когда требуется -- в стандарте Си нет никакого стека. Когда есть понимание, что при рекурсивном вызове не обязательно использовать инструкцию процессора call и размещать адрес возврата на стеке, тогда цикл появляется сам собой. При этом цикл может накапливать какие-либо данные на стеке и точно так же его переполнит.

>если контроллеру не хватает памяти то он может попросить у другого через глобальные переменные....

Офигеть, прямо NUMA-кластер контроллеров!

Бред какой-то. Я думал, что пригодность языка определяет его эфыктивность и удобство при решении задач, а не игра кто кого перевоняет в интернете.

Вспомни D

Не перевоняет, а докажет ненужность... этл разные вещи

Хаааан, ты уже обоср@лся в каждой ветке под этой новостью. Заканчивай.

Добро пожаловать в реальность.

Мне больше интересно как эти неженки смогли бы исправить ошибку в месе, которая приводила к тирингу в i3, и может других рабочих столах/вмах. Пусть эти малохольные как админы поддерживающие прости господи шиндоуз и линукс в одной конторе учат Си, С++, Ржавого, Жабу, Жабоскрипт, баш, питон и лишь потом вылезают с авторитетными комментариями. Даже создатели языков Си и С++ вели себя скромнее.

>Любое обсуждение ЯП это обвинения в некомпетности, троллинг и тонны лулзов причем жоских и это нормально

Это просто общение дебилов.
К ЯП отношения не имеет.

> Любое обсуждение ЯП это ожесточенные споры, обвинения в некомпетности, троллинг и тонны лулзов причем жоских и это нормально

Смотри, я озаботился посчитать частоты ников:

$ sort tmp.txt | uniq -c | sort -n
...
      1 Совершенно другой аноним
      2 Anonnnym
      2 Ordu
      2 Rev
      2 Аноним зеленый
      2 Анонимъ
      2 Онаним
      3 adolfus
      3 ПомидорИзДолины
      6 anonymous
     11 deeaitch
     12 Кир
     13 Aukamo
     14 n00by
     20 Аноньимъ
     68 Хан
    104 Аноним

За ником Аноним прячется куча людей, он не считается. Ты на первом месте среди размахивающих шашкой, с большим отрывом от Аноньимъ, которого я бы объединил в одну группу с deeaitch, Кир, Aukamo и n00by, в группу людей умеренно размахивающих шашкой.

Это я к тому, что, действительно, в глаза бросается, что для тебя нормально превращать разговор о языках программирования в холивар. Ты эт, таблетки пить не пробовал?

Оналитег однако!

Товарищ майор вам надо в отпуск. Вы заработались.

Эх, а у меня почти получилось его внедрить в компании в automotive. Но нет, сыровато.

Тем не менее удачи проекту, а сообществу быть менее токсичным, перестать обвинять всех вокруг и научиться признавать ошибки и недочёты.

Буду следить и может через пару лет в новом поколении техники попробую ещё раз. Даже не может, а точно попробую. Думаю устранят недостатки.

Только честно, помимо карго добавьте нормальные вещи, карго не пропустят, честно.

О, классно, растоманы меня минусуют, не спят, бдят.

А вопрос почему? Ответа не будет. Но ребята, расслабтесь. Будет готово и я с удовольствием воспользуюсь. А пока гуглите на пример подгобного рассказа про ваш Rust и Automotive в двух томах. Эксперимент длинною в полтора года.

Не Automotive , а Automake руст лишь паразиты objectтированного кода созданного архитектором который переиначил пути для большей производительности

> Не Automotive , а Automake руст лишь паразиты objectтированного кода созданного архитектором
> который переиначил пути для большей производительности

Ну вот глупость же поправил. Откуда ты там нарисовал Automake?

Чтож вам хрустикам постоянно что-то мешает. Фаерфокс не смогли переписать, да ничего не смогли даже написать. Но мешают этому конечно же хейтеры, это из-за них вы ничего не можете сделать с вашим язычком.

Вангую что растоманы даже не знают как передаются аргументы в функцию и почему например нельзя вернуть массив из функции, это же так низкоуровнево))) а в расте все просто и понятно

Ты знал

Ладно расскажу и я, вообще думаю все помнят скандал со злополучным Audacity и сливом персональных данных, один разраб кричал что мол хэш-функция обратно не реверсится, на что ему знающие люди тактично указали что если число входящих значений в хэш-функцию конечно как те же IP-адреса, то не составляет труда составить таблицу хэшей всех IP адресов после чего прогнать интересующий тебя хэш по ней дабы найти соответствие и узнать IP-адрес... на что разраб сказал что вы все врети и отключился

Кстати эта лабуда с хэшами IP и тип анонимностью на каждом сайте

Хотя вру, можно, по ссылке если массив обьявлен как static внутри функции

А кстати из функции struct можно вернуть. В нем массивы можно же сделать. Это не прокатит? :)

В общем то Си разрешает функциям возращать структуры, но это просто офигительные дополнительные расходы на копирование, представь если структура большая и не помещается в регистры которых в x86 кот наплакал, поэтому компилятор может так использовать стек для возврата не сбрасывая его указатель перед выходом из функции и лишь потом сбросить его чтобы было время сохранить значения, а если и этого не хватает тогда в зависимости от компилятора могут быть различные грязные хуки но опять же двойным а то и тройным копированием...

Поэтому проще, быстрее и надежнее пробрасывать ссылку(адрес) на static память вызываемой функции в вызываемую и работать с ней как с обычной глобальной переменной

> В общем то Си разрешает функциям возращать структуры, но это просто офигительные
> дополнительные расходы на копирование

Не должно быть копирования. Достаточно зарезервировать стек перед вызовом.

Будет или нет копирование - зависит от оптимизатора и конкретного кода. Хинто: сравни x=f(x) и y=f(x)

> сравни x=f(x) и y=f(x)

Нет разницы, пока мы говорим о возврате структуры из функции, а не подменяем предмет обсуждения на сравнение f(x,y) и f(y,x). Что бы избежать копирования, достаточно передать её адрес неявным аргументом.

Ну смотри стек функция не сбросила и сохранила в нем возвращаемое значение, но его же нужно как то обработать, а перед этим сохранить

Копирование 1
Из стека в регистры
Копирование 2
Из регистров в память

После чего сбросить стек

Что значит "сбросить стек"?

Вы предполагаете, что структура при возврате из функции куда-то копируется. Значит место (приёмник) зарезервировано в памяти. Для чего указатель стека уменьшается на размер структуры (плюс выравнивание, но это не существенно). Происходит это при определении экземпляра. То есть до вызова функции.

struct foo r;
r = foo_construct();

Далее в теле функции определяется второй экземпляр структуры и как-либо инициализируется.

struct foo
foo_construct()
{
  return (struct foo) { /* ... */ };
}

Локальные переменные живут до выхода из функции. Соответственно, при выполнении return, по-Вашему, необходимо скопировать данные из локального для вызванной функции экземпляра в стек вызывающей.
Представьте, что один из членов структуры инициализирован указателем на неё. Что предпринять в данном случае? Как видим, копирование вообще решением не является.
С другой стороны, если копирование должно быть выполнено до выхода из функции -- значит адрес приёмника каким-то образом в теле функции известен. А раз он известен, то незачем создавать локальную структуру, достаточно формировать результат непосредственно в стековом кадре вызывающей функции. На практике передаётся неявным аргументом указатель (как this в C++), либо функция-конструктор встраивается.

Сбросить стек значит вернуть указатель стека в изначальное положение которое было до вызова функции(чтобы не получить переполнение стека)

... ну смотри ты говоришь что во время return локальные переменные копируются в стек вызываемой функции... только вот стек общий на всю программу(можешь себе представить стек разделяемой памятью фиксированного размера)

Отсюда ты и говоришь про некий адрес приемника... там адреса не нужны это или регистры или стек которые заранее известны

Локальной памяти не существует(она хранится в стеке), название неправильное, оно не отражает ее природу, в отличии от определения автоматической памяти

*в стек вызывающей

Короче суть такова что стек один на всех, а не укаждого свой

> Сбросить стек значит вернуть указатель стека в изначальное положение которое было до
> вызова функции(чтобы не получить переполнение стека)

"Восстановить" вместо "сбросить" было бы понятнее. Вернуть значение указателя нужно, что бы можно было дальше обращаться к своим локальным переменным. А то до переполнения дело не дойдёт.)

Единственно что, в зависимости от конвенции вызова, аргументы (если таковые были переданы через стек) могут быть оставлены на стеке (cdecl) или сняты вызывающей стороной (ctdcall). То есть при выходе из подпрограммы вершине стека не обязательно сразу же вернётся прежнее значение.

> ... ну смотри ты говоришь что во время return локальные переменные копируются
> в стек вызываемой функции...

Я говорю, что копирование вообще неправильно (почему -- подробнее можно почитать про глубокое копирование в С++). Но если бы оно было, то там ему самое место.

> только вот стек общий на всю программу(можешь
> себе представить стек разделяемой памятью фиксированного размера)

Стек общий, но у меня говорится о стековых кадрах. То есть об областях стека, где подпрограммы хранят свои локальные переменные. Дословно: достаточно формировать результат непосредственно в стековом кадре вызывающей функции.

По поводу разделяемой памяти - в моём понимании это страницы ОЗУ, которые принадлежат различным адресным пространствам (процессам). Стека в такой памяти быть не должно.

> Отсюда ты и говоришь про некий адрес приемника... там адреса не нужны
> это или регистры или стек которые заранее известны

Если возвращающая структуру функция (назовём её конструктором) вызывается из одного места, тогда строение стекового кадра вызывающей стороны действительно известно и однозначно, можно не передавать адрес для сохранения результата. Но в таком случае конструктор скорее всего окажется встроен (inline).

Если же вызывается из разных мест, или для массива структур, то придётся передавать адрес конструктору. И этот же адрес потребовался бы, если бы пришлось копировать структуры.

> Локальной памяти не существует(она хранится в стеке), название неправильное, оно не отражает
> ее природу, в отличии от определения автоматической памяти

Как раз вместо "автоматической памяти" в стандарте языка Си определено время жизни объектов (аutomatic storage duration). И опять же, у меня "локальные переменные". Кадр стека локален для каждого вхождения в подпрограмму, поскольку обращение к нему происходит относительно регистра стека.

> Короче суть такова что стек один на всех, а не укаждого свой

Вот именно. Потому, предприняв меры (передав указатель на место под результат), можно создавать структуру сразу в нужном месте и без копирования.

Ты умный чел сразу видно.. но пиши чут чут попроще тип без такого формализма читать сложно...

Указатель стека нужно возвращать/сбрасывать дабы он не вышел за границы стека, ведь проверки границ стека как и массива не предусмотрено, разве что проц выкинет исключение на стек и Ояс завершит программу в отличии от массива

Спор насчет локальных или автоматических переменных ниочем, это же логично что с вызовом подпрограммы формируется ее стековый фрейм, а фрейм вызывающей не очищается так как она не завершена

Ясно что можно передавать структуру по указателю, мы же говорили про накладные расходы при передаче по значению

Насчет конструктуров и стековых фреймов чет не понял...

С друго стороны такие хитроумные манипуляции похожи на костыль из разряда передать массив(до 8 байт) запаковать в long и вернуть по значению а потом распаковать снова в массив

> Ты умный чел сразу видно.. но пиши чут чут попроще тип без
> такого формализма читать сложно...

Короче пушим дворды и зовём функу потом попаем. Это называется сидекл. В стдкол функа сама попает ретн. А в фастколе параметры в регистрах. :)

> Указатель стека нужно возвращать/сбрасывать дабы он не вышел за границы стека, ведь
> проверки границ стека как и массива не предусмотрено, разве что проц
> выкинет исключение на стек и Ояс завершит программу в отличии от
> массива

Верно. Но это не главное. Допустим, перед вызовом подпрограммы по адресу [rsp - 8] что-то сохранили. Подпрограмма изменила указатель стека, отработала, произошёл возврат. В rsp другое значение, и по [rsp - 8] прочитали мусор. Так до переполнения дело не дойдёт.

> Спор насчет локальных или автоматических переменных ниочем, это же логично что с
> вызовом подпрограммы формируется ее стековый фрейм, а фрейм вызывающей не очищается
> так как она не завершена

Так я и не спорю.

> Ясно что можно передавать структуру по указателю, мы же говорили про накладные
> расходы при передаче по значению

Я говорю только по поводу возврата структур https://www.opennet.me/openforum/vsluhforumID3/124921.html#249
то есть отвечал вот на это:
> В общем то Си разрешает функциям возращать структуры, но это просто офигительные
> дополнительные расходы на копирование

С передачей всё верно. Если вызываемая функция меняет переданный аргумент и эти изменения не нужны вызывающей стороне, приходится создавать копию. Это дополнительные расходы, но без них запортится оригинал. Иначе передаём по указателю (константной ссылке в С++).

При возврате нет смысла создавать копию.

> Насчет конструктуров и стековых фреймов чет не понял...

Конструктором я назвал функцию, которая возвращает структуру, что бы меньше писать.

Про фреймы просто надо подумать, как в ассемблере будет выглядеть сишный псевдокод из исходного объяснения https://www.opennet.me/openforum/vsluhforumID3/124921.html#348

Вот как оно описано в "System V Application Binary Interface AMD64 Architecture Processor Supplement"

The returning of values is done according to the following algorithm:

2. If the type has class MEMORY, then the caller provides space for the return
value and passes the address of this storage in %rdi as if it were the first
argument to the function. In effect, this address becomes a “hidden” first ar-
gument. This storage must not overlap any data visible to the callee through
other names than this argument.
On return %rax will contain the address that has been passed in by the
caller in %rdi.

Локальные(автоматические) переменные могут и после выхода из функции, до тех пор пока не сбросится стек, это как раз случай возврата большой структуры для которой не хватает регистров

> Локальные(автоматические) переменные могут и после выхода из функции, до тех пор пока
> не сбросится стек, это как раз случай возврата большой структуры для
> которой не хватает регистров

Не стоит на это полагаться! Прерывание разрушит содержимое стека. System V x86-64 ABI гарантирует всего 128 байт Красной Зоны.

Это уже особенности ОС как я понимаю....

Особенность ОС это наличие красной зоны, или переключение адресного пространства/стека в обработчике прерывания, или гарантированное отсутствие прерываний. В общем же случае данные за вершиной стека сразу невалидны. И ловить это дело не слишком просто, особенно, если о таком не знать, а под отладчиком оно не проявится. :)

Скинь ссылку где это описано, я чет с этим не сталкивался

> Скинь ссылку где это описано, я чет с этим не сталкивался

Параграф 3.2.2 The Stack Frame

System V Application Binary Interface
AMD64 Architecture Processor Supplement
Draft Version 0.99.7

https://www.uclibc.org/docs/psABI-x86_64.pdf

Вот новее версия в исходниках https://gitlab.com/x86-psABIs/x86-64-ABI

Вот pdf версии 1.0 https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-1.0...

Прокатит, только это тормозной вариант

Кстати из за таких накладных расходов в Си нельзя массивы передавать по значению, а вовсе не потому что этому что то мешает...

А вот почему структурам разрешили передаваться по значению это вопрос, говорят так тип предполагалось что структуры были бы этакими пакетами сгруппированных значений небольшого размера, а потом пошло поехало массивы в структурах, структуры в структруктурах и тд

Кстати на обьектах в C++ весь это ад с передачей по значению закончился

Чтобы просто было понятно

Между передачей функции ссылки на структуру и возвратом ссылки на static структуру нет никакой разницы обе структуры будут глобальными

То есть невозможность передать и вернуть массив по значению это чисто ограничение языка Си, просто его создатели так решили массивы только по ссылкам, а структуры ладно и так сойдет

Ой, блин, умники.
Во первых вернуть массив из функции возможно во многих ЯП.
Даже в С++, если использовать std::array .

А теперь давай, просвети нас, неразумных. Почему это в С нельзя вернуть массив сам по себе, но если завернуть его в структурку, то можно ?

std::array это стадартная либа, речь же шла про возможности синтанксиса

перечитай свое первое сообщение в этой ветке.
Где там говорилось что речь строго про синтаксис? Где там вообще говорилось про какой-либо ЯП.

Вот так вывалил поток сознания, и потом рассказывает что ему отвечают не то.

Хера память как у рыбки... выше на коммент глянь, кто про C++ и std::array начал

Хера у тебя соображалка как у морской свинки.
Я же отвечал на твое сообщение, что где-то нельзя вернуть массив из функции.
Я же и привел как пример с std::array. Только вот не я начал, я уже писал в ответ на твое непонятное утверждение.

Что, уже на 2 уровня выше не в состоянии подняться по сообщениям?
Блин, и это недорозумение рассказывает какие растоманы тупые !!!

Лол што? Что ты привел? std::array который выступает оберткой над обычным массивом? Действительно при чем тут втроенные возможности языка и синтаксис? Гений раста что тут еще скажешь

Уже ответил читай выше

> Почему это в С нельзя вернуть
> массив сам по себе, но если завернуть его в структурку, то
> можно ?

"Еще более удивительно (по крайней мере на первый взгляд) то, что а[i] можно записать как *(а+i)" (c) K&R

> "Еще более удивительно (по крайней мере на первый взгляд) то, что а[i]
> можно записать как *(а+i)" (c) K&R

i[a] же.

                                                                                         
int a = 123;                                                                        
int *b = &a;                                                                         
0[\b] = 456;   // форумный движок считает b в [] тегом
char* anon[2] = 
    {"аноним","аноним"};                                                    
1[anon] = "рулит";                                                                    
   

Не спойлери, что обращение к массиву тип mas[2] это просто синтаксический сахар над указателем *(mas+2)

В си нельзя вернуть массив из функции тупо потому что он его не может толком отличить от указателя, в раст массив без проблем возвращается

fn tst() -> [i32; 3] {
    [1, 2, 3]
}    
fn main(){
    println!("{:?}", tst());
}  

По значению нельзя, но это особенность реализации массива в Си, в той же структуре тот же Си обходится без указателей а просто пакует побайтово

Чтобы такие растоманы не гоняли память туда сюда без толку

> По значению нельзя, но это особенность реализации массива в Си,

Я тебе про это и пишу.

> Чтобы такие растоманы не гоняли память туда сюда без толку

А вот это точно не имеет отношения к вопросу, в си просто компромиссно выбрали удобство представления массива как указателя и пожертвовали возвратом из функций и передачей как параметров, никто ни делал это ограничение для того что не разрешать гонять массивы по стеку.

Хм посмотри на массив в структуре который запакован и передается по значению, такая реализация массива через указатель была выбрана во имя производительности ибо массив это самый гоняемый тудасюда тип данных в IPC, TCP/IP, i/o например

> Чтобы такие растоманы не гоняли память туда сюда без толку

Оно не гоняет память туда-сюда без толку.

Глянь:

mod tmp {
    pub fn make_array() -> [i64; 128] {
    [-1; 128]
    }
}
fn main() {
    println!("{:?}", tmp::make_array());
}

(make_array засунута в сабмодуль, чтоб rustc её не инлайнил)

Другие твои комменты подсказывают мне, что ты хочешь доказать, что это крайне неэффективно, ибо копировать памяти много надо, и если так, то ты глобально ошибаешься. Забудь всё, что тебе рассказывал препод информатики в школе в 90-х. Это всё ложь. Уже лет 15-20 как это стало ложью.

Если это скомпилировать код выше с --emit=asm, то можно видеть такую штуку:

;; это main, прошу обратить внимание, mangled нехило, но тем не менее main
_ZN3tmp4main17hef74ed440589210dE:
    .cfi_startproc
    subq    $1112, %rsp     ; выделяется память на стеке под возвращаемое значение
    .cfi_def_cfa_offset 1120
    leaq    88(%rsp), %rdi  ; указатель на неё пошёл в %rdi, неявный аргумент для tmp::make_array
    callq    _ZN3tmp3tmp10make_array17h69c0c6c82460a46fE ; вызов make_array
        ...

Если ты заставишь C возвращать из функции объект килобайтового размера по значению, он сделает тебе примерно то же самое: память под возвращаемое значение будет выделять на стеке вызывающий код.

Проще говоря выражение типа int mas[]={1,2,3,4} не создает никакой массив, просто создает указатель mas и выделяет 16 байт памяти и записывает ее адрес в указатель

Походу тему атаковала нейросеть на самоподдуве. Забавно.

Бросай наркотики и иди читать книжки.

Это юзеры, к сожалению.

> Это юзеры, к сожалению.

С трудом верится. Боты ведь на сетях стали последнее время очень правдоподобными, в том смысле что выглядят как идиоты несущие бред.
Но отличить ботов от идиотов и сумасшедших уже очень трудно, если вообще возможно.

Вышки 5G, чипирование... теперь это... завязывал бы ты уже с рентв

> #[path = concat(env!("OUT_DIR"), "/generated.rs")]

Прикольно, теперь хрустикам можно будет нетривиальные бекдоры без палева хреначить. Первое со вторым дружит надеюсь?

#include "generated.h"

В раст есть прямой аналог #include из препроцессора C/C++ это макрос include!, с ним тоже будет что-то типа include!("generated.rs"), а конструкция свыше это полноценная загрузка модуля. Ну и напугавшие, как я понял тут всех, макросы concat и env позволяют задать путь в compile time что хоть и коряво, но весьма удобно в C/C++ все это придется выносить в систему сборки. Хотя когда в C++ модули доведут до ума нечто подобное тоже наверняка появится.

пипец синтаксис...

В каждой минорной версии что-то добавляют и добавляют.. Он когда-то будет полным? По сложности уже, наверное, соперничает с плюсами, если еще не обогнал.

Нет конечно все менеджеры уверенны что пользователям нужны только новые фичи. И они правы фанатикам нужны именно они. Но нормальным людям работу надо работать, менеджерам это невдомек.

Ну не пользуйтесь новыми фичами, работайте свою работу, кто мешает?

Отсутствие обратной совместимости? У хрустиков у них же стабилизация функции это целая фича.

У них эпохи придумали для того чтобы даже новые несовместимые компиляторы могли собирать старый код. Вообще адская несовместимость была только до выхода стабильной 1.0 версии.

Забавно видеть как этот недоязык превращается в C++. Забивает в собственный гроб гвозди. Ржавые.

На самом деле это С++ ввел у себя некоторые хайповые фичи. Но это не комплимент срастикам.

Стоп-стоп, как это - Раст падает до уровня C++?

Привет еще растоненавистникам:) Я с растом уже как 3-4 года)...

Прям камингаут...

Не тратьте время на раст, лет через 10 стабилизируют, за это время на С++ еще библиотек напишут на миллиарды долларов, а вызвать С++ код из раста - это приключение, в котором вы не хотите приключаться

Через 10 лет уже перепишут всё, что можно на раст )))
Шутка конечно, но тенденция есть.

Мозила показала, что это невозможно, и выгнала растаманов.

Это ты прочитал в комментах на опеннете?)

Хаха...nope
https://wiki.mozilla.org/Oxidation

Хотя то, что после отделения Раста процесс притормозился (али как обычно заброслии вики обновлять) - факт. Тем не менее WebRender - растовый и он работает.

Кого стабилизируют-то? Раст вот уже, а C++ уже никогда

Начал седня изучать раст, первая же проблема - излишне длинный код. Почитал про макросы. Думаю ну ок, можно как-то извернуться, но хотелось бы постфиксные макросы. Почитал про то что постфиксные макросы нужно заключать в блок. Закрыл страницу

А конкретнее, где длинный? Может, это ты что-то не так делаешь?

Да здраствует великая Rust!!! Да здраствует язык будущего!!!
Скоро Linux весь на rust перепишут))))

Все 24 млн строк сишного/ассемблерного кода?

> Скоро Linux весь на rust перепишут

Они свой редох написать не могут...

Кто - они? Несколько энтузиастов, которые пишут чисто изучения / прикола ради?

>> Скоро Linux весь на rust перепишут
> Они свой редох написать не могут...

Ты уже довел Hurd до ума?

Что ты мелишь? Hurd еще в 90-е рипнули в угоду GNU/Linux даже Столлман об этом говорил в фильме про Linux...

А так да уже давно есть работоспособный Minix...Intel не даст соврать... смешно конечно же наблюдать как дедушка Таненбаум со студентами и аспирантами смогли в микроядро, а толпы растоманов только мечтают о Redox...

Код то хоть не из Minix воруете? А?

> Что ты мелишь? Hurd еще в 90-е рипнули в угоду GNU/Linux даже
> А так да уже давно есть
> отмазки и лютый бред поскипаны.

Ясно. Не осилил. Так и скажи - твои отмазки никому не интересны.

Лол))) вспомни еще мультикс 60-х годов... ее Кен Томпсон и Денис Ритчи неосилили

Но про Minix ты тактично умолчал))) эх растоманы чуть что в кусты и классическое вы все врети

> Но про Minix ты тактично умолчал)))

Зачем мне комментировать твой бред? Тебя спрослили за Hurd, а ты начал блеять за что-то там (при этом и рядом не стояв).
> эх растоманы чуть что в кусты и классическое вы все врети

Какой занимательный (нет) диалог шизофреника с лишь ему слышными голосами ...

Ну че там скоро Redox достигнет уровня Minix?

Вообщем криворучки за которых раст все сделает сам, вашу недоось ждет судьба все того же Hurd который так и не вышел

Ты что куришь? Кому вообще не плевать на Redox?

Растоманам же

>Rust 1.54, основанного проектом Mozilla

Автор новости ошибся. Основал Раст некто Грейдон Хоар. Грейдона Хоара некоторая группа растаманов вытеснила - к его мнению не прислушивались, и он справедливо обидевшись ушёл.

>при этом обходясь без использования ... runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки).

Рантайм в Расте есть. Есть только один язык программирования в, котором нет рантайма, это чистый Си!

Надеюсь, сейчас не выскочит растаман и скажет что при таких-то и таких-то опциях компилятора рантайма не будет. Не надо, нам это не интересно.

Вот эти штуки без рантайма. https://rust-lang-nursery.github.io/rust-cookbook/concurrenc...

Ошибся, там вроде токио используется.

> Рантайм в Расте есть. Есть только один язык программирования в, котором нет рантайма, это чистый Си!  
> ... и скажет что при таких-то и таких-то опциях компилятора рантайма не будет

О, очередных опеннетных бала^W теоретиков подвезли. Расскажи нам о том, как freestanding в gcc не требует memcpy, memset, memmove и опций компилятора, не стесняйся!

Что такое "рантайм" в твоем понимании?
В моем - что-то будет вызываться просто потому что (gc и прочее недоразумение)
В Расте же вызывается только то, что вызвал программист

у Вас большие познания (нет)

сорян, но если у вас пушинки libc или rust std - рантайм и огромные so-дополнения, то что тогда не рантайм
условно тру рантайм - это монстры уровня джавы, ноды
в сравнении с ними rust std или libc просто незаметные песчинки на фоне огромной пустыни

Много вы на чистом Си напишете без стандартной библиотеки? (Нет, ну можно, если вы пишете ядро ОС, но там и ассемблер понадобится.)

Чем тот же glibc не "рантайм"?

>Чем тот же glibc не "рантайм"?

Тем, что в чистом Си glibc не часть языка.

Ну так и у раста есть аналог "чистого си" no_std https://docs.rust-embedded.org/book/intro/no-std.html

>Надеюсь, сейчас не выскочит растаман и скажет что при таких-то и таких-то опциях компилятора рантайма не будет. Не надо, нам это не интересно.

смотри выше.

Понятно цитируемый аноним просто тупо врет что только си язык без рантайма.

>>Надеюсь, сейчас не выскочит растаман и скажет что при таких-то и таких-то опциях компилятора рантайма не будет. Не надо, нам это не интересно.
> смотри выше.

На что именно? На детский сад "Тама нету! А если кто-то даже и покажет что есть, то это НЕ СЧИТАИЦА!"?

Стандартная библиотека - часть Си и входит в стандарт. https://ru.wikipedia.org/wiki/Стандартная_библиотека_языка_Си

Деннис Ритчи с тобой не согласен.

> Надеюсь, сейчас не выскочит растаман и скажет что при таких-то и таких-то опциях компилятора рантайма не будет. Не надо, нам это не интересно.

В C ты тоже не сможешь собрать бинарь без libc.so не передавая дополнительных опций компилятору. Если твоя программа начинается с main, то значит в ней уже есть рантайм -- к ней линкуется crt0.o, crti.o, crtn.o плюс-минус ещё какие-то объектные файлы. Попробуй как-нибудь в образовательных целях слинковать C'шную программу вызовом ld. Вот не gcc запускай линкером, а ld. Много чего нового узнаешь, если слинкуешь.

Что делать если ты пряморукий, но язык тебе мешает? https://en.wikipedia.org/wiki/C_standard_library#Concepts,_problems_and_workarounds

Есть эффективный способ выучить баги Си/С++ чтобы их эффективно обходить и не отстрелить конечности?

>Си/С++

Никогда так не пиши. Это два совершенно разных языка.

Почему же?
Да, это условно разные языки, но один - подмножество другого и основные проблемы у них общие, поэтому в некоторых контекстах это очевидно верное написание

Абревиатура "C/C++" выдумана Майкрософтом в её ВижуалСтудии. Отцы-юниксоиды из Белл Лабса никогда так не писали.

Абревиатура "C/C++" - маздаевский высер.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2644.pdf

иди, жалуйся в комитет C(WG14), что они не знают как писать C/C++.

Отцы основатели теперь пишут С/С++.

Ни бзди.

C++ включает в себя в полном обьеме Си

Не совсем.
Например, в C я могу присвоить указатель на void* типизированному указателю, а в C++ (без явного кастинга) - нет.
Или, скажем, вложенные структуры по разному работают.
Короче, дофига мелких отличий на самом деле.

C++ поддерживает Си на достаточном уровнем чтобы юзать Си библиотеки как родные без изменений кода, а это говорит о многом

я из Паскаля могу юзать Си библиотеки как родные, и что?!

Для маленьких растоманов... на уровне исходного кода юзать, то есть буквально смешивать Си и C++ и все будет ок

> на уровне исходного кода юзать, то есть буквально смешивать Си и C++

Не учи детей плохому, они ведь поверят, а потом огребут на линковке :) когда случится "симбол нот фаунд". Ты, надеюсь, в курсе, что манглинг у них разный? И почему в сырцах идёт явное указание, что мы собираемся компилировать - си или плюсы.

>> на уровне исходного кода юзать, то есть буквально смешивать Си и C++
> Не учи детей плохому, они ведь поверят, а потом огребут на линковке
> :) когда случится "симбол нот фаунд". Ты, надеюсь, в курсе, что
> манглинг у них разный? И почему в сырцах идёт явное указание,
> что мы собираемся компилировать - си или плюсы.

#ifdef __cplusplus
extern "C" {
#endif /*__cplusplus*/

...

#ifdef __cplusplus
}
#endif /*__cplusplus*/

Если чет не так, на уровне синтаксиса отгребают на стадии компиляции, линковка то дела уже ABI

Любую функцию Си можно встроить в качестве метода в обьект C++ просто спопипастив... где еще так возможно?

> спопипастив

Попой пишешь? Оно и заметно.

Велосипедоизобретатель?

В с++ такое невозможно, вот эта вполне легальная Си строка

int *arr = malloc(3 * sizeof(int));

не соберется.

С каких пор malloc не void? Где приведение типа? Это костыль а не Си-код

> С каких пор malloc не void? Где приведение типа? Это костыль а
> не Си-код

Это валидный си код который компилируется с  -Wall -Wextra -pedantic без писка, так что тезис о копипасте несостоятелен. Но соглашусь с тем что из C++ си код очень легко использовать, но это также не отменяет того, что языки уже разошлись и вряд-ли в ближайшем будущем сойдутся до полной совместимости.

Нет. Читайте спеки.

https://www.acm.org/media-center/2021/july/dissertation-awar...

In his dissertation, Jung tackles this challenge by developing semantic foundations for Rust that account directly for the interplay between safe and unsafe code. Building upon these foundations, Jung provides a proof of safety for a significant subset of Rust. Moreover, the proof is formalized within the automated proof assistant Coq and therefore its correctness is guaranteed. In addition, Jung provides a platform for formally verifying powerful type-based optimizations, even in the presence of unsafe code.

Осталось подождать срыва покровов от местных экспертом с девятью классами образования.

Что сказать-то хотел? Ещё не научился выражать мысли?

По твоему комменту видно, что ты не научился работать мозгом.

И только старый попугай вдруг громко крикнул из ветвей (с): "...не научился работать мозгом!".

Собрал на FreeBSD из порта lang/rust. Пакет rust-1.54.0_1 при сборке выжрал 14 ГБ ОЗУ (82%) и 1.4 ГБ SWAP. Я опешил от такого.