> Ограничением архитектуры, но уж никак не языка.В сях изначально нет нормальной поддержки разных адресных пространств. Порой по этому поводу что-то придумывают, типа маппинга в виртуальные области с разными адресами и проч, но при этом может ус отклеиться у вон той абстракции.
> Ведь в том же AVR32 вполне возможно запускать код из RAM
Насколько я помню AVR32 - успешно сдох. Нишмог в конкуренцию с армами, ни мк ни апликушники.
>> Где у 32L1 кеш то?
> В 32L5 его добавили для решения этой проблемы.
Это разные классы чипов. И той проблемы - как таковой нет. Кеш делает чип намного более быстрым и намного менее предсказуемым по jitter, что для МК - аргумент.
Более того - в сях штатно нет контроля над кешом и вы никак не можете контролировать запросит ли код I или D из кешированого региона или некешированого. При записи в флеху он, соответственно, поймает якорь. Семантическая корректность при единичной записи будет обеспечена - контролер флехи может запаузить ядро сигналом на шине пока не будет готов отдать ему что оно там хотело. Но времянки будут продолбаны, для управляющих систем это важно.
Одна из причин по которым до сих пор порой для настроек ставят 24Cxx в МКшные штуки, запись туда точно не якорит core, хоть как. Это про потерю управления на энное время.
> А почему нет? Я же делаю. Само собой, на основе ранее скомпиленного
> из языка высокого уровня шаблона.
Потому что в общем случае мои цели страшно далеки от написания компиляторов. Для меня они лишь инструмент в решении совсем иных проблем. В каких-то случаях типа импактящего меня бага я конечно могу попытаться включиться в процесс, если остальные совсем не могут, ибо опенсорс это вот так. Но в общем случае лучше если этим займутся более тематичные люди.
> А как тогда делать рефлексию, динамически формируя оптимальный код для
> изменившихся метаданных?
С небольшой потерей оптимальности - наверное нечто такое можно изобразить указателем на функцию. И в принципе даже сгенерить кастомный вариант в RAM и на него указатель поставить.
Но Кента с вот этим - послали из ядра, он там пытался код генерить. Пришлось урезать осетра. И были правы. Ибо W^X violation и вообще, "premature optimization is a root of all evil" (c).
> Когда таких данных сотни миллионов сообщений в сутки, рефлексия дает очень
> заметный выигрыш.
Линух без всего этого ворочает еще и не столько пакетов интернета запросто. Значит серебряные пули несколько переоценены...
> Компиляция в Rust весьма тяжелая.
Ну вот тут фиг поспоришь. Анализ видимо навороченный получается. Но и результат по своему приколен, нет оверхеда VM и рантайм проверок, а некие гарантии выживают. И well defined behavior. При всей хайповости, несколько вещей они сделали правильно.
> А вызов динамически скомпилированного кода - вообще целое приключение в unsafe.
Зато unsafe код явно маркирован как именно это. И знаешь откуда ждать проблем. Это как раз очень хорошо придумано имхо. С одной стороны - можно, если нужно. С другой - видно откуда ждать проблем.
> Чтобы не останавливать продуктивную систему для того, чтобы пересобирать и деплоить сотню
> сервисов из-за изменившихся метаданных.
Ну так компилят обычно на билдферме, а продакшн так то обычно умеет в graceful upgrade, при том нечто сравнимое даже нжинкс умел еще когда там.
> Например, protobuf в Kafka или gRPC можно парсить динамически, но это очень
> медленно. А можно скомпилировать обработчики для схем, что ускорит обработку
> почти на порядок. И тут выбор. Или компилировать в CI/CD, что заметно снижает
> доступность системы, или компилировать на лету, как только сервис обнаруживает
> сообщение с новой схемой или новой версией схемы.
Какие-то проблемы из ниоткуда. Не понимаю в чем трабл сбилдить на билдферме и плавно апгрейдить. Разве что если архитектура дно и так не предусмотрено было.
>> Однако универсальность тула - это его очень крутое достоинство.
> Ассемблер еще более универсальней.
По этому поводу до сих пор имеет определенное хождение. Не, вы точно не хотите увидеть с какой скоростью работает вон тот видеокодек в его сишной версии. Особенно если это современный кодек.
> По моему опыту, универсальным швейцарским ножом пользуешься
> намного реже, чем ответркой, строительным ножом, консервным ножом, ножницами и т.п.
У меня отвертка и шуруповерт с сменными битами (догадайтесь почему) а ножницам не так уж важно буду я ткань резать, бумагу, или даже фольгу какую.
> Потому что специализированный инструмент удобней и работать им продуктивней.
А я то как баклан меняю биты в отвертке и шуруповерте... Если на кажлый размер Torx, Philips, Pozidriv, hex и slot взять по нескольку размеров, клад отверток вырисовывается. И это я еще pentalobe и что там еще более экзотичное не вспоминал, только повседневное.
> А на данный момент, имеем грандиозную иерархию классов в .Net.Core, на которой
> базируется Office 365 и не имеем возможности ее просто конвертировать в Rust,
А оно и не надо - надо функциональность переписать. А не всенепременно закрутить гвоздь отверткой с аргументом "это любимый инструмент". На мой вкус делать веб дотнетом это еще хуже чем крутить гвоздь отверткой. Выглядит как-то так же.
> так как её идеология наследования в Rust не поддерживается. Необходимо
> разрабатывать свою систему структур, типажей и макросов для создания чего-то подобного.
Вообще-то если именно такая нужда возникает - значит архитект жесточайше облажался еще на фазе архитектинга. И его тем более надо выпереть ASAP - и заменить этого спагетти монстра нафиг.
Или к вопросу почему веб сейчас часто юзает "микросервисы". А вот чтоб с такими спагетти-монстрами дела не иметь. Мелкие гранулярные штуки проще адаптировать и намного меньше implementation constraints высосаных из пальца, типа вот этого вот бреда - для меня когда я вижу такие заявы, я понимаю насколько именно господа не умели в архитектуру продукта. Т.е. - вообще совсем. Увольте вашего архитекта: он не знал что делает и круто подставил вас.
> Там проблемы те же самые, что и в любом языке с GC
По этой причине хруст получает уникальный пойнт в нагруженном проде. Сюрприз!
> Ну и следует понимать, когда лучше использовать среду с JIT (CLR, JVM,
> V8), а когда лучше компиляцию в машинный код.
Для меня ответ по сути - "никогда". Ну может кроме JS, в фронтэнде.
> Лично я против Rust ничего не имею. Сам использую plrust на PostgreSQL.
Я просто не понимаю зачем надо дотнет если уже есть хруст. Абстракции ради абстракций не нужны, нужно - решение задачи, нормальная архитектура, и если все приходит к вон тому - я понимаю что с этим вышел EPIC FAIL.
У нормалных людей - да всем вообще ср@ть на чем микросервис написан. И так сильно проще постепенно менять это - без ломового отвала башки. А у дотнетчиков обычно получается страшенный макаронный монстр которого тронуть страшно. Потому и - переписать. С увольнением вон тех и архитекта за такую подставу нанимателю. Хреново когда в каком-то решении сложно переиграть решения. Это не достоинство дизайна.
> что на C можно напрямую работать со страницами PostgreSQL, что на
> Rust слишком сложно и все равно unsafe.
Rust вероятно задолбает в этом качестве.
> А gRPC сервис, продьюсер или консьюмер к Kafka и т.п. - как раз задача для C#.
Я от всего этого к счастью страшно далек.
> Надо уметь его готовить. Естественно, если нахреначить в каждом методе сотню переменных
> не в стеке - GC под нагрузкой не будет успевать их
Ну, кому надо - тот пусть и. А у меня нет желания греть мозг вот этой дрянью. Это анти-технологично и костыльно по максимуму. Особенно когда в новой версии могут логику изменить по желанию левой пятки, без предупреждения - и я таки видел что в результате получается! Еще вчера все было ЗБС. Сегодня кастомеры осадили саппорт, охренев от жора памяти. А весь офис жестко хардкорит в овертайм и выхи чтобы придумать хоть что-нибудь, соответственно.
> и для каждой задачи следует подбирать свой инструмент.
Я думаю что хруст сможет в дофига задач дотнета сунуть свой нос - и не обломается. И энное количество нетчиков таки будет заменено и выписано в легаси. Со всеми своими "незаменимыми" абстракциями. Незаменимых не бывает, а для корпорации незаменимые решения это вообще злейший враг и прострел пяток.
