Это всё-таки не отвечает на мои вопросы (ещё раз): * А

в каком состоянии по вашему мнению Майк Полл забросил разработку?
* И что такое по вашему мнению 10%?

Но я тем не менее как-то попробую ответить.

Во-первых, бетой в 2019 году по-прежнему является ветка 2.1, а 2.0 – stable. Сравнивая 2.1 и LuaVela, я не берусь утверждать, что LuaVela – это bugless code, но я хотя бы могу сказать, что она крутится с 2017 года в боевом окружении, обрабатывая сотни миллиардов запросов ежесуточно (я не преувеличиваю). А про LuaJIT 2.1 у меня проверенной информации нет. При этом, возвращаясь к стабильной ветке 2.0: она просто не умеет работать со всей виртуальной памятью на 64-битной платформе на Линуксах, а LuaVela (как потомок стабильной 2.0) – умеет. Да, 2.1 имеет режим LJ_GC64, но, насколько я помню доклад Питера на митапе в Лондоне (смотрели?), этот режим стабилизировался только к 2017 году.

Далее, не JIT-ом единым живы реализации Lua. Например, ещё хочется эффективно использовать память в бизнес-приложениях. Для этой цели и была добавлена функциональность силинга (о ней см. в анонсе) и DataState (забыл упомянуть об этом, это возможность задёшево разделять read-only данные между несколькими экземплярами VM). В этот момент мы бесплатным бонусом получаем возможность делать какие-то данные иммутабельными (как я рассказывал на докладе в прошлом году, ujit.immutable(_G) спасает нас от проблем опечаток в именах переменных).

Но если мы говорим о JIT-е:

* В LuaVela затащено очень многое из того, что есть в LuaJIT 2.1. Из крупного, что не сделано – trace stitching для "компиляции" вызовов Lua C API;
* В LuaVela есть расширения стандартной бибилиотеки, в которых собраны некоторые полезные на наш взгляд функции общего назначения. Они написаны на C, и многие из них JIT-компилируются;
* В LuaVela появились оптимизации, которые помогают улучшить работу машинного кода при обилии с операциями с памятью (это очень частый случай при скриптовании бизнес-логики, и вот тут оригинальный JIT ведёт себя не очень хорошо – безусловно делая всех в чисто вычислительных задачах).

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

В общем и целом – да, проблема фрагментации, безусловно, есть. Это тот случай, когда сильная сторона языка оборачивается его же слабостью.

Но утверждение про 10% – это выглядит как-то непонятно.

Отвечаю по памяти: Марк решил что не будет тащить инт64 в джит, Марк набросал теорию нового сборщика мусора но не стал его имплементировать, не добавили вроде битовые операции в синтаксис, поддержкой ютф8 занимаются энтузиасты до сих пор

>Но утверждение про 10% – это выглядит как-то непонятно. Это Серёжа. Я его уже много раз бил по рукам за громкие вопли без оснований, и миллиард выводов когда сам не разобрался в теме (наполовину нахватался, наполовину выдумал). Не работает. Видать просто человек такой, но реагировать бесполезно.