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

А хвалёная безопасность Астра Линукса

Основана на сертификации и выполнении ряда требований законодательства.

А зачем?

Что делать с многомегабайтной россыпью дебаг информации (именования объектов, сохранение костеков на некоторых операциях, россыпь валидаций), которая нужна в дебаге, но не нужна в релизе?

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

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

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

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

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

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

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

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

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

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

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

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

Иметь что-то более удобное, чем bash, когда надо накидать автоматизацию «на коленке»? Люди используют язык не по назначению, но виноват язык, ага.

Иметь что-то более удобное, чем bash, когда надо накидать автоматизацию «на коленке»? Люди используют язык не по назначению, но виноват язык, ага

Проблема в том, что даже баш поддерживает многозадачность, а питон — нет. Если ты хочешь многозадачность на питоне, то это Popen, который по сути более сложный вариант баша, либо multiprocessing, который настолько убог, что им почти никто не пользуется, предпочитая специализированные готовые решения.

Это не проблема совершенно. Вся многозадачность на питоне, которая нужна, прекрасно покрывается модулем threading. Потому что питон - для администрирования, ему надо ждать IO, а не CPU (числа дробить питоне не умеет и не должен). И в этом плане его «неподдерживаемая многозадачность» работает отлично.

#ifdef YES

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

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.

Мы такое с помощью features делали.

Хорошо, внутрь не заглядывал, но по идее оно так и должно называться.

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