Каковы недостатки ориентации на JVM вместо x86?

Я разрабатываю новый язык. Моя первоначальная цель состояла в том, чтобы скомпилировать исходный x86 для платформы Windows, но теперь я сомневаюсь.

Я видел, что некоторые новые языки нацелены на JVM (наиболее известные Scala и Clojure). Конечно, невозможно легко переносить каждый язык в JVM; это может привести к небольшим изменениям языка и его разработке.

После того, как я задал этот вопрос, я даже больше сомневался в этом решении. Теперь я знаю некоторые аргументы "pro" JVM. Первоначальный вопрос: нацелил ли JVM на хорошую идею при создании компилятора для нового языка?

Обновлен вопрос: Каковы недостатки таргетинга JVM вместо x86 на Windows?

Ответ 1

Ориентация на JVM - довольно проверенный и проверенный подход. Тот факт, что Clojure, Scala, JRuby и многие другие языки сделали это успешно, должны дать вам некоторое подтверждение.

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

Сказав, что основными недостатками, с которыми вы можете столкнуться в отношении JVM, на мой взгляд, являются следующие:

Отсутствие поддержки хвостовой рекурсии на уровне байт-кода. Есть способы обойти это (например, см. Специальную форму Clojure "recur" ), но это раздражает некоторые языковые реализации, особенно функциональные языки. Вероятно, в конечном итоге это будет исправлено в будущих версиях Java.
Немного очевидно, но вам нужен JVM, установленный на вашем клиенте. Обычно в настоящее время это не проблема, но есть случаи, когда это может быть сложно.
Примитивы (int, long, float и т.д.) в Java ведут себя иначе, чем остальная объектная система. Снова вы можете обойти это, но это лишний хлопот для разработчиков языка.

Некоторые потенциально полезные/интересные ссылки:

ASM-анализ байт-кода и структура управления. Это отличный инструмент, Я считаю, что это то, что Clojure использует под капотом.
Clojure исходный код

Ответ 2

Возможно, вам захочется взглянуть на таргетинг на LLVM вместо JVM. LLVM может использоваться для таргетинга на несколько архитектур, включая x86.

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

Ответ 3

Если вы создаете язык для JVM, у вас также есть большое преимущество в том, что огромная библиотека находится у ваших ног, которую можно легко использовать с вашего языка. Скорее всего, это не так, если вы компилируете для x86. Я предполагаю, что вы не сможете включить, например, C-заголовки на вашем языке без C-анализатора.

По этой причине Scala, Groovy и другие - такой успех.

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

Ответ 4

Вы должны нацеливаться только на JVM, если вы счастливы, что часть выполнения во время выполнения вашего кода полностью зависит от стороннего кода и требует, чтобы ваши пользователи устанавливали такие файлы, и JVM предоставит существенные функции, которые вы не можете разумно (например, заголовки ОС на С++), и вы довольны JNI как вашим интерфейсом к собственному коду (и, следовательно, другому управляемому коду, например .NET).

В конечном счете, это полностью зависит от имеющихся у вас ресурсов и того, как вы представляли языковые взаимодействия. Если вы собираетесь использовать JVM для предоставления множества функций, и вы счастливы, что вмешательство будет ужасным, а затем используйте его. Кроме того, я думаю, вы должны пересмотреть.