Comments 12
Однако, JS и Lua - слишком нишевые языки. JS ассоциируется у всех с вебом а Lua - с разработкой игр. Таким образом, выбор естественным образом пал на Python
Это хорошо, что выбор пал на Python, хоть и противоестественным образом - читать интереснее, но и плохо тоже - выбор кажется мне необоснованным точно, и неудачным с нарушением принципа «по себе людей не судят».
JS никак не нишевый язык, на нём пишется всё кроме системного софта - и фронтенд, и бэкенд, и мобилки, и десктоп. И JS много быстрее Python.
Lua тоже не нишевый язык, на ней Neovim (с которым Lua ассоциируется раньше чем с играми), Roblox и куча всего работает, кроме того, она тоже несколько быстрее Python и надо бы посмотреть на сколько распухает приложение при каждом выборе.
У Lua, JS и Python было ровно одно преимущество - способность обходить W^X политику на мобилках. И один огромный недостаток - отлаживать, причём через задницу, без помощи компилятора (типа пользователь слышал, что если Rust скомпилировался, то работает).
Если мобилки не требуются, то естественный выбор - модуль plugin и Go. Я бы, как представитель пользователей, то есть почти покупатель который всегда прав, такому выбору порадовался.
Если мобилки требуются, то WebAssembly - она тоже обходит W^X политику и не навязывает конкретный язык. Этому выбору я, который всегда прав см. выше почему, тоже очень порадовался бы, а статья получилась бы и того интереснее.
Для меня Go был бы идеальным выбором. Я люблю этот язык. И есть интерпретатор, кстати.
Если выбирать под мой личный вкус из перечисленных, я бы предпочёл JS. Он хоть на Си похож. И опять же, есть интерпретатор, написанный на Go, и в отличии от Питона, никто не будет ждать от него полной совместимости (непонятно с чем, потому что реализаций JS в обороте много, и все разные).
Но что-то мне подсказывает, что встроенный Питон найдёт большее понимание среди широких народных масс. Хоть я и правда его не люблю.
Что до скорости, она в для меня не критична.
Открывая статью, тщетно надеялся я узнать, для чего это всё. Не почему нужен свой вариант, ведь тут достаточно наличия личного интереса (любопытства) и большого количества свободного времени. Просмотрев статью, я не смог ответить на вопрос, для чего, вообще, иметь внутри хорошей, красивой программы на go, или на си++, такой якорь на шее, как какой-нибудь скриптовый язык?
Просмотрев статью, я не смог ответить на вопрос, для чего, вообще, иметь внутри хорошей, красивой программы на go, или на си++, такой якорь на шее, как какой-нибудь скриптовый язык?
Чтобы предоставить пользователю domain-specific language, который не надо отдельно учить.
примеры
откройте блендер и пройдите в консоль и попутно откройте документацию
скриптовые аналоги на движках (какие-то движки с ноукодинг там где открываем вьюшку с формами заполняем и оно компилируется)
функционал
рефлексия, моды, удобные конфигурации пример lua + C/C++ (с/без rttr)
RTTI можно открыть еще почитать (в дополнении почитать rttr для С++)
на просторах ютуба есть пример видео обзор движка сурс-лайк там показывается как это всё вместе работает(ну как пример потомучто реализации могут быть разные в частном случае)
синергия
если смотреть от синергии могут быть вопросы как это конкретно надо реализовывать, тут надо смотреть/тестировать - удобство и прочее
Для тех кому интересна тема использования python from go, можете оценить мой подход https://github.com/yaroher/gopybuf
Спасибо за рекомендацию, но...
Во-первых, мне не очень нравится, что оно привязывается к конкретной версии Питона. Во-вторых, я не очень понимаю, как оно может устойчиво работать: гороутинка может в любой момент сбежать на другую OS thread, Питону это не понравится. В третьих, мне всё же хотелось бы иметь возможность работать с несколькими экземплярами интерпретатора. Ну и наконец, разговаривать самому с собой через protobuf внутри одного процесса как-то очень тяжеловесно, что ли...
Про "тяжеловесно" соглашусь, но тут в игру вступает complexity биндингов, где вам нужно учитывать все возможные преобразования (например slice->tuple) что увеличивает когнитивную нагрузку для разработчика. Есть несколько статей и переводов где люди пытаются подружить rust + go достаточно сложным способом в link time. В общем случае если есть возможность принебречь временем потраченным на сериализацию вызова, то данный подход способен дать доступ к вызову метода в другом языке (python) из основного рантайма с минимальным complexity для продукта/проекта. В вопросе смены os thred'a действительно не было проведено тестирование поведения python, что действительно является минусом приведенной выше библиотеки. А по поводу версии и экземпляров интерпретатора все зависит от задачи, за частую в prod окружении версия будет зафиксирована (т.е. можно собираться только для одной), а количество используемых интерпретаторов ограничено только тем как вы организуете свой код внутри go runtime.
Если вам не нужен полноценный скриптовый язык, а нужно вычислить выражение, проверить правило, сгенерировать структуру, etc., то я бы посоветовал обратить внимание на https://github.com/google/cel-go. Интерпретатор написан на чистом go, неплохо кастомизируется. Крутим в проде больше полугода, полёт нормальный.
Отличная статья и крутые проекты, уважение!
Как привинтить Python к Go