Раст — вполне пристойная замена сишки, особенно ещё лет через десять когда окончательно стабилизируется. Примерно как D, например.

в машинном языке машинные слова

лучше просто молчать и ничего не писать

Справедливости ради, в правильно сконструированном языке компилятор действительно массу проблем снимает. У Луа просто изначальная заточка была под относительно небольшие задачи, где можно всё в голове удержать.

Ну правильно, учим машинные слова под каждую архитектуру и набиваем в хекс-редакторе, кто так не умеет — нипрограммист и вообще нечего его к коду подпускать )

А тут ещё прикол в том, что если твою задачу не получается удержать в голове — самое время её декомпозировать, вне зависимости от языка, а то начинается: "ООП не нужно потому что все вокруг только и делают что наследуют по десять тысяч раз, и это в голове не помещается" и "DOD не нужно потому что всё вокруг плодится на миллиард подсистем которые в голове не помещаются, и я хз где оно первым загоняется а где перезаписывается, и вообще дублей дофига, а ещё я не заметил как перекрыл подсистемы и они теперь коллидируют и конфликтуют, и я хз какие и с кем".

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

Правда, это не очень вяжется с бизнесом и командами разработки, которым абстракции подавай и сам на чужих абстракциях строй ))

К сожалению, при прочих равных декомпозиция только увеличивает общую сложность системы. Ну там, второе начало термодинамики, вот это вот всё :) И тут статика приходится очень ко двору, потому что позволяет часть сложности спихнуть на железку.

Декомпозируй так, чтобы упростить ))

По отдельности - да, каждый кусочек будет проще. Вместе... энтропия не убывает, сволочь такая ;)

Хе, некоторые вещи напротив весьма эффективно композировать. Например длинная портянка основного цикла, бизнес-логические блоки и минимальные функции. Ну типа, чтобы проще было находить аналогии в реальной жизни.

А потом ведь неизбежно наступает момент рекомпозиции. Это мне сильно напоминает анекдот про студента, сессию и чёрта с мешком гвоздей.

Т.е. сама возможность вынести хотя бы часть сложности на аутсорс компилятору иногда бесценна.

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

Чего именно не хватает в Teal?

Я не так давно пытался запилить байндинги для Teal апи движка Defold, нагородил костылей и так и не доделал. Уже смутно помню все проблемы. Например, для того, чтобы определения байндингов были топ-левел, обязательно нужно иметь tlconfig.lua. Юнион типов можно иметь только из примитивных типов, нельзя сделать юнион с рекордами или контейнерами. Что-то может еще было, но это то, что запомнилось.

С API Дефолда я не знаком😞, не могу предположить какие там подводные камни. API Love2d переведено практически полностью и работает. Также работает типизированный биндинг ImGui. Мне не хватает в своих проектах наследования интерфейсов(записей). И рабочего дополнения для редактора(neovim). Сам проект задумывался для создания не только тайпчекера, но и продвинутого тулинга основанного на статическом анализе типов. Писать на чистом Луа после Бирюзового уже не хочется, не хватает строгости и документированности кода. В целом мне нравится подход Хишама, он не добавляет все фичи подряд, тщательно взвешивает новую функциональность.

Ещё я видел попытки переписать функциональную библиотеку luafun с типами. Не знаю, достиг автор успеха или забросил. Но к таким библиотекам очень нужно умное дополнение и всплывающие подсказки с сигнатурами типов.

Ну расширение VSCode для Teal работает весьма неплохо, код комплитит, ошибки подчеркивает до компиляции.

Кстати, есть Haxe, который тоже неплохо компилит в Lua и имеет хороший тулинг. Но он жирноватые Lua сорсы генерирует.