Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
Сообщение от opennews (?), 30-Июн-22, 09:04
В списке рассылки разработчиков набора компиляторов GCC опубликован отчёт о состоянии проекта Rust-GCC, развивающего GCC-фронтэнд gccrs с реализацией компилятора языка Rust на базе GCC. До ноября этого года планируется  довести gccrs до возможности сборки кода, собираемого компилятром Rust 1.40, и добиться успешной компиляции и использования штатных Rust-библиотек libcore, liballoc и libstd. В следующие после этого 6 месяцев планируется реализовать проверку заимствования переменных (borrow checker) и поддержку пакета proc_macro... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57428
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+14 +/–
Сообщение от АнонимкаРастуимка (?), 30-Июн-22, 09:04
одобряю, куда денег?
Ответить | Правка | Наверх | Cообщить модератору

	110. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+10 +/–
	Сообщение от Аноним (110), 30-Июн-22, 13:05
	Давай почту, скину номер карты.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Без аргументов (?), 30-Июн-22, 13:50
	Мне
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	125. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Без аргументов (?), 30-Июн-22, 13:53
	Собираю на цистерну WD40
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	163. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Bdfybec (?), 30-Июн-22, 19:48
	Что, можно пить?
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (110), 30-Июн-22, 19:56
	Если запор, то можно.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (-), 30-Июн-22, 20:17
	А также в край надоело работающее зрение, легкие и прочее "ненужно". По крайней мере так на банках написано.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–1 +/–
	Сообщение от Аноним (205), 01-Июл-22, 04:39
	Это все при виде раста?
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от thhh (?), 01-Июл-22, 07:12
	И при упоминании тоже.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 30-Июн-22, 20:45
	> одобряю, куда денег? Bitcoins accepted here! :))
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. Скрыто модератором	+1 +/–
Сообщение от васёк (?), 30-Июн-22, 09:07
нужен rust, собираемый компилятором zig с ide на JavaScript, вот тогда будет как надо
Ответить | Правка | Наверх | Cообщить модератору

	17. Скрыто модератором	+23 +/–
	Сообщение от Жироватт (ok), 30-Июн-22, 09:52
	Ты извращенец. Собирать растовый нужно так: 1. Проверяльщик боровов преобразует rust -> typescript 2. Проприентарная (это важно!) приблуда от майкрофсофт раскрывает typesript в pure js 3. Код на js преобразуется в представление на lasarus pascal 4. Паскальный код компилируется в байткод java-машины, выполняющейся в WebASM 5. Байткод раскрывается в перловый скрипт в синтаксисе латыни (https://users.monash.edu/~damian/papers/HTML/Perligata.html) 6. Перловая латынь приводится к виду YoptaScript (https://yopta.space/) 7. YoptaScript преобразуется в YoptaC# 8. YoptaC# выполняется на дотнете так, чтобы его выводом была программа на С 9. Далее уже стандартным gcc все собирается. Нужно по максимуму задействовать стек технологий, резюме само себя не напишет
	Ответить | Правка | Наверх | Cообщить модератору

	25. Скрыто модератором	–1 +/–
	Сообщение от Alladin (?), 30-Июн-22, 10:04
	Это конечно наверное очень смешно, но вы дальше 0 пункта не пройдете.. тоесть системный язык и ts/js?? смешно сопоставлять..
	Ответить | Правка | Наверх | Cообщить модератору

	92. Скрыто модератором	–1 +/–
	Сообщение от Аноним (92), 30-Июн-22, 12:05
	Не называйте rust системным. Ему ещё далеко до этого. И походу он только отдаляется. Без оптимизации он создаёт код в сотню раз больше нужного, причем не факт, что способного выполниться без переполнения стека.
	Ответить | Правка | Наверх | Cообщить модератору

	136. Скрыто модератором	+4 +/–
	Сообщение от Alladin (?), 30-Июн-22, 14:44
	Это еще почему я его не могу называть системным языком?:) Недавно на нем запилил код для esp32, даже esp8266.. не так давно собираюсь запилить драйвер для uefi на расте.. Где в этом месте он не системный? Нет оптимизаций? Вы смешной, по вашим рассказам llvm наверное тупо транслятор в машинный код без оптимизаций... "он создаёт код в сотню раз больше нужного" А пруфы можно? Пока на данный момент раст проги весят больше аналогичных сишных лишь по причине того что внутренняя библиотека раста (std) линкуется статически, в то время когда на C/C++ все эти ваши си std линкует динамически (и то все это решаемо). "причем не факт, что способного выполниться без переполнения стека" Шо? Коня украли?
	Ответить | Правка | Наверх | Cообщить модератору

	164. Скрыто модератором	+/–
	Сообщение от Bdfybec (?), 30-Июн-22, 19:54
	> запилил код для esp32, даже esp8266.. Так пишут и на питоне и никто не называет питон системным. > не так давно собираюсь запилить драйвер для uefi на расте не так давно собираюсь - это собираешься несколько минут? И как твои собиралки соотносятся с системностью раста?
	Ответить | Правка | Наверх | Cообщить модератору

	168. Скрыто модератором	+/–
	Сообщение от Аноним (-), 30-Июн-22, 20:30
	> нем запилил код для esp32, даже esp8266.. Кажется для тебя есть сюрприз, см. ниже. > не так давно собираюсь запилить драйвер для uefi на расте.. Где в этом месте он не системный? А он так умеет? Пример? Особенно если сабжем? > "причем не факт, что способного выполниться без переполнения стека" Внезапно, хруст уповает на MMU по поводу стека. А если его нет (в ESP32 он разве есть?) - тогда и от переполнения стека в хрусте никакой защиты "само по себе" не будет. Внезапно, да? Более честные хрустики пробовавшие на мк хотя-бы это честно пишут, в отличие от таких как ты.
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	199. Скрыто модератором	+/–
	Сообщение от Alladin (?), 30-Июн-22, 23:38
	"А он так умеет? Пример?" В сети примеры, например нейкие неадекваты написали к uefi эмулятор GameBoy (не драйвер конечно, но ПО). "тогда и от переполнения стека в хрусте никакой защиты" да, в расте нет переполнения стека в safe.. бо его в safe не сделаешь никак. а в unsafe(если ктото умудрится запилить такое) тотже miri это заметит и сообщит что вы неадекваты.
	Ответить | Правка | Наверх | Cообщить модератору

	210. Скрыто модератором	+/–
	Сообщение от n00by (ok), 01-Июл-22, 07:40
	> "тогда и от переполнения стека в хрусте никакой защиты" > да, в расте нет переполнения стека в safe.. бо его в safe > не сделаешь никак. Каким образом это обеспечивается? Запрещается рекурсия?
	Ответить | Правка | Наверх | Cообщить модератору

	26. Скрыто модератором	+3 +/–
	Сообщение от АнонимкаРастуимка (?), 30-Июн-22, 10:06
	вы приняты!
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	145. Скрыто модератором	+2 +/–
	Сообщение от Тычок (?), 30-Июн-22, 15:42
	Походу ты уже сам принял!
	Ответить | Правка | Наверх | Cообщить модератору

	45. Скрыто модератором	+1 +/–
	Сообщение от Без аргументов (?), 30-Июн-22, 10:44
	Без npm и nodejs не обойтись.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	50. Скрыто модератором	+/–
	Сообщение от Alladin (?), 30-Июн-22, 10:53
	Даже если вы возьмете nodejs.. язык который не требует сборщик мусора и прибить к нему гвоздями сборщик мусора.. оверхед будет великолепный..
	Ответить | Правка | Наверх | Cообщить модератору

	130. Скрыто модератором	+/–
	Сообщение от Аноним (130), 30-Июн-22, 14:28
	10-19. Использование различных систем сборки: от Make до CMake. 20-29. Упаковывание всего в разные матрёшки: от rpm до FlatPack. 30-31. Ну и конечно контейнеры и виртуализация: от Docker до OpenVZ.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	89. Скрыто модератором	+1 +/–
	Сообщение от Аноним (89), 30-Июн-22, 12:02
	>нужен rust, собираемый компилятором zig с ide на JavaScript, вот тогда будет как надо А сам Zig должен быть написан на Hare.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

4. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+10 +/–
Сообщение от Аноним (4), 30-Июн-22, 09:07
Откуда такая толпа растаманов? И откуда у них деньги на зарплаты? Я реально не понимаю. Коммерческий софт на С++, системный на Си, веб на интерпретируемых языках. У раста даже ниши (в бизнес-смысле) нет.
Ответить | Правка | Наверх | Cообщить модератору

	5. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (5), 30-Июн-22, 09:17
	Блокчейн
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (7), 30-Июн-22, 09:26
	в вебе горячие части переписывают довольно часто еще
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	8. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–1 +/–
	Сообщение от Аноним (8), 30-Июн-22, 09:39
	Ну вот так вот с ходу: https://github.com/ijl/orjson https://github.com/aviramha/ormsgpack Это для ускорения сериализации/десериализации. В приниципе, довольно неплохие результаты показывает. Если говорить про фронтовый web, то там тоже есть свои либы (в основном для SSR из того что видел). Я не фанат раста и не считаю, что он ведёт к успешному успеху, но у них хорошая интеграция с другими ЯП, что возможно нехило добавляет популярности. В своё время это помогло Python'у взлететь.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	22. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Бывалый смузихлёб (?), 30-Июн-22, 10:01
	Доо. Ведь всем давно известно, что осн время ожидания в вебе приходится исключительно на серилизацию-десереализацию Питону помогло не это, а то, что ему начали учить в энных школах/колледжах как первому ЯП
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+3 +/–
	Сообщение от Alladin (?), 30-Июн-22, 10:07
	Смешно, особенно про первый язык программирования в школах и колледжах.. Кажись первым языком всегда был Pascal да Delphi...
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (43), 30-Июн-22, 10:35
	>Смешно Да, я тоже часто задумываюсь о причине суперпопулярности такого убожества, как Python... Возможно, всё-таки главным фактором являетсо то, что синтаксис с отступами выглядит менее пугающе для непрограммиста. Непрограммистам тоже надо программировать.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–1 +/–
	Сообщение от Аноним (110), 30-Июн-22, 13:02
	Синтаксис с бегино-ендами выглядит более пугающим для ленивых программистов. А программисты, в большинстве своём, ленивы ;)
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (109), 30-Июн-22, 13:04
	у питона самое крутой сообщество, из-за этого большое количество готовых библиотек под все случаи. самое главное его достоинство, которое ему помогло выстрелить - открытость(возможность внесения PEP), возможность дергать сишные либы. ну и язык задумывался чтобы быть максимально читаемым и расширяемым. сегодня большинство из этих вещей есть во многих языках, но питон завез это все сильно раньше
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	174. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (-), 30-Июн-22, 20:47
	> у питона самое крутой сообщество Крутой, крутой, сообществ... И простите, но почему-то 95% питонокода являет собой прекрасно отформатинованный гамнокод.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от mandms (ok), 30-Июн-22, 22:06
	вы не читали и не применяете PEP8 или его аналогги, вот в чем дело
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 01-Июл-22, 19:16
	> вы не читали и не применяете PEP8 или его аналогги, вот в чем дело На качество кода, баги, скорость и жрач оперативки все ваши PEP мало влияют, хоть обложись ими. Язык для создания макетов софта и есть это самое. Все остальное на нем получается ужасно. Даже до корпов с вебней дошло, на го заменяют.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (207), 01-Июл-22, 06:37
	Как и код на других языках.
	Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

	219. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от aa (?), 01-Июл-22, 10:48
	Посмотрите программы западных университетов - везде основы программирования преподают на питоне.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	238. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 01-Июл-22, 21:34
	> Посмотрите программы западных университетов - везде основы программирования преподают > на питоне. А раньше учили прогать на BASIC. Это однако не значит что на нем же и надо было остаться, освоив азы :)
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 30-Июн-22, 20:43
	> Питону помогло не это, а то, что ему начали учить в энных > школах/колледжах как первому ЯП Однако от его производительности у корпов все же подгорает. Так появился игого, на который большие корпы и переползают, заодно впрочем и на хруст иногда: у игого GC неотключаемый, это все же так себе радость.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	255. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от anonymous (??), 04-Июл-22, 17:14
	Когда его начали учить в колледжах, всё уже свершилось. Обычно школы и колледжи даже остают довольно нехило от трендов. А вы тут утверждаете, что они эти тренды задают.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	81. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–2 +/–
	Сообщение от Аноним (81), 30-Июн-22, 11:57
	>pip install maturin ls -lh /usr/local/lib/python3.9/dist-packages/maturin/maturin -rwxr-xr-x 1 root staff 15M июн XX XX:XX /usr/local/lib/python3.9/dist-packages/maturin/maturin (это после принудительной минификации через strip -s, которую maturin сам не делает, а изначальная сборка была вообще цирком с понями, так как собирает он сам себя) >curl https://sh.rustup.rs Сразу на хрен.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	171. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 30-Июн-22, 20:44
	>>curl https://sh.rustup.rs > Сразу на хрен. БезопасТность по растамански приходит к чему-то такому...
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (9), 30-Июн-22, 09:39
	Гуглите, что такое инерция мышления.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	10. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+12 +/–
	Сообщение от Аноним (10), 30-Июн-22, 09:40
	> Коммерческий софт на С++ Адский язык, на котором нельзя писать коррректный код и не сойти с ума > системный на Си Не менее адский язык, на котором писать корректный код всем западло, особенно не писавшим на плюсах профессиональным сишникам > веб на интерпретируемых языках Зачастую без типизации, а значит нечитаемые и смертельно опасные Деньги на раст получаются от тех, кому уже надоело платить за ошибки сишников и плюсовиков
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	13. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+10 +/–
	Сообщение от Аноним (43), 30-Июн-22, 09:47
	>Деньги на раст получаются от тех, кому уже надоело платить за ошибки сишников и плюсовиков Поддерживаю Вашу точку зрения, многоуважаемый Аноним. Кроме того, видел у работодателей ещё такую мотивацию, что приходят разработчики сразу уже очень хорошего уровня, то есть сам факт, что человек освоил Rust, означает, что преодолён некий ценз некомпетентности. Сишники и плюсовики с опытом, не желающие что-то менять, уже замшелые.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+12 +/–
	Сообщение от Admino (ok), 30-Июн-22, 10:08
	> Сишники и плюсовики с опытом, не желающие что-то менять, уже замшелые. Разработчики старше тридцати не умеют развиваться, они все старые, брюзжат, у них в продакшне легаси и они могут использовать один и тот же фреймворк неделями.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Sw00p aka Jerom (?), 30-Июн-22, 11:47
	>Разработчики старше тридцати не умеют развиваться Задайтесь вопросом, что есть разработка?
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–1 +/–
	Сообщение от n00by (ok), 30-Июн-22, 11:59
	>>Разработчики старше тридцати не умеют развиваться > Задайтесь вопросом, что есть разработка? Admino - админ сайта Розалинукс, который не раз ломали. Разработка операционной системы Розалинукс ведётся на языке баш. Какие тут могут быть вопросы?
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от анон_тот самый (?), 30-Июн-22, 21:48
	весь линукс вырос из баш скриптов.он на них просуществовал около 20 лет. чем тебя язык то не устроил. неужели даже в баш не можешь. хоть чуток?))
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (-), 30-Июн-22, 21:50
	На баше кернел не очень пишется.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от анон_тот самый (?), 30-Июн-22, 22:51
	не про ядро и речь. все юникс жили работой на баш скриптах(и перле). да сам линукс только около по сути 8 лет как на системду перешел. и скажу сразу не большой её фанат, как и противник. просто нужна была более концептуально доработанная версия инита, а не тот комбаин что сейчас. хотя к теме. линух до сих пор во многом живет на баш.
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (-), 01-Июл-22, 02:21
	> не про ядро и речь. все юникс жили работой на баш скриптах(и перле). Запредельная наглость скриптера. Вообще-то основой были кирпичики "does one thing and does it well" - писаные как правило на сях. А баш - для лабания по бырому in situ glue-кода между ними. Баш в чистом виде без вон тех кирпичеков нахрен не упал. Чо им делать? Он вообще в систему нормально интерфейситься не умеет сам, впрочем, ему и не надо так то. Хотя сильно потом сделали всякое, типа /dev/tcp со временем, конечно, но это тот еще прон. > да сам линукс только около по сути 8 лет как на системду перешел. И как по мне - я не скучал об sysv init, вот уж эталонный кусок дряни. > и противник. просто нужна была более концептуально доработанная версия инита, Был upstart, но, таки, из-за полумер в вот этом аспекте + жирного факапа с зависимостями его и захотелось заменить. Потому что создал новых проблем решив старые в лучшем случае наполовину. > а не тот комбаин что сейчас. хотя к теме. линух до сих пор во многом живет на баш. Просто любой инструмент хорош в своей нише, без чрезмерного фанатизма. Даже ассемблер хорошая штука, если к месту. А напиши на нем нечто с бинарем 100 кило - и получишь неструктурированное месиво, которое почти невозможно поддерживать и нереально на другую архитектуру портировать. А по глобальной оптимизации оно сольет C/C++ с LTO на раз. Просто потому что кодер пять раз забыл что 3 килобайта тому назад вгрузил подходящие константы которые реюзнуть можно. А компилеру похрен, он железный.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от анон_тот самый (?), 01-Июл-22, 06:56
	верно скрипт это скрипт и он нужен там и в том количестве , где необходим. его действительно создали для выполнения быстрых и коротких операций и связи всей остальной системы на сях. инит был может и куском дряни( хотя сомневаюсь. он был изначально прост и понятен пока дистростроители не стали лепить свои поделки и ветвления скриптов, как тот же сьюз).да был у него косяк. невозможность отслеживания процессов после завершения их изначального родительского процесса.(такие были косяки) но это можно было реализовать . никто просто не брался за это. что до раст.... это весьма сложная тема и неблагодарная тоже. создали язык, который можно сравнить с машиной на автомате, причем кривом, который требует чуть ли не постоянного зажатия педали тормоза иначе автоматическая коробка не работает правильно, но вы не парьтесь у нас мощный движок, потому машина поедет почти так как Си. а то что это требует повышенного расхода мощностей забыли. да и синтаксис.... как бы сказать - странноватый? ну это фиг с ним у каждого свой дальтонизм им и решать. но язык далек от идеала и в местах критических он требует не меньше , а еще больше риска чем Си. а все эти так называемые безопасные режимы идут лесом. это как будто вам говорят, что их машина безопасна, но что бы хорошо справляться с задачей вам время от времени нужно нажимать педаль в пол и скидывать тормоз и рисковать. короче их язык с сильными дефектами.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 01-Июл-22, 21:28
	> верно скрипт это скрипт и он нужен там и в том количестве , где необходим. ИМХО его epic win это интерактив в консоли и возможность записать это или чуть более крупное нечто для какой-то небольшой системной автоматизации. Вот так он вполне уместен и привносит кое что полезное. > его действительно создали для выполнения быстрых и коротких > операций и связи всей остальной системы на сях. И вот в таком виде я против него ничего против не имею и сам им так пользуюсь. Но это означает что он сам не попадает в интенсивные потоки данных, продвинутый парсинг или что там еще. Он лишь общий координатор/автоматика на верхнем уровне. Без должной технологической подложки оно попросту ни о чем. > инит был может и куском дряни( хотя сомневаюсь. Я порой делаю с линем что-то типа OEM или системной интеграции и в гробу это месиво видал. Там полный задник с управлением системой, диагностикой, логингом и траблщутингом. А уж авторестарт сервисов и прочее "ненужно" все делали из спичек и желудей. Сделать на этом нормальную изоляцию сервисов от системы и друг друга? Агаща. Это месиво дохнет на середине потому что система уже недоступна. А зачем вебсерверу уметь bash вызывать вообще? Для выполнения функций вебсервера ЭТО совершенно точно не надо, только хакерам дает лишние возможности. Механизмы "system defaults" vs "adm/user override"? Ну, их нет. Как и дружбы с пакетником. А некоторые считали что припереть свой наколенный монитор живости сервиса и что там еще на 3-4 страницы в своем скрипте - "круто". Круто и удобно. Кроме случая когда это месиво вон там почему-то не запускается, и надо разобраться почему. Самолично накодив логинг операций этому куску кала. Как угодно но системд эти моменты обыграл. Хорошо ли, плохо ли, но другие и так не смогли. Апстарт был еще более грабельным, другие лечили что "это не надо", чем вызвали большой спрос от эксплуатантов чтобы уйти этих гениев к хренам с сделать уже наконец как лучше работает. > он был изначально прост и понятен Я морально не готов пользоваться большой фичастой системой как будто на дворе ранний юникс. Как еще понятнее это объяснить? > сравнить с машиной на автомате, причем кривом, который требует чуть ли > не постоянного зажатия педали тормоза иначе автоматическая коробка не работает правильно, Ну, я научился его готовить правильно и мои системные образа проблем мне и клиентам не создают. А ваши художества из спичек и желудей - не очень ценная штука, сугубо по тому как это все работало и делало окружающим мозг. Ну да, офигенные возможности при траблшутинге, только мы это научились делать иначе. Более радикально и эффективно. В цать раз быстрее. Некоторые технологии просто изменились. > скидывать тормоз и рисковать. короче их язык с сильными дефектами. Если про сабжа - у них в принципе и некоторые забавные вещи есть, тот же borrow checker и делание UB все же Defined Behavior, разумные типы данных. Но это очень узкий view, в то время как объективная оценка стабильности, предсказуемости и безопасности требует full view и врядли для сабжа он у кого-то сейчас вообще есть. Более того, он сложнее и поэтому ВСЕ аспекты учесть многократно труднее. Говоря на чистоту, сишники кому вон то не пофиг, сами велоспидят нечто что отдаленно это напоминает. Но почему это не должно быть частью тулчейна все же логичный вопрос.
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от n00by (ok), 01-Июл-22, 09:15
	>> не про ядро и речь. все юникс жили работой на баш скриптах(и перле). > Запредельная наглость скриптера. Вот это их характерное оличие от тех, кого почему-то презрительно именуют "вебмакаки". Последние чётко понимают "фронтенд", "бэкенд", "фреймворк" и иерархию. В мире баш-программистов ядро и прочие компоненты системы как бы сами собой растут на деревьях, их надо лишь собрать, а "система" - это набор разрозненных пёрлов типа systemd-initramfs-degenerator.sh, в которых они ориентируются при помощи умопомрачительных комбинаций параметров команды grep.
	Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

	239. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 01-Июл-22, 21:39
	> Вот это их характерное оличие от тех, кого почему-то презрительно именуют "вебмакаки". > Последние чётко понимают "фронтенд", "бэкенд", "фреймворк" и иерархию. Им это не всегда и не всем помогает и они иногда пытаются в не менее дурацкие комбо, типа "а давайте вообще все на JS для унификации подхода?". Начиная с чуть ли не парсинга HTTP и работы с сокетами. Потом оказывается что JS так то для больших проектов не игого, начинаются десятиэтажные извращения чтобы вбивать все гвозди именно любимым бабушкиным микроскопом. > В мире баш-программистов ядро и прочие компоненты системы как бы сами собой растут на > деревьях, их надо лишь собрать, а "система" - это набор разрозненных > пёрлов типа systemd-initramfs-degenerator.sh, в которых они ориентируются при помощи > умопомрачительных комбинаций параметров команды grep. Я и довольно забавные экспонаты видел, типа конекта по хитрозадому бинарному протоколу и проч, но там скрипт состоял из эскейпинга чуть менее чем полностью, и, честно, даже на сях это лучше выглядит.
	Ответить | Правка | Наверх | Cообщить модератору

	212. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от n00by (ok), 01-Июл-22, 07:47
	> не про ядро и речь. все юникс жили работой на баш скриптах(и > перле). А пёрл те баш-программисты не могут, потому и выкинули. На баше они пишут в основном spec-файлы для RPM, а не то, что подумали некоторые. ;)
	Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

	237. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 01-Июл-22, 21:29
	С этими я особо не контактирую, ибо в моем дистре DEB, для начала.
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от n00by (ok), 01-Июл-22, 07:43
	> весь линукс вырос из баш скриптов.он на них просуществовал около 20 лет. > чем тебя язык то не устроил. неужели даже в баш не > можешь. хоть чуток?)) Не могу, и это моя принципиальная позиция. Когда покажете аналог doxygen для bash, тогда будет другой разговор.
	Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

	183. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (-), 30-Июн-22, 21:16
	> фреймворк неделями. Безобразие. Правда Масяня на эту тему тролололил очень конкретно - мол, а что ты вообще представляешь из себя без своих плагинчиков? Хотя-бы формулу пороха могешь?!
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	49. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Без аргументов (?), 30-Июн-22, 10:50
	Где ты видел? Вездесущий. Хотя наверно а стартапе по телеграмму собесы...
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	54. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (43), 30-Июн-22, 11:02
	>Где ты видел? В одном обсуждении на rsdn.org. Сейчас уже не найду, но запомнил. Это, кстати, послужило одним из стимулов самому перейти на Rust, потому что Go-разработчики (видимо, благодаря лёгкости освоения языка) зачастую удручающего культурного уровня.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (62), 30-Июн-22, 11:31
	В чём ты на Раст то перешел в твоём хеллоуворлде, который ты даже показать никому не можешь? Это очень смешно.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–1 +/–
	Сообщение от Аноним (43), 30-Июн-22, 11:37
	>В чём ты на Раст то перешел в твоём хеллоуворлде, который ты даже показать никому не можешь? Это очень смешно. У меня, в принципе, есть несколько открытых Rust-проектов на github. Но показывать я их действительно не буду, потому что там многовато говнокода. С опытом начинаешь понимать ошибочность многих архитектурных решений, принятых ранее, но переписывать лень, проще учесть при начале новых проектов. Как пример, я понял ненужность крейтов вроде anyhow или eyre, "облегчающих" обработку ошибок ценой стирания информации о типе. В будущем — только строгая обработка (крейты thiserror или snafu).
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (124), 30-Июн-22, 13:53
	Посоветуешь что-нибудь про async rust? Курсы, лекции, книги? Информации о нём крайне мало.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (43), 30-Июн-22, 16:01
	Например, про async хорошо расписано в книге "Rust for Rustaceans". Это такая книга для "продвинутых" (есть на рутрекере).
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от px (??), 30-Июн-22, 17:46
	У нас Rust в проде почти 6 лет (посмотрел в гите) и прикрасно себя чувствую. Писать на нём приятно, а багов, в итоге, править меньше
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	91. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от n00by (ok), 30-Июн-22, 12:03
	>>Где ты видел? > В одном обсуждении на rsdn.org. Сейчас уже не найду, но запомнил. Помню такое обсуждение. Только было оно давно и там был Haskell.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	149. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (43), 30-Июн-22, 16:05
	Может быть, в контексте Haskell тоже что-то такое было. А ту дискуссию хорошо помню; участвовал там авторитетный на rsdn написатель Иван Дубров, американец. Он рассказывал, как для эксперимента втащили в проект Rust и обнаружили такой приятный побочный эффект, что Rust-разработчики были лучше мотивированы и более продуктивны, чем в среднем.
	Ответить | Правка | Наверх | Cообщить модератору

	217. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от n00by (ok), 01-Июл-22, 09:45
	> Может быть, в контексте Haskell тоже что-то такое было. А ту дискуссию > хорошо помню; участвовал там авторитетный на rsdn написатель Это как понимать? Я там был в топ 100, пока писал. Я авторитетный написатель? > Иван Дубров Не удивлюсь, что он и в той дискуссии участвовал: "Вопрос в другом. Можно взять и в лоб реализовать вычисление Haskell-программы — на основе редукции лямбда терма (в порядке call by name или call by need). И будет работать. Никакого стека там совершенно точно не будет. Состояние будет терм. Один шаг — одна редукция." > американец. А, да. Вот это аргумент. > Он рассказывал, как для эксперимента втащили в проект Rust и обнаружили > такой приятный побочный эффект, что Rust-разработчики были лучше мотивированы и более > продуктивны, чем в среднем. Лучше бы он возраст сравнил. Может там корреляция более устойчива?
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (109), 30-Июн-22, 13:07
	согласен со всем кроме >Зачастую без типизации, а значит нечитаемые и смертельно опасные туда сейчас типизация тоже очень активно проникает. всякие mypy еще конечно далеко не идеальны, но движутся в правильном направлении и достаточно быстро
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	196. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от maximnik0 (?), 30-Июн-22, 23:20
	>Деньги на раст получаются от тех, кому уже надоело платить за ошибки сишников и плюсовиков За последнее время я уже один раз слышал про безопасный язык и новый мир в програмирование.Тогда все уши прозжужали про безопасность языка ява.И вот я смотрю на 8 версия явы и чешу репу-откуда за 14 лет 219 исправлений, с 5-8 багами на багфикс,не считая около 18 критических? А ларчик просто открываеться-взаимодействие с внешним api и логические ошибки .
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	256. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от anonymous (??), 04-Июл-22, 21:10
	Это какие такие языки без типизации?
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	190. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 30-Июн-22, 22:12
	> Откуда такая толпа растаманов? И откуда у них деньги на зарплаты? Масонский заговор, не иначе. /s Ты не думал, что язык действительно может нравиться тем, кто пишет на нём? Или ты веришь в то, что любовь бывает только за деньги?
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

6. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–2 +/–
Сообщение от Аноним (6), 30-Июн-22, 09:20
Молодцы
Ответить | Правка | Наверх | Cообщить модератору

	11. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (43), 30-Июн-22, 09:47
	>Деньги на раст получаются от тех, кому уже надоело платить за ошибки сишников и плюсовиков Поддерживаю Вашу точку зрения, многоуважаемый Аноним. Кроме того, видел у работодателей ещё такую мотивацию, что приходят разработчики сразу уже очень хорошего уровня, то есть сам факт, что человек освоил Rust, означает, что преодолён некий ценз некомпетентности. Сишники и плюсовики с опытом, не желающие что-то менять, уже замшелые.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (62), 30-Июн-22, 11:32
	Нет у работодателей такой мотивации, не выдумывай.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (43), 30-Июн-22, 11:43
	>Нет у работодателей такой мотивации, не выдумывай. Ну, строго говоря, у меня не было обобщения на всех работодателей. Но о фильтровании потока кандидатов задумывается каждый... Впрочем, сейчас скорее вообще трудно найти разработчика на Rust, то есть работы больше, чем исполнителей. Об этом говорит ежедневный поток предложений работы на Rust в линкедине. То есть на Rust могут начать переходить искатели высоких доходов, то есть опять-таки люди чуждой мне культуры :).
	Ответить | Правка | Наверх | Cообщить модератору

15. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+5 +/–
Сообщение от Шарп (ok), 30-Июн-22, 09:51
>В следующие после этого 6 месяцев планируется реализовать проверку заимствования переменных (borrow checker) Т.е. компилятор не поддерживает главную фишку языка, из-за которой вся шумиха? Бгг.
Ответить | Правка | Наверх | Cообщить модератору

	18. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (43), 30-Июн-22, 09:55
	Не всё сразу. Впрочем, я тоже не совсем понимаю необходимость использования gcc; с тех пор, как его начали переписывать на C++, стало ясно, что проекту конец.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от EULA (?), 30-Июн-22, 09:59
	А на чем еще писать компилятор C++, кроме как не на С++?
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (6), 30-Июн-22, 10:02
	На ANSI C
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (32), 30-Июн-22, 10:10
	А компилятор раста на питоне?
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–1 +/–
	Сообщение от Аноним (6), 30-Июн-22, 10:21
	На расте
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+3 +/–
	Сообщение от Аноним (175), 30-Июн-22, 20:49
	Трололо ситуации состоит в том что кодогенератор дефолтного rust'а это LLVM, писаный на плюсах.
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от wyry (?), 20-Июл-22, 14:55
	Не говорите так! xD
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (110), 30-Июн-22, 12:42
	Так, как бы, компилятор С (gcc) в GCC уже частично на C++ написан.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	36. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (43), 30-Июн-22, 10:15
	>А на чем еще писать компилятор C++, кроме как не на С++? Предлагаю обратить Ваше внимание, мой достопочтенный оппонент, на то, что аббревиатура GCC содержит в себе начальную букву слова "collection".
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	80. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от 1 (??), 30-Июн-22, 11:56
	На паскале
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	113. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (110), 30-Июн-22, 13:15
	Россиянцы могут импортозаместительный набор компиляторов писать хоть на Отбероне.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Брат Анон (ok), 01-Июл-22, 07:53
	Вообще-то -- уже написано как минимум 4 компилятора и как минимум один интерпретатор для браузера.
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–1 +/–
	Сообщение от Аноним (224), 01-Июл-22, 13:48
	4 разных компилятора Оберона? Это ещё не набор в том смысле, как GCC.
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Брат Анон (ok), 02-Июл-22, 12:17
	> 4 разных компилятора Оберона? Это ещё не набор в том смысле, как > GCC. Он и не нужен -- весь этот зоопарк. Оберон системный язык программирования высокого уровня. Хоть ОС написать, хоть пакет символьной алгебры. И к тому же не позволяет грязными руками в памяти лазить.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+5 +/–
	Сообщение от Alladin (?), 30-Июн-22, 10:12
	GCC нужен для алтернативы выбора больше, дабы даже в линь ядре было меньше вопросов с навязкой LLVM.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	93. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (81), 30-Июн-22, 12:07
	gccrs нужен хотя бы для того, чтобы можно было начать сами компиляторы из gcc на rust потихоньку переписывать. Потому что если компилятор не может сам себя собрать, то это нехорошо. А когда у нас типа коллекция - единый продукт, то типа даже если компилятор сишный собирается компилятором раста, то это норм, ведь норм же собирать компилятор фортрана и ады компилятором сишным.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (89), 30-Июн-22, 12:33
	ЗАЧЕМ именно на Rust переписывать GCC? Он что, постоянно подвергается атакам?
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (81), 30-Июн-22, 12:59
	Причём тут атаки? Софт сложный, раст помогает со сложностью бороться.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (110), 30-Июн-22, 13:10
	Тогда GCC (сложный софт) нужно писать на языке, наилучшим образом воспринимаемом человеками. Это не про Rust.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (126), 30-Июн-22, 14:14
	Раст побеждает сложность - сложным синтаксисом. Побеждает утечки - безопасными утечками. Побеждает безопасность через unsafe.
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	152. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (43), 30-Июн-22, 16:23
	>Раст побеждает сложность - сложным синтаксисом Мне кажется, сложность растового синтаксиса — миф. Там всё на месте, ничего лишнего. Вон на Go как выворачиваются, только бы не использовать угловые скобки для генериков, а как ни крути — это лучшие символы для такой цели.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–1 +/–
	Сообщение от Аноним (19), 30-Июн-22, 09:57
	Самую назойливую. Как я это понял, просто напечатать переменную 2 раза подряд без копирований уже нельзя. А сахарок вполне не плохой, для тех, кому хочется потолще.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	73. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (89), 30-Июн-22, 11:47
	Rust и сахарок, Вы шутите?
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (43), 30-Июн-22, 11:53
	>Rust и сахарок, Вы шутите? В Расте полно синтаксического сахара. Взять хотя бы знак вопроса или async/await.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (19), 30-Июн-22, 11:59
	В смысле, сахар и сахарок?
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	88. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (43), 30-Июн-22, 12:02
	Намекаете на хрестоматийное стихотворение Алексея Грунина? Сахар, Сахар, Сахарок! Спас меня ты, мой дружок! и так далее...
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от UHkj hihfdvtuchnweu (?), 01-Июл-22, 11:08
	> Сахар, Сахар, Сахарок! > Спас меня ты, мой дружок! Ты ведь пробовал, дружок, Этот чудо сахарок?
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (175), 30-Июн-22, 20:51
	Инсулин в комплекте дают на случай пережора?
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	244. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от burjui (ok), 02-Июл-22, 00:56
	> просто напечатать переменную 2 раза подряд без копирований уже нельзя. $ > x.rs fn main() {     let x = vec![1,2,3];     println!("Раз {:?} и два {:?}", x, x); } $ rustc x.rs $ ./x Раз [1, 2, 3] и два [1, 2, 3]
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	247. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–1 +/–
	Сообщение от Аноним (19), 02-Июл-22, 01:47
	Ах, если бы всё так просто.
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от burjui (ok), 02-Июл-22, 02:19
	В Rust совсем немного сложных мест, если разобраться. Уж точно меньше, чем в C++, а уж его-то отлично знают местные эксперты (с их слов).
	Ответить | Правка | Наверх | Cообщить модератору

21. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+8 +/–
Сообщение от Аноним (6), 30-Июн-22, 10:00
Как получилось что смузихлебы, не знающие архитектуру, системы и чем отличается фон неймановская архитектура от гарвардской написали GCC-фронтэнд? И где местные эксперты которые все это знают, но ни строчки кода показать не могут...
Ответить | Правка | Наверх | Cообщить модератору

	29. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+7 +/–
	Сообщение от Жироватт (ok), 30-Июн-22, 10:09
	Ставлю 1000:1, что сделал это белый, здоровый телесно и психически, цисгендерный англосаксонский студент-угнетатель Jonh Smith в качестве курсовой по курсу белого, здорового телесно и психически, цисгендерного англосаксонского профессора-угнетателя университета лиги плюща (где такие пары еще сохраняются), а, затем, после сдачи, курсовик взяла кодла небинарных жиротранслесбух, нарисовала там радужные флажки, набила CoC(k)'ами и теперь обмазывается смуззи.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (6), 30-Июн-22, 10:19
	Вот и первый эксперт
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+3 +/–
	Сообщение от Анонус (?), 30-Июн-22, 12:11
	> англосаксонский студент-угнетатель Jonh Smith Намного вероятнее, что это был выпускник Пекинского университета Джу Вао Хань.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	191. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от mandms (ok), 30-Июн-22, 22:13
	что за CoC? "clash of concepts"?
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	218. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (218), 01-Июл-22, 09:51
	Code of conduct.
	Ответить | Правка | Наверх | Cообщить модератору

	228. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (224), 01-Июл-22, 14:24
	Почти рекурсия: Cock of Conduct
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Без аргументов (?), 30-Июн-22, 11:04
	Пока ещё ни одна компания, производящая полупроводники и микроконтроллеры или проиктирующая ядра, не выпустила ничего кроме как на Си. А это огромные кучи кода, то, что есть какие то попытки ардуиномакак сделать на расте, это только может мигать светодиодом, используя сишную основу.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	77. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Sw00p aka Jerom (?), 30-Июн-22, 11:53
	>не выпустила ничего кроме как на Си там и С не нужен, асм есть.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от 1 (??), 30-Июн-22, 11:58
	Фи ... уже полно и VB и питонятины
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (89), 30-Июн-22, 12:30
	Да и JS для микроконтроллеров есть. Не удивлюсь, если проект GNU туда запихнёт Guile.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Без аргументов (?), 30-Июн-22, 13:47
	Есть. Но что он, что пистон урезан до возможности вывести хеллоуворлд и подрыгать ногой, жестко прибитой к распиновке отладочной платы.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–1 +/–
	Сообщение от Без аргументов (?), 30-Июн-22, 13:49
	Они могут запихивать что угодно. Но микроконтроллеры не такой сложный софт, чтобы даже рабовладельцам было выгоднее стрепать калокод. Там до сих пор Си с классами вместо полноценного ООП.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	129. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (110), 30-Июн-22, 14:26
	Пробовал на Атмеге и наследование с виртуальными методами. Ничего страшного не произошло, брат жив.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (181), 30-Июн-22, 21:10
	> Пробовал на Атмеге и наследование с виртуальными методами. Ничего страшного не произошло, Бывает и хуже. Некто PWM с типа-синусом на питоне на ESP кодил. Прямо через GPIO. Даже как-то работало, только силовые ключи почему-то иногда #$%шили :) > брат жив. Пробовали ему систему жизнеобеспечения на этом делать? А лучше себе.
	Ответить | Правка | Наверх | Cообщить модератору

	227. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (224), 01-Июл-22, 14:03
	Систему жизнеобеспечения? Это был не Питон, а компилируемый язык, так что можно и её.
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 02-Июл-22, 00:15
	> Систему жизнеобеспечения? Это был не Питон, а компилируемый язык, так что можно > и её. А ты настолько хорошо понимаешь во что реально все эти виртуальные методы отливаются и где оно может взбрыкнуть чтобы свою тушку этому доверить?
	Ответить | Правка | Наверх | Cообщить модератору

	258. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от wyry (?), 20-Июл-22, 15:07
	Там C БЕЗ классов) и это абсолютно нормально для микроконтроллеров. C++ если и полезен, то только в очень крупных системах, в противном случае - чистый C + ASM (если требуется что-то нестандартное, что плохо или вообще не поддерживается железкой из коробки).
	Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

	119. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–1 +/–
	Сообщение от Без аргументов (?), 30-Июн-22, 13:45
	Где там? В однодневных репозитариях на гитхабе для управления очередной метеостанцией с помощью Cortex M7?
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	138. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (110), 30-Июн-22, 15:03
	Держу в курсе: Заказал вот такую платку https://aliexpress.ru/item/1005004372856686.html?item_id=100... с гигом ОЗУ. Да, это, конечно, уже не микроконтроллер, но цена платки приближается сверху к микроконтроллерным девбордам. Зато в неё поместятся не просто какие-то там микропитоны и т.д., а настоящий Python 3. Да хоть V8 или Spidermonkey.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Без аргументов (?), 30-Июн-22, 17:58
	Благодарю, такую не видел. Ну да, сделайте фотоловушку на таком жручем камне, которая бы передавала фотки по LTE или другому радиоканалу где-нить в диком месте на батарейках.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (110), 30-Июн-22, 19:59
	Для GNU Radio, если он соберётся под эту архитектуру.
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от burjui (ok), 02-Июл-22, 01:44
	> о, что есть какие то попытки ардуиномакак сделать на расте, это только может мигать светодиодом, используя сишную основу. peace door ball Найди мне здесь сишный код https://github.com/rust-embedded/cortex-m Не найдёшь, потому что на Rust точно также можно писать код инициализации и таблицу обработчиков прерываний, а либы с периферией генерятся автоматически утилитой svd2rust.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	194. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (194), 30-Июн-22, 22:50
	> Как получилось что смузихлебы, не знающие архитектуру, системы и чем отличается фон неймановская архитектура от гарвардской написали GCC-фронтэнд? Где ты в последний раз видел фон неймановскую архитектуру? В 8086? Архитектура x86 на 80286 не совсем успешно пыталась спрыгнуть с фон неймановской архитектуры, но в 80386 ей это удалось. И теперь у нас есть память ядра, области памяти процессоров, есть память исполняемая, есть read-only, и чтобы элементарно прокинуть данных в ядро мало просто обменяться с ним указателями, надо ещё пляски с бубном устраивать. Либо специальным образом копируя из юзерспейса, либо мапя юзерспейс-память на кернелспейс. Хвастаться он тут пришёл знанием "умных" слов... Чувак, твоё базовое IT образование устарело ещё в прошлом веке, ты знаешь об этом? Иди учись снова. > где местные эксперты В зеркало глянь.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	197. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Мимолеопард (?), 30-Июн-22, 23:27
	Эм, а как бы матчасть выучи. Фон Неймановская - совместное хранения команд и данных в единой памяти Гарвардсая - хранилище инструкций и хранилище данных представляют собой разные физические устройства И все эти закидоны с безопасностью, W^X например, или защиты стека от ROP - именно следствие Неймановской. Да, части процессора используют идеи гарвардской - раздельные кэши, раздельные шины. Но в целом, общее хранилище данных и команд - единая память - никуда не делось.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (206), 01-Июл-22, 06:33
	Технически никто не мешает в современном x86 сделать два селектора отображающих не пересекающиеся области памяти, у одного поставить разрешение на выполнение, у второго снять. И всё, считай у тебя будет две независимых памяти, в одной можно выполнять код, в другой нет. Так не делают из-за кучи легаси которая вся сломается, jit компиляторы, java, вот это всё.
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 01-Июл-22, 10:52
	> Фон Неймановская - совместное хранения команд и данных в единой памяти Современный x86 разделяет память на память для команд и данных. С точки зрения программиста -- прикладного, системного, ядерного -- разные области памяти нисколько не равноценны. ОС тщательно пытается скрыть эти нюансы и пытается создавать для приложения иллюзию фон неймановскости, но эта иллюзия сохраняется ровно до тех пор, пока ты не попытаешься сделать что-нибудь, для чего требуется фон неймановскость -- самомодифицирующися код, или подгрузить код библиотеки с диска, или даже прокинуть буфер в ядро -- тебе придётся учитывать, что это сильно не бесплатная операция, и в частности потому, что буфер в юзерспейсе и буфер в ядре -- это разные области памяти. Даже если ты создал два маппинга страниц для одного физического блока памяти, то это значит, что переключаясь между ядром и юзерспейсом, процессор будет сбрасывать одни кеши таблиц страниц, и загружать другие, хоть он и работает с одной физической памятью. Приложено невообразимое количество усилий, чтобы сохранить иллюзию фон неймановскости как своего рода абстракцию, но это leaky абстракция, она течёт как peшeтo. И если ты хоть раз попробуешь сделать на современном железе что-нибудь интересное, ты увидишь это воочию. Но я бы рекомендовал пойти и получить хорошее образование, потому что твоё явно осталось на уровне 8 класса 80-х годов. > Да, части процессора используют идеи гарвардской - раздельные кэши, раздельные шины. Да, и если мы решим что фон неймановскость -- это не о том, как для программиста выглядит, а как оно в железе реализовано, и закопаемся глубже чтобы посмотреть на устройство железа, мы увидим, что типов памяти гораздо больше. Ассоциативная память под кеши, RAM... И гора костылей поддерживающих иллюзию фон неймановскости. И эта абстракция не менее leaky чем софтварная. > И все эти закидоны с безопасностью, W^X например, или защиты стека от ROP - именно следствие Неймановской. Да, исправление фон неймановской архитектуры с целью повышения надёжности, багоустойчивости системы.
	Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

	240. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 01-Июл-22, 21:56
	> Современный x86 разделяет память на память для команд и данных. С точки > зрения программиста -- прикладного, системного, ядерного -- разные области памяти нисколько > не равноценны. ОС тщательно пытается скрыть эти нюансы 1) Это не только ОС пытается. 2) Изначально таки равноценны. 3) Кто и какие права в MMU страницам прописывает это вообще к нейман vs гарвард не относится напрямую. > и пытается создавать для приложения иллюзию фон неймановскости, Все проще. В современном железе до людей дошло что логически оно должно быть нейманом а физически гарвардом. Т.е. деление на I-bus и D-bus (а также соотв кеши у жирдяев) как бы есть и они как бы параллельно могут ворочаться и так быстрее, но логически при программировании мы это обычно не видим, кроме каких-то сильно специальных случаев. > фон неймановскость -- самомодифицирующися код, С этим не было бы никаких проблем - если бы не соображения systems security которые нынче так то диктуют правило W^X из соображений зарубания потуг эксплойтов на корню. Но это чисто конфигурационные вопросы на тему того какие права в MMU страницам прописаны. > или подгрузить код библиотеки с диска, или даже прокинуть буфер в ядро -- При взаимодействии с ядром надо понимать что адресное пространство процесса и ядра просто разные. Также есть виртуальная память и физическая, и это 2 большие разницы. Но к нейман vs гарвард это не относится. Более того mmap() в лине даже можно конкретный регион физической памяти отмаппить, конечно только от рута, и без lockdown'а, ибо ведет к полному поимению системы. > в юзерспейсе и буфер в ядре -- это разные области памяти. А современные шустрые zerocopy интерфейсы и оптимизации про это в курсе? Другое дело что там куча проверок и правами MMU конечно же порубано. Однако, операции, вот, удешевили. Вплоть до zerocopy. > peшeтo. И если ты хоть раз попробуешь сделать на современном железе > что-нибудь интересное, ты увидишь это воочию. Вообще это довольно нормальная абстракция, если не лезть в очень сильные дебри. Обращение к физическому адресу 0x100500 это именно оно, и только так. Какие права там в MMU и не прилетит ли за это в тыкву - вопрос номер два. > костылей поддерживающих иллюзию фон неймановскости. И эта абстракция не менее leaky > чем софтварная. Это попытка и рыбку съесть (не иметь гребли с гарвардом) и косточкой не подавиться (одновременно гонять инструкции и данные для них). > Да, исправление фон неймановской архитектуры с целью повышения надёжности, багоустойчивости > системы. Однако это лишь настройки MMU // я другой анон если что
	Ответить | Правка | Наверх | Cообщить модератору

	241. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 01-Июл-22, 23:09
	> 1) Это не только ОС пытается. Естественно, совместные усилия процессора и софта. Так конфигурабельнее, чем железно прошивать что-то неизменяемое. > 2) Изначально таки равноценны. Да, на одних и тех же физических законах работают. Или ты про то, что они сделаны на транзисторах? > 3) Кто и какие права в MMU страницам прописывает это вообще к нейман vs гарвард не относится напрямую. Если ты задашься вопросом зачем придумали такие абстракции как "нейман" и "гарвард", а потом это "зачем" применишь к современности, то ты увидишь, что они сегодня элементарно не работают, не выполняют своих функций. Бывают MCU или недо-процы которые следуют нейману или гарварду, но все топовые процессоры давно такие гибриды всех всевозможных идей из прошлого, что классификациями из XX века можно подтереться. Так же как и с языками программирования. Нам достались некоторые языки из прошлого, которые чисто императивны, или функциональны, или декларативны, или интерпретируемы, или ещё что. Но все языки XXI века не вписываются ни в одну парадигму, потому что тащат из всех парадигм то, что им удобно, и отбрасывают то, что не удобно. > Это попытка и рыбку съесть (не иметь гребли с гарвардом) и косточкой не подавиться (одновременно гонять инструкции и данные для них). Да, именно. Инженеры прагматичные люди, и когда академики наморщив лоб предлагают какую-нибудь классификацию процессоров, инженеры следуют ей только тогда, когда это удобно. И подтираются ею, когда прагматичнее сделать иначе. Все классификации академиков чем-то напоминают закон Мура: они работают, пока они работают, а потом они перестают работать. Есть некоторые фундаментальные, скажем периодическая таблица Менделеева: её пришлось немного допилить, когда выяснилось что тупо по массе сортировать нестоит, потому что у атомов одного элемента может быть разная масса. Но таблица пережила перепиливание, и пока выглядит так, что она _фундаментальна_, она описывает фундаментальный закон Вселенной. Но большинство классификаций не фундаментальны, а просто кто-то очень умничал, пытался набить себе публикаций, получить PhD, или профессуру. > А современные шустрые zerocopy интерфейсы и оптимизации про это в курсе? Это и на i386 можно было. Создать отмапить память процесса на память ядра, и вот ядро может читать. Но оно не меняет того, что тебе приходится проводить кучу манипуляций для того, чтобы добраться до какого-то куска памяти. Вот если проц на гарвардской архитектуре будет позволять, совершая определённые ритуалы, писать в программную память или читать оттуда -- будет ли это нарушением гарвардской архитектуры? Реально существуют MCU на гарвардской архитектуре которые могут перепрошивать сами себя, но для этого их распаять надо специальным образом (те о которых я знаю, по-крайней мере требуют специальной распайки). Насколько простыми должны быть эти ритуалы перепрошивки себя, чтобы они делали бы из гарвардской архитектуры фон-неймановскую? > Более того mmap() в лине даже можно конкретный регион физической памяти отмаппить И что? Если бы у тебя все адреса были бы равноценны, тебе бы не пришлось сношаться с mmap'ом. > Обращение к физическому адресу 0x100500 это именно оно, и только так. Когда ты в последний раз обращался к физическому адресу 0x100500? Ты можешь привести реалистичный пример программки на C, которая будет делать что-то типа *(unsigned char*)0x100500, и при этом обращаться именно к физическому адресу 0x100500? Никто не обращается к физическим адресам, все давным-давно работают с виртуальными. Только mm в ядре парится о физических адресах, чтобы таблицы страниц правильно заполнять. > Однако это лишь настройки MMU И что? Если ты упомянул "умную" аббревиатуру, то "это" перестало существовать? Я ещё раз говорю, только самые позорные прикладники, которые не парятся оптимизацией от слова совсем, могут пребывать в иллюзии фон-неймановскости. Наверное, это можно сформулировать и так, как ты это формулируешь: > Вообще это довольно нормальная абстракция, если не лезть в очень сильные дебри. Все кроме этих позорных прикладников вынуждены думать о стопке всё более медленных слоёв памяти в цепочке регистры-L1-...-LN-RAM-SSD/HDD/TAPE. Им приходится учитывать нюансы работы этих слоёв, хотя бы с точностью до порядка представлять себе объёмы этих слоёв. Им приходится думать о том, как быстро прокидывать данные между процессами, между юзерспейсом и ядром. Они никуда не денутся от всех этих проблем. А раз так, то какой смысл называть эту мешанину фон-Нейманом? Или я могу поставить этот вопрос иначе: насколько надо ещё эту мешанину усложнить, чтобы наконец признать, что это уже не фон-Нейман? У меня складывается ощущение, что ты считаешь, что ежели ядерный MM отлить в железе, то тогда это будет уже не фон-Нейман. Но ты понимаешь ведь, что никто в здравом уме годов с 70/80 такую сложность не отливает в железе? Такие сложности делаются софтварно. 8086 содержал микрокод, то есть множество программок, на каждую инструкцию по программке. В 8086 микрокод был прошит навсегда, но в более поздних процессорах его можно менять. Почему? Потомучто: а) слишком сложно в железе это делать, б) никаких транзисторов не хватит, и в) софтварное решение проблем гораздо гибче, настраиваемее.
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (-), 02-Июл-22, 01:19
	> Естественно, совместные усилия процессора и софта. Так конфигурабельнее, > чем железно прошивать что-то неизменяемое. Ну да. А гарвард в классическом его понимании как раз полный брейнфак. Кто сомневается, может попробовать AVR прогать на сях, повозиться с указателями и познать масштаб грабель. Вот именно чистый гарвард, когда он настолько полный что и в программную модель вылез, это булшит все же. Си, да и сабж наверное не заточены на такое сами по себе. > Да, на одних и тех же физических законах работают. Или ты про > то, что они сделаны на транзисторах? Я про то что поход на адрес 100500 это поход на адрес 100500, и будет ли он I-bus или D-bus сделан в принципе не проблема програмера, в 99.9(9)% даже может не задумываться над этим. В этом смысле современные железки чаще "логический нейман". А то что физически оно гарвард... прогеру обычно не видно. Только в каких-то глубоко системных операциях. Ну там early init когда I-cache и/или D-cache хотим как SRAM использовать за отсутствием DRAM, тут может начать интересовать. Более детально в Cortex M видно: Cortex M0 нейман целиком (1 шина на все, 1 адреса). А M3 и жирнее уже нейман в логике, но I-bus и D-bus уже разные в физике, и так ессно быстрее при прочих равных. Но программная модель - нейман и от M0 в этом аспекте вообще отличия найти сложно. > Если ты задашься вопросом зачем придумали такие абстракции как "нейман" и "гарвард", > а потом это "зачем" применишь к современности, то ты увидишь, что > они сегодня элементарно не работают, не выполняют своих функций. Я их условно разделил на "логический" и "физический" уровни. Так вроде катит. Ну то-есть если есть I-bus и D-bus, то физически гарвард, но логически может нейманом выглядеть, чтобы не делать мозг пространствами. > классификацию процессоров, инженеры следуют ей только тогда, когда это удобно. В случае RISC vs CISC все еще интереснее. > Но таблица пережила перепиливание, и пока выглядит так, что она _фундаментальна_, А вон вам для гарвард vs нейман "с дополнениями". Разделим логику и физику, так вроде недурно классифицирует все что на глаза попадалось. > она описывает фундаментальный закон Вселенной. Но большинство классификаций > не фундаментальны, Вообще, 1 шина на все vs I-Bus + D-Bus достаточно фундаментальное деление вроде. Во что это трансформируется в софте - отдельный вопрос. > что тебе приходится проводить кучу манипуляций для того, чтобы добраться до > какого-то куска памяти. Сейчас штуки типа линуха сделали подобные вещи достаточно lightweight. Конечно переключение контекста при желании отдать что-то ядру будет, и это не совсем халява. Но именно копиривания все же нету, потому и zerocopy. И сишные указатели за что-то такое все любят. > Вот если проц на гарвардской архитектуре будет позволять, совершая определённые ритуалы, > писать в программную память или читать оттуда -- будет ли это > нарушением гарвардской архитектуры? Ну, посмотрите на AVR. На си это мапится ушлепански. В gcc ведет к указателям которые как бы выглядят одинаково но не эквивалентны. Реально SRAM и FLASH натурально 2 разные пространства. В чем трабл? А в том что они не взаимозаменяемы и много нестандартных особенностей. > Реально существуют MCU на гарвардской архитектуре которые могут перепрошивать сами себя, Ну вот конкретно в AVR это отливается в то что оно не может извне вгрузить модуль в RAM. То-есть налить то код туда можно, но выполнить его - болт. В этом месте кортексы имеют нефиговый плюс. Даже если оно M3, вот так к SRAM bus matrix цепляет I, а вот так D, так что можно и код и данные. > распайки). Насколько простыми должны быть эти ритуалы перепрошивки себя, чтобы они > делали бы из гарвардской архитектуры фон-неймановскую? Ну вон для "истинного гарварда" AVR подобное временами ведет к брейнфаку. Фокус в том что при записи флеш "временно недоступен" и в лучшем случае его контроллер держит шину и исполнение паузится на весьма ощутимое время в течение которого чип совершенно недееспособен. Хуже если не паузится :). А ежели код в SRAM выполняется, он при записи флеша живой и веселый, если не сунется в занятый флеш сдуру. > И что? Если бы у тебя все адреса были бы равноценны, тебе > бы не пришлось сношаться с mmap'ом. Это требуется в основном из-за многозадачности. Каждому процессу кажут свое адресное пространство, полного размера. Он по нему может как правило целиком шариться (получит SIGSEGV за некоторые вещи). Очевидно физический лэйаут памяти не может совпадать 1 в 1 с этим. Иначе все процессы будут видеть всех, и внутренности ядра, отстой по безопасности. Но это другая абстракция, не особо связаная с гарвардом и нейманом, это "виртуальная память". В системе с VM и paging имеет смысл операция "memory mapping". Она отображает физические адреса в логические. Если бы мне не пришлось сношаться с mmap, я мог бы полностью перехватить контроль над системой, ибо некоторые физические регионы памяти это вообще железо. И я ммапал чтобы в регистры железки сходить "бех драйвера ядра" так то. Это вообще делать не стоит без понимания почему это может прокатить: прямой доступ таким манером рушит допущения многозадачки, при этом нет никакого арбитража доступа разных процессов и ядра и можно на этом нехило налететь. > Когда ты в последний раз обращался к физическому адресу 0x100500? Не так уж давно, а что? > Ты можешь привести реалистичный пример программки на C, которая будет делать что-то типа > *(unsigned char*)0x100500, и при этом обращаться именно к физическому адресу 0x100500? Бутром из STM сдампил, характерной фичой "dumpblock(addr, len)" берущей на вход - только подумайте - лобовой адрес "чего дампим". Любой из 2^32 (оно 32-битное). Или даже в лине мапил конкрентые физические адреса ммапом чтобы железку потрогать. Но она ядром не поддерживалась, что гарантировало отсутствие обращений ядра и других программ. Вот так это даже может прокатить, но все-равно не стоит это делать. > Никто не обращается к физическим адресам, все давным-давно работают с виртуальными. Только > mm в ядре парится о физических адресах, чтобы таблицы страниц правильно заполнять. Ок, так круто за всех сишников говорить... только вот вся работа с железом например это работа с конкретными физическими адресами. Оно за mem-mapped, потому что это просто, быстро, хорошо работает, удобно сям. > И что? Если ты упомянул "умную" аббревиатуру, то "это" перестало существовать? Я лишь имел в виду что к гарварду MMU вообще ортогонален. И по логике вещей у "полного" гарвардца должно быть их минимум два: на I-адресацию и D-адресацию. Так то еще IOMMU бывает, но он про чуть иное: постановку железок в стойло. DMA так то тоже оперирует лобовыми адресами, физическими. И это не только позволяет железке полностью отыметь систему, но и к тому же ведет к очень интересным эффектам если железку в виртуалку пробросить. Там у драйвера свои идеи насчет адресов, только вот с хостом это не совпадает и когда железка запроганая драйвером в guest сделает именно вот туда DMA... :))) > сформулировать и так, как ты это формулируешь: >> Вообще это довольно нормальная абстракция, если не лезть в очень сильные дебри. Я разделяю как минимум логическое представление и физическую реализацию. И да, вы верно заметили что возможны гибриды когда в логике нейман, а в физике гарвард. > Все кроме этих позорных прикладников вынуждены думать о стопке всё более медленных > слоёв памяти в цепочке регистры-L1-...-LN-RAM-SSD/HDD/TAPE. HDD и TAPE как правило не адресуемы как адреса памяти. Хотя mmaped файлы в случае HDD как частный случай могут немного поспорить с этим. > насколько надо ещё эту мешанину усложнить, чтобы наконец признать, что это > уже не фон-Нейман? Со своей стороны я считаю логическим нейманом ежели все адреса в адресном пространстве дереференсятся одинаково. А если надо адресные пространства учитывать, это уже логический гарвард. Заметьте, физическая реализация тут не фигурирует. > У меня складывается ощущение, что ты считаешь, что ежели ядерный MM отлить > в железе, то тогда это будет уже не фон-Нейман. Для меня ответ на этот вопрос в контексте "логический нейман vs логический гарвард" будет зависеть от того греет ли програмер мозг отдельными адресными пространствами. > сложность не отливает в железе? Такие сложности делаются софтварно. Вообще-то программно-аппаратно. Совсем софтварно это малореализуемо и тормозно и требует очень явной поддержки именно железом. Как то paging и MMU. И вот этот паттерн многие собезьянили. > микрокод, то есть множество программок, на каждую инструкцию по программке. Не на каждую IIRC. Только на сложные. Это такой способ компрессии потока команд а потом и некая абстракция логического апи наружу от физической реализации. Внутри современнй x86 совсем не то что снаружи. > можно менять. Почему? Потомучто: а) слишком сложно в железе это делать, Вообще-то там в проце дефолтный uCode ROM защит. Просто его можно оверрайдить загружаемым, это после ряда увесистых багов в процах подгорело. Но uCode ROM это специфика махровых CISC. У большей части RISC его вообще нет, это одна из довольно четких границ водораздела RISC vs CISC. > б) никаких транзисторов не хватит, и в) софтварное решение проблем гораздо > гибче, настраиваемее. Оно таки не полностью софтварное. Да и вообще uCode ROM заменили на uCode SRAM. И некие дефолты там есть, без него CISC вообще свой набор команд не могет выполнять по идее. Как минимум сложные операции, разбиваемые на микрооперации. RISC на самом базовом уровне отличается тем что операции простые и не бьются на более мелкие микрооперации секвенмируемые uCode ROM. И таки это делает процессорное ядро проще и меньше при прочих равных.
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 02-Июл-22, 08:38
	>> Если ты задашься вопросом зачем придумали такие абстракции как "нейман" и "гарвард", >> а потом это "зачем" применишь к современности, то ты увидишь, что >> они сегодня элементарно не работают, не выполняют своих функций. > Я их условно разделил на "логический" и "физический" уровни. Так вроде катит. Ну то-есть если есть I-bus и D-bus, то физически гарвард, но логически может нейманом выглядеть, чтобы не делать мозг пространствами. Как ты интересно проигнорировал вопрос. Если глянуть на https://en.wikipedia.org/wiki/Von_Neumann_architecture#Desig... то там показано, что современная архитектура нихрена не фон-нейман, даже схемка нарисована, для сравнения с той, что в начале статьи. Но если бы ты не игнорировал вопрос, а вот в той же статье на википедии почитал бы раздел History, то увидел бы, что фон Нейман рассуждал о том, как было бы хорошо, если бы компьютеры не прошивались бы один раз и навсегда, а могли бы модифицировать код, и в этом смысле современные процессоры можно рассматривать как развитие архитектуры -- идея та же, но дополненная многими другими. Правда вопрос о том, зачем сегодня могут быть нужны абстракции "фон нейман" и "гарвард", остаётся висеть в воздухе. А это ведь ключевой вопрос, так? Ты как инженер (ты ведь инженер?) должен понимать это? Это же базовое мышление инженера, которое прививается ему на первом курсе. Мы сначала берём задачу (то самое "зачем"), затем формулируем требования к решению (в данном случае, этими требованиями будут критерии принадлежности двух архитектур к одному или разным классам), после этого создаём решение этой задачи (в данном случае классификацию архитектур). Если у тебя нет задачи, и ты классифицируешь ради классификации, то это болезнь. > Да и вообще uCode ROM заменили на uCode SRAM. И некие дефолты там есть, без него CISC вообще свой набор команд не могет выполнять по идее. Как минимум сложные операции, разбиваемые на микрооперации. RISC на самом базовом уровне отличается тем что операции простые и не бьются на более мелкие микрооперации секвенмируемые uCode ROM. И таки это делает процессорное ядро проще и меньше при прочих равных. Садись, пять. Выше практически все твои реплики типа "демонстрация знаний ради демонстрации знаний", с абсолютной потерей нити беседы. Каждый раз. Ладно бы ты демонстрировал какие-то малоизвестные знания, но ты же по большей части по учебнику первого курса шпаришь. У тебя какие-то комплексы по этому поводу? Ты испытываешь неодолимое желание демонстрировать окружающим свои познания?
	Ответить | Правка | Наверх | Cообщить модератору

30. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
Сообщение от anonn (?), 30-Июн-22, 10:09
Кто-то может обьяснить зачем это нужно когда есть mrustc, который нужно просто допилить?
Ответить | Правка | Наверх | Cообщить модератору

	33. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (32), 30-Июн-22, 10:11
	не нужно
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (40), 30-Июн-22, 10:24
	Чтобы был включён в ядро под сусом: ой оно само как-то так получилось
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	79. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (89), 30-Июн-22, 11:56
	Под правильной лицензией и без всяких LLVMов.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	182. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (181), 30-Июн-22, 21:12
	> Кто-то может обьяснить зачем это нужно когда есть mrustc, Сравнили мощный тулчейн с крутыми оптимизациями и поддержкой 100500 процессорных архитектур с mrustc.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

31. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
Сообщение от Аноним (32), 30-Июн-22, 10:09
На раст нет спецификации и меняется с каждой версией. Смысл пытаться постоянно догонять?
Ответить | Правка | Наверх | Cообщить модератору

	37. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+3 +/–
	Сообщение от Аноним (43), 30-Июн-22, 10:17
	>Смысл пытаться постоянно догонять? Сейчас времена такие. Надо бежать изо всех сил, чтобы хотя бы оставаться на месте...
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (62), 30-Июн-22, 11:35
	Т.е. если остановится ты будешь двигаться быстрее чем если бы бежал? Зачем тогда бежать? Физика тебя не одобряет.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (43), 30-Июн-22, 11:46
	>Т.е. если остановится ты будешь двигаться быстрее чем если бы бежал? Зачем тогда бежать? Физика тебя не одобряет.   Дак никто не гарантировал, что физика материального подмира действительна в подмирах, являющихся продуктами интеллектуальной фантазии (как бизнес-процессы или так называемая экономика).
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (128), 30-Июн-22, 14:21
	«Алиса в стране чудес» это как раз про подмиры.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (110), 30-Июн-22, 15:17
	Так и микология тоже про эти подмиры.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Sw00p aka Jerom (?), 30-Июн-22, 11:55
	без неподвижной точки отсчета не докажешь движение.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	86. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (43), 30-Июн-22, 12:00
	>без неподвижной точки отсчета не докажешь движение Зависит от определения понятия "движения" в конкретной аксиоматической системе. Например, многие течения буддизма постулируют, что движение не имеет начала.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (89), 30-Июн-22, 12:16
	Так и в физике движение не обязано иметь начала или конца. Имеет смысл текущее положение относительно какой-то точки.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Sw00p aka Jerom (?), 30-Июн-22, 12:44
	>Имеет смысл текущее положение относительно какой-то точки. тогда еще неподвижность точки надо доказывать, кто-то там говорил "все в движении".
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (110), 30-Июн-22, 14:32
	Не нужно. Инерциальные системы отсчёта.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (110), 30-Июн-22, 14:38
	Абсолютное движение это только в воображении эфирщиков. В физике всё движение или покой относительны.
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	98. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от n00by (ok), 30-Июн-22, 12:19
	> многие течения буддизма постулируют, что движение не имеет начала. Западная наука нашла этому феномену банальное объяснение, изучив состав благовоний.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	114. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Sw00p aka Jerom (?), 30-Июн-22, 13:30
	>Например, многие течения буддизма постулируют, что движение не имеет начала. возьмите белый лист бумаги и не касаясь кончиком пера листа бумаги, проведите линию. Начерченная линия есть движение точки касания кончика пера. Можем ли первую точку касания пера назвать началом? Можем, но если посмотреть на лист он и есть множества всех этих путей, тогда за начало мы можем принять и край листа. К чему все это? Понятие начала так же как и движения не просто доказать.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	180. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 30-Июн-22, 21:02
	> возьмите белый лист бумаги и не касаясь кончиком пера листа бумаги, проведите линию. В CNC лазерник его сунь, он покажет как это делать правильно. Начало и конец движения тоже найдется.
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Sw00p aka Jerom (?), 01-Июл-22, 02:06
	>Начало и конец движения тоже найдется. любая точка будет началом
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 01-Июл-22, 02:47
	> любая точка будет началом А таки там обычно есть абсолютные точки отсчета типа центра системы координат и начало и конец линии будет относительно этого как прописано в кадфайле.
	Ответить | Правка | Наверх | Cообщить модератору

	222. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Sw00p aka Jerom (?), 01-Июл-22, 11:53
	так и есть, калибровка с любой точки возможна, относительно ее происходят дальнейшие действия
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (89), 30-Июн-22, 12:13
	Если не бежать, будешь двигаться с отрицательной скоростью.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	99. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от n00by (ok), 30-Июн-22, 12:23
	А если найти источник цитаты из №37, то можно составить список экспертов по физике.
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Sw00p aka Jerom (?), 01-Июл-22, 11:55
	сектор приз на барабане, попробуйте его крутануть одновременно как по часовой так и против
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	225. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (224), 01-Июл-22, 13:52
	Право-левый спин? Хм, в этом что-то есть...
	Ответить | Правка | Наверх | Cообщить модератору

	229. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Sw00p aka Jerom (?), 01-Июл-22, 14:35
	> Право-левый спин? Хм, в этом что-то есть... неее, это ведь равносильно "не крутить", отсюда вопрос, можно ли доказать покоится "барабан Якубовича" или вращается.
	Ответить | Правка | Наверх | Cообщить модератору

	231. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (224), 01-Июл-22, 15:28
	Смотря, относительно какого наблюдателя. Если система остчёта наблюдателя связана с барабаном, то покоится.
	Ответить | Правка | Наверх | Cообщить модератору

	233. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Sw00p aka Jerom (?), 01-Июл-22, 16:32
	> Смотря, относительно какого наблюдателя. Если система остчёта наблюдателя связана с барабаном, > то покоится. для стрелки, указывающей на сектор, покоится, но ведь барабан приводят в движение два игрока, один по часовой другой против, и для них барабан в движении. Приведу другой пример (с барабаном случай противоположных движений), представьте вращение белого-белого бильярдного шара (вращение в одном направлении) с бесконечной скоростью. Можно ли на глаз определить покоится он или вращается? Даже если нарисовать на нём черную точку, при вращении с бесконечной скоростью, что мы увидим?
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Alladin (?), 30-Июн-22, 10:46
	Кажись раст еще в первой версии определился что он раст и специфики никогда не менял:)) Автор, ну але.. Язык развивается, как и все.. Но при эттм у языка есть четкое разделение стабильных и нестабильных фитч и годов редакции.. для нас разрабов это все учитывается и нестабильные фитчи мы подрубаем вручную ничего не ломая.. а пакеты разных годовых редакций 15 года, 18 года и 20 года между собой совместимы..
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	66. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (62), 30-Июн-22, 11:36
	И как это всё мешает выпустить спецификацию? Я конечно понимаю что ты мало образован и не понимаешь зачем, но всё же почему не собрались и не выпустили. Язык же якобы системный (на самом деле нет)
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–2 +/–
	Сообщение от Аноним (43), 30-Июн-22, 11:58
	>Язык же якобы системный (на самом деле нет) Системный или несистемный — это всего лишь ярлык. Значение имеет лишь то, будут ли использовать тот или иной язык инженеры, именно инженеры, которым важна эргономика инструмента.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Sw00p aka Jerom (?), 30-Июн-22, 13:44
	>которым важна эргономика инструмента. важно соблюдать инструкции по безопасности для работы с инструментом. Не соблюдая инструкциям безопасности приводит к печальным последствиям, и это не повод кричать, что инструмент гамно.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (128), 30-Июн-22, 14:17
	Дураку (тебе) ни что не поможет ни безопасный инструмент, ни каска. Ты любым инструментом натворишь дел и раст тебе вообще не помошник, скорее наоборот.
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	137. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+4 +/–
	Сообщение от Alladin (?), 30-Июн-22, 14:58
	"но всё же почему не собрались и не выпустили" https://rust-lang.github.io/rfcs/introduction.html
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	158. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от warlock66613 (ok), 30-Июн-22, 17:32
	Что полезного сделает спецификация? Хоть десять спецификаций выпусти, реальная спецификация всё равно будет неявно определяться референсным компилятором. Известная история же, проходили с Haskell и GHC.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	193. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Аноним (193), 30-Июн-22, 22:26
	Спецификацию уровня ANSI/ISO? Это очень долго, муторно и сейчас бессмысленно - оно будет только тормозить развитие языка, как это происходит с с++. Нужно собирать комитет, где все будут годами рассуждать о чем-то, тянуть на себя одеяло, тихонько попиливая бюджет. Ради интереса, посмотрите когда появился Си, а когда появился первый стандарт C89. Стандартизация началась в 1983, а закончилась только в 1989. Шесть лет обсуждений! Причем для настолько простого варианта языка. Для раст (или любого современного языка) это затянется на десятилетия.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	68. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (68), 30-Июн-22, 11:37
	>  и меняется с каждой версией Ну, если он так меняется, что нужные мне крейты без внесения изменений без проблем компилируются после смены уже не одной версии в течении уже полутора лет, то пусть меняется. Пока еще не столкнулся с проблемами при смене версий.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

51. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
Сообщение от Аноним (51), 30-Июн-22, 10:53
Ждем ОГБТ/CoC от GCC
Ответить | Правка | Наверх | Cообщить модератору

	53. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от Жироватт (ok), 30-Июн-22, 11:02
	Ждем ОГБТ/CoC от ОРДЕНА ТРУДОВОГО КРАСНОГО ЗНАМЕНИ ЛАТИНОАМЕРИКАНСКОГО МЕЖГОСУДАРСТВЕННОГО КОМИТЕТА СПО АВТОМАТИЗИРОВАННОГО СБОРОЧНО-ЛЕКСИЧЕСКОГО КОМПЛЕКСА ГНУ ГЦЦ На мой взгляд - так лучше
	Ответить | Правка | Наверх | Cообщить модератору

60. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+5 +/–
Сообщение от Аноним (60), 30-Июн-22, 11:22
Не, ну если хотят собирать модули на расте для ядра, то лучше иметь раст в "штатном" наборе компиляторов, чем нечто "левое" через "левый" rustup.
Ответить | Правка | Наверх | Cообщить модератору

70. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
Сообщение от Аноним (81), 30-Июн-22, 11:46
>В следующие после этого 6 месяцев планируется реализовать проверку заимствования переменных (borrow checker) "Реализация Rust" без borrow-checkerа не имеет права называться реализацией Rust.
Ответить | Правка | Наверх | Cообщить модератору

	75. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (89), 30-Июн-22, 11:53
	Похеру, как она будет называться, лишь бы модули ядра, которые будут на Расте, успешно собирала.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (81), 30-Июн-22, 12:03
	Не будет она собирать модули ядра, ведь всем известно, что пакеты на rust собирает не rustc, а cargo (которому нехипстерский gcc нафиг не нужен, конкурент он), который тебе пол-crates бэкдоров выкачает, соберёт и запустит, а без зависиостей с crates, по десятку версий на одну и ту же зависимость, ты хрен что соберёшь. Раст станет нормальным языком тогда, когда его поддержка появится в CMake, причём без `Cargo.toml`, а через `find_package()`, где пакеты бирутся из системы какие есть, и линкуются динамически.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от НяшМяш (ok), 30-Июн-22, 13:32
	Cargo это тот же самый аналог cmake, который внутри себя дёргает rustc. Никто не мешает вручную дёргать rustc и лапками линковать. Просто это нафиг никому не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–1 +/–
	Сообщение от Аноним (81), 30-Июн-22, 14:38
	CMake линкует либы из системы, какие сказано, такие и линкует. Сказано линковать какие есть - значит линкует какие есть. Сказано скачать - значит скачивает. Сказано не качать - значит не скачивает. Сказано собирать - значит собирает. Не сказано - значит не собирает. Cargo же просто качает всё подряд, собирает всё подряд, линкует статически всё подряд. Те версии, какие сказано в репозиториях, и не сказать нельзя. В какой-то зависимости сказано "использовать супер-древнюю версию" - он выкачивает и её, а потом у нас бинарники на десятки мегабайт получаются для маленькой простой программы, которая делает простую вещь, просто потому что кто-то шибко умный решил написать её на сыром недоделанном ЯП от смузихлёбов. Карго сам так делает, я его это делать не просил, и разработчикам программ другого выбора и не предоставляет, хочешь программировать на расте - либо терпи всё это дерьмо, либо пиши свою собственную систему сборки.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (110), 30-Июн-22, 15:12
	О коде на Rust в ядре. А что, стандартная система сбрки ядра не сможет вызывать gccrs? Ядерщики не позволят тянуть в ядро эту чуждую систему сборки.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Прогресс в разработке компилятора для языка Rust на базе GCC"	–2 +/–
	Сообщение от Аноним (81), 30-Июн-22, 20:53
	Никто не будет писать модули так, как этого захочет Линус. Будут писать так, как захотят ржавые макаки. А кому такие драйвера не будут нравится - тот будет без драйверов сидеть, драйвер ведь есть, уже написан, notabug, invalid, wontfix.
	Ответить | Правка | Наверх | Cообщить модератору

	226. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (224), 01-Июл-22, 13:56
	Те, кому уже написанные не понравятся, тоже Rust освоят. Будут править, чтобы собирались штатными средствами ядра и gccrs. Всё же, это значительно проще, чем from scratch.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
	Сообщение от НяшМяш (ok), 30-Июн-22, 23:28
	Записал в Cargo.toml зависимость - он её скачал. Не записал - не скачал. Надо залинковать внешнюю зависимость - если у неё есть -sys крейт, то тоже элементарно вписывается в Cargo.toml. Нет -sys крейта - создаём сами и указываем в Cargo.toml на локальную папку. Нужны дополнительные ключи сборки - что-то поддерживается в Cargo.toml, что-то можно передать в build.rs. Вот вообще никакой разницы не увидел.
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	252. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Прохожий (??), 02-Июл-22, 09:15
	Во-первых, есть и динамическая линковка. Во-вторых, линкует только то, что указано в файле зависимостей, а не всё подряд. Не нравится то, что скачивает Cargo, убери эту зависимость, если тебя действительно волнует размер исполнимого файла, и ты сюда не просто свою желчь пришёл излить, а конструктивно обсуждать вполне себе годный язык и его куда более продвинутую систему сборки, чем убогая cmake.
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	94. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (89), 30-Июн-22, 12:09
	Какие пакеты, какая Карга? Речь о модулях ядра. Там все исходники всё_в_одном архиве linux-x.y.tar.gz.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	104. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (81), 30-Июн-22, 12:48
	>Там все исходники всё_в_одном архиве linux-x.y.tar.gz Ты думаешь разработчики на Rust могут без крейтов? Нет, будет так. Вот вам out-of-tree модуль, использующий крейты, и поэтому не в ядре, кому не нравится - тот сидит с неработающим железом. Дистры берут его и пакуют, и наср@ть на крейты. Ведь дистры - это про UX, они даже проприетарь пакуют и поставляют, ведь иначе никак.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (110), 30-Июн-22, 12:54
	Палец Линуса им такое безобразие позволит?
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+4 +/–
	Сообщение от Аноним (153), 30-Июн-22, 16:29
	А что вам мешает запаковать нужные крейты в архив и собрать их на пользовательской машине? Это ничем не будет отличаться от архива с исходниками и make-файлом для Си/Си++. Такое чувство, что про раст вы только из комментариев на опеннете узнаете. Из этого языка можно сделать все, что угодно. Если хочешь, то можешь писать как на плюсах, если же нужно писать в baremetal или на очень низком уровне, то отключаешь ненужные модули и получаешь лучшую версию Си. Можно использовать карго, а можно и не использовать. Можно качать крейты, а можно не качать и работать с зависимостями в стиле Си. Единственная претезния к языку - это централизованная разработка и один компилятор. Но gccrs решаеют эту проблему.
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	176. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (81), 30-Июн-22, 20:50
	>А что вам мешает запаковать нужные крейты в архив Ага, половину crates.io, половину версий каждого пакета.
	Ответить | Правка | Наверх | Cообщить модератору

	249. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от burjui (ok), 02-Июл-22, 01:55
	>Такое чувство, что про раст вы только из комментариев на опеннете узнаете Именно отсюда и узнают. Неоднократно убеждался, что местные хейтерята даже не читали базовые доки.
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

87. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
Сообщение от 1 (??), 30-Июн-22, 12:01
Хммм ... Вангую новую тотальную волну - кто быстрее (надёжнее, меньше выходные файлы) компиляет раст.
Ответить | Правка | Наверх | Cообщить модератору

108. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
Сообщение от Аноним (108), 30-Июн-22, 13:03
Жаль, что до мая следуещего года еще так долго ждать.
Ответить | Правка | Наверх | Cообщить модератору

	135. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (110), 30-Июн-22, 14:42
	Так и годных рабочих модулей ядра на Расте до мая следующего года ещё не появится.
	Ответить | Правка | Наверх | Cообщить модератору

139. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
Сообщение от Аноним (139), 30-Июн-22, 15:08
А теперь угадайте, какая судьбинушка будет у этого gccrs, если: он стопроцентно будет в качестве догоняющего у обычного раста (ведь обычный раст не пишется под стандарт, он и есть стандарт), вся экосистема раста прибита гвоздями к cargo, а cargo-культ из мозгов не выбить. Проще было бы пнуть Столлмана на то, чтобы он к своему елиспу гвоздями прибил бы нужную типизацию и нужную семантику, не убив вконец макры, полученное можно было прицепить к GCC и назвать языком антилоп. И от этого было бы больше прока.
Ответить | Правка | Наверх | Cообщить модератору

	141. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (110), 30-Июн-22, 15:15
	Лучше тогда взять Гайл. Он у них, как бы, более универсальный получился.
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (234), 01-Июл-22, 17:37
	>Лучше тогда взять Гайл. Он у них, как бы, более универсальный получился. Твои слова да Andy Wingo или как там его в уши: пирамиду языков сделали, а полноценную поддержку этих самых языков (или хотя бы полный common lisp и scheme в одном пакете) - нет, как и оптимизации. Сам пишу на guile и поплакиваю, смотря на chicken scheme и sbcl.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Alladin (?), 30-Июн-22, 16:34
	"ведь обычный раст не пишется под стандарт, он и есть стандарт" есть определенная сборка rfc которая и определяет что такое раст. но роль догоняющего у gccrs остается, так как основное сообщество им не будет заниматся и все основное тестирование и сборки будут сосредоточены на llvm.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	157. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (110), 30-Июн-22, 17:12
	Главное, чтобы кернелостроители ориентировались на актуальную версию GCC/gccrs.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от burjui (ok), 02-Июл-22, 01:51
	> Проще было бы пнуть Столлмана на то, чтобы он к своему елиспу гвоздями прибил бы нужную типизацию и нужную семантику, не убив вконец макры Ещё бы вместо скобочек сделать нормальный синтаксис - и получится хорошо. Только зачем, если уже хорошо? Плохо только местным хейтеркам-бунтарям против системы и всемирного зла, которых насильно заставляют читать новости о Rust.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

144. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
Сообщение от Аноним (-), 30-Июн-22, 15:34
Раст может взлететь только после одобрения его Столлманом. Не одобрит - не взлетит. Раст должен иметь лицензию со строгим копилефтом - GPL v.3 or later. Растаманы! Ваша судьба в руках великого Столлмана!
Ответить | Правка | Наверх | Cообщить модератору

162. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+2 +/–
Сообщение от SNM (?), 30-Июн-22, 19:37
Непонятно зачем это нужно, когда есть Си и Паскаль (без шуток). Очередное "изобретение колеса ради изобретения" какой-то в последнее время наблюдаю.
Ответить | Правка | Наверх | Cообщить модератору

	169. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Sw00p aka Jerom (?), 30-Июн-22, 20:33
	>Очередное "изобретение колеса" не колеса, а палок для колеса
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (-), 30-Июн-22, 21:53
	> Непонятно зачем это нужно, когда есть Си и Паскаль (без шуток). Очередное > "изобретение колеса ради изобретения" какой-то в последнее время наблюдаю. И как, много системщины на паскале напрогали? Это ж мучительно что пипец. И результат очень так себе.
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

	192. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (193), 30-Июн-22, 22:18
	Ну, чтобы потом в OpenSSL не было "перезаписано или прочитано до 8192 байт". А по второму - что мертво, умереть не сможет.
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

	215. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (43), 01-Июл-22, 09:11
	>Непонятно зачем это нужно, когда есть Си и Паскаль (без шуток) Наивность? Языки программирования устаревают вообще-то, как и всё остальное.
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

200. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
Сообщение от Michael Shigorin (ok), 01-Июл-22, 00:30
Как назвали-то -- grust? :)
Ответить | Правка | Наверх | Cообщить модератору

	201. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+1 +/–
	Сообщение от Аноним (6), 01-Июл-22, 00:34
	Прочитайте текст новости прежде чем писать
	Ответить | Правка | Наверх | Cообщить модератору

	230. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Michael Shigorin (ok), 01-Июл-22, 15:05
	Ага, уже разул глаза, но решил оставить.
	Ответить | Правка | Наверх | Cообщить модератору

	232. "Прогресс в разработке компилятора для языка Rust на базе GCC"	+/–
	Сообщение от Аноним (224), 01-Июл-22, 15:30
	Вообще-то да, правильно подметил такой вариант названия.
	Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема