> Which is how Lisps should be implemented on top of modern environments.

Lisps are modern environments. Which is why they're implemented in themselves.

The mapping of the AST onto lisp plus an implementation of macros would solve all the issues with Go verbosity, lack of generics, error handling, and probably much more.

But it would have a lot of braces so junior programmers wouldn't be able to use it and so it's a non starter.

This seems a bit like the story with Clojure vis-a-vis Java, to me. Yes, Clojure does a lot to clean up Java's verbosity, flaky implementation of generics, etc. But I don't think that's actually because Clojure is a Lisp; I think it's mostly because Clojure is a dynamic language. For example, Clojure largely resolves Java's generics situation by simply not needing them in the first place.

That worked for Java, where a lot of people are stuck on the JVM for legacy reasons, but yearning to at least be able to work in a more ergonomic language. Go lives in a different social environment, though. Nobody's stuck on Go because they've got 25 years' worth of massive legacy Go monoliths that they can't just chuck out the door. They're on Go because Go is what they want. And I'm pretty sure, given that they're invested in Go, that a dynamic language with a heavy focus on metaprogramming is approximately the opposite of what they want.

I keep meaning to play with https://github.com/cosmos72/gomacro

You can translate an analogous syntax of your choosing into the same lists =) E.g. something Python-ish or Yaml-ish, or Rebol.

See Hebigo's Python-like approach: https://github.com/gilch/hissp#hebigo

It's a Lisp-flavored Python, Python with Lisp syntax.

Just doing a syntax translation into an AST might not be enough to implement an actual Lisp on another language.

I spent some time with Hy about a year back, and that is approximately the impression I brought away. In order to maintain good interop with Python, they had to make a lot of compromises about how things work in Hy, relative to what a Lisper might expect. The most striking example I can think of offhand is that `let` had to get banished from the standard library: https://github.com/hylang/hy/issues/844

That said, Hy is still a nice language, and very well thought out. It's just that billing it as a lisp dialect for Python (as the project's website does) might lead to some false expectations. That GH thread I linked above is a great example of this. There's a lot of good, careful thought going into the design of the language. But it also has this sentence in the opening comment: "Hy is not Clojure, nor Common Lisp, but homoiconic Python." If you're interested in a Python variant with good macro system, this is it.

(Also, I'm not sure it necessarily disqualifies Hy from being a lisp. There are too many different conflicting opinions about the definition of 'lisp' for me to want to say either way, and, while a lot of good and insightful things have been said on the subject, I've personally always found that particular argument to be rather boring.)

Hy does have a let macro now, but you have to (require) it before it works: https://docs.hylang.org/en/master/api.html#module-hy.contrib...