Покрывают ли макросы Rust возможности #define?

Ну вообще-то нет, я же написал «допустим». Я хочу перевести программу с Си на Оберон, и больше всего этому мешают макросы. Соответственно, нужно разработать такие макросы для Оберона, чтобы было удобно переводить. Какие-то я уже разработал, а #ifdef там и так уже присутствует. Но всё равно пока непонятно, что делать, т.к. другой порядок слов. Я надеялся, что в расте решали задачу о переписывании, но похоже, что нет. Иначе была бы готовая методичка, как мигрировать с Си на Раст, и такие случаи были бы в ней разобраны. Но может быть, она и есть, просто пока что мне не попалась. Кстати, порядок слов в определении переменной в Расте тоже правильный - как в Обероне, а не неправильный - как в Си.

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

То, что на Си как два пальца об асфальт, как связный список, на Расте как каменный цветок родить. Вот и думай.

Я думал, что в Расте пошли именно этим путём, но нет.

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

В контексте языка, который ценен своими ограничениями, в этом мало смысла.

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

То, что на Си как два пальца об асфальт, как связный список, на Расте как каменный цветок родить. Вот и думай.

НДА. Так-то конечно связный список естественным образом порождает гонки. Надо заводить новую тему.

То, что на Си как два пальца об асфальт, как связный список, на Расте как каменный цветок родить. Вот и думай.

НДА. Так-то конечно связный список естественным образом порождает гонки. Надо заводить новую тему

Меня больше поражает, что стандартная либа в Rust застряла где-то на уровне 80-х годов, то есть, однопоточные контейнеры под блокировками, для которых даже связанный список уже «гонки, низзя». Даже сейчас, когда я пишу на крестах за денюжку, меня вообще не тянет штудировать STL, потому что STL — по большей части засохшее говнище из каменного века, а хэш-таблица пишется за день. При этом за два дня хэш-таблицу можно сделать многопоточно, а контейнеры STL расширить невозможно. Хотя бы привязать группу контейнеров к экземпляру аллокатора ты не можешь, только весь тип можно привязать. Ту же ошибку успешно повторяет Rust. Это только одна из ошибок, бездумно скопированных разрабами Rust из C++.

Приходи в новую тему, Rust и двусвязный список

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

Может, надо тогда написать вместо конверетера с Си конвертер с раста…

А какая у тебя цель вообще? Переводить произвольные программы на оберон?..

Меня больше поражает, что стандартная либа в Rust застряла где-то на уровне 80-х годов…

А в каких «современных» языках иначе? Swift? Kotlin? Что-нибудь ещё? Мне кажется, что то, что ты хочешь везде будет в сторонних библиотеках.

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

А в каких «современных» языках иначе? Swift? Kotlin? Что-нибудь ещё? Мне кажется, что то, что ты хочешь везде будет в сторонних библиотеках

Go, Clojure. Да, Swift и Котлин тоже застряли, потому что больше упора делали на совместимость с Си и Java соответственно.

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

Там гвоздями приколочены Send/Sync, которые подразумевают блокировочную модель многозадачности из 80-х — это уже никакими сторонними либами не исправишь.

Go

Вот я загуглил и обнаружил такое:

Before Golang 1.6, concurrent read is OK, concurrent write is not OK, but write and concurrent read is OK. Since Golang 1.6, map cannot be read when it’s being written.

Это правда лучше?.. Причём если тебе не нужна синхронизация внутри контейнера - ты всё равно её получаешь.

Там гвоздями приколочены Send/Sync

Очевидно, ты не понимаешь как работают Send и Sync.

Цель - откуда-нибудь надыбать готовых и качественных программ для Оберона, чтобы их не писать. Не с произвольных языокв. Сейчас основная задача - добавить мяса к ЯОС. Это, в основном, касается сети и драйверов. Нужно выбрать один хороший язык-донор и наладить технологию перевода с этого языка. Я сначала думал, что это будет Си. Но теперь думаю, что Раст, видимо, лучше. Из того, что я про него намедни узнал, он мне не нравится. Однако, если программа уже готова, то чудачества языка-донора имеют мало значения. Уж лучше чудачества Раста, чем чудачества Си. Так-то по идее голанг наиболее близок к оберону из популярных языков, за ним Дельфи. Но это не те языки, на которых принято писать системный софт, поэтому из них для ОС много не наберёшь.