[ddragon]

While not nearly as mature as the main platforms (like the JVM, .NET, BEAM), the Julia compiler does have some unique features (an extremely aggressive optimizer, a sophisticated type inference mechanism, possibly the most exceptional multiple dispatch support, Go-like lightweight processes), including a macro system that supports reader macros for writing parsers (like this library) and extensible multi-stage compilation (like the IR manipulation that is used in auto-differentiation of source code), which makes me wonder if once all those features (and possibly new ones) become robust enough it will become one of the targets for people creating new programming languages.

[stabbles]

What you see most is domain-specific languages implemented through macro's. For instance this package, https://jump.dev/JuMP.jl/dev/examples/basic/, https://github.com/SciML/ModelingToolkit.jl or https://turing.ml/dev/docs/using-turing/get-started

[ddragon]

Yes, I was thinking about someone going many step furthers, like Elixir is for Erlang and the BEAM, someone who disagrees with design decisions of the Julia language but appreciates the compiler's capabilities and the ecosystem enough to use them to implement their own vision for a programming language. Making it a Lisp is just one of the more obvious scenarios, as someone may like Julia in general but want the full power of s-expressions.

[rlander]

How is Elixir’s design different from Erlang’s? Semantically they’re pretty much the same language.

A better example would be Java/Clojure.

[ddragon]

Elixir is basically Erlang, just like Lisp Flavored Erlang and Gleam (the statically-checked language for the BEAM). The BEAM in general is a very specialized VM, which is why I used as an example, as the Julia compiler is also a very specialized platform and other languages targeting it would also be just Julia. Like Julia with s-expression, a typescript like extension for Julia that maybe would focus on different tradeoffs by reducing polymorphism in exchange for type checked contracts (but still use the same machinery and ecosystem since it would compile to Julia/Julia IR). I really wouldn't expect something completely different like the JVM supports (as at this point it would be better to use the LLVM directly).

[oxinabox]

Most languages designed to be used by people are not good targets for people creating new languages. Very different set of concerns.

The main ones I am aware of are:

JavaScript: you basically got to if you want to run in a browser.

And C Because it's available on every piece of hardware, it was there before llvm and it doesn't change across hardware (unlike assembly), and most people writing languages know C.

JVM, the .Net CLR etc are not languages. They are intermidate representations like LLVM is. (Approximately). They were designed to be compilation targets. Julia wasn't.

Most of Julia's intersting compiler features are unusual because they need to solve problems Julia has in general other languages wouldn't,or that would not transfer across language boundaries.

The macro stuff is awesome for DSLs. Messing with compiler passed is cool for adding capacities. But I think much more in the sense of implementing a micro language that is closely related to Julia, rather than a full on language that has its own goals and identity (I want to write one for codegolf called Jules that is just Julia except on an error it tries some other lexically nearby code)