> Ну, технически отладка - это дело решаемое, тулзы с библиотеками Знаешь, теоретически - много чего решаемо. А практически - это кто-то должен сделать.
Можно написать отладчик? Да. Только посмотри сколько ресурсов на это в нормальном виде реально надо. Вон в LLVM народа поболее чем у некоторых, а нормальный отладчик за несколько лет так и не сделали. При том такая фигня при отсутствии нормальной оси - вообще с АБСОЛЮТНО ВСЕМ. Сферическое приложение в вакууме - это круто, концептуально и ... не от мира сего.
Так, очевидное: стоит сервачок. Он в основном HTTP, но еще он синкает файлы по rsync. Несколько гигов потенциально. И задержка не более 5 минут. Ну так надо. В этом конкретном случае. Любой человек в здравом уме в general purpose оси просто пропишет рсинк в крон. Дешево и сердито, занимает 5 минут времени. А потом просто работает. А на такой конструкции - ОПАНЬКИ!
> (в том числе и отладка-логирование) один раз пишутся и отлаживаются, в конце концов.
Вот только это кто-то должен сделать. А чтобы это было в нормальном виде, на это надо вбухать уйму ресурсов. В general purpose осях - все это делали исторически, за многие годы, между делом, под нужды разработчиков и юзерей. А сейчас мы можем прийти и за 5 минут опереться на плечи гигантов. Которые до нас написали cron, rsync и что там еще. И вместо борьбы с искусственными сложностями - заняться решением своей задачи. А не написанием себе логгера с замашкми трассира, подрыва писать свою реализацию протокола rsync на ocaml и что там еще.
Я уж не говорю о том что схватиться за единственный малопопулярный ЯП, принципиально обув себя на все остальные ЯП и наработки под них - это фееричный прострел пяток и залет на туеву хучу работы на ровном месте. Там где можно было бы сто раз взять готовые либы, программы и скрипты - придется пыхтеть самому.
> сколько занимает код. Потому что данные, которые он будет лопатить, занимают
> в памяти минимум на пару порядков больше обычно.
Это конечно варьируется. Но в целом такие конструкции оказались совершенно не от мира сего.
> да, как только захочется странного - это странное обойдётся дорого.
Более того, в 95% случаев придется делать козью морду и с позором объявить что задача "не решается" [вами, за разумное время и деньги, с этой технологией]. Под гомерический гогот скриптокидозников, показывающих внезапно обломившемуся им клиенту как это сделать за 5 минут и даже без программирования.
> В-четвёртых - они там всерьёз, скажем, FS сами реализовывать будут?
В таких вещах ФС как таковой может и не быть. Будет какое-нить апи к базе, например. Мелкомякоть как-то так и хотели. Реально оказался адов гемор на ровном месте, разумеется, и все труба шатали такую мегаконцептуальщину.
> Что за чушь насчёт "отсутствия ядра и драйверов"
Имеется в виду что в контейнере с ОС-паразитом нет большинства драйверов и ядро может быть урезанное, т.е. чисто прослойка для работы с гипервизором.
Но реально кучу лишних дров можно оборвать и у general purpose, если это так принципиально. Это и под реальное железо то делают, там где место жмет. Ну вон опенвртшники в 4 мега упаковываются, при том половина из этого - как раз программы рисующие вебморду, ну и всякая логика вокруг типа фаера, роутинга и обвязки всего этого. Но реально плюс-минус пара мегабайтов на обычной VM в более-менее типовых условиях - никого не парит. И хардкорно плясать с бубном чтобы откусить от виртуалки несколько мегов - в целом довольно странное начинание. Ну то-есть пытаются делать поменьше и полегче, но лишь до тех пор пока это не начинает требовать много времени и факапить то для чего виртуалки поставили.
