> It's for this reason that nowadays I rarely write my own "new" programming languages from scratch, but rather embed them as DSLs inside existing programming l

> It's for this reason that nowadays I rarely write my own "new" programming languages from scratch, but rather embed them as DSLs inside existing programming languages using macros. This way you get the full ecosystem of the host language for free I don't understand what you mean by this, so I'm hoping you can clarify. What's the advantage of doing this over the alternative way: writing a parser which would compile to code in the host language, or some primitives that you've arranged in the host language that would represent the bytecode of your language interpreter. From there you can leverage whatever in the host language you want, including its type system, packages, language semantics, FFI access to other languages. Really whatever you like. What you're suggesting is leveraging a macro system to help you write what is essentially a parser/compiler, which is a good win. But I don't see what that buys you past that point. If I do things the other way, by writing a parser that consumes a *.my_lang file and compiles it to primitives or actual source code in the host language, I can still leverage all the benefits of the host language just as you describe doing with a macro system. The advantage of doing things this way is you're not limited to languages with tolerable metaprogramming capabilities.