I'm surprised Microsoft didn't "invent" their own version of Go yet. Actually I'd use it in a heartbeat over Google's if they add generics to it. Just call it "Micro".
The substitution macros aren't that much fun either since they lack certain capabilities (like introducing a new variable into the current scope without having to specify the name redundantly).
Without a lot of external libraries, procedural macros are almost impossible to write in my experience.
Neither of them allows one to properly code onto the type system or replace it and neither is properly supported by the IDEs (or RLS).
The closest thing to this I can think of is Racket. It's supposedly powerful enough to embed Haskell in it https://lexi-lambda.github.io/hackett/
Racket is special because its designers provide dedicated support of language-oriented programming. But that is about ecosystems, not typesystems.
The high-level-variant is a dynamic language with optional typing, which is good for scripting, fast prototyping, fast time-to-market, etc.
The low-level-variant is similar to the high-level-variant (same syntax, same features mostly, same documentation), but it has no garbage collector, typing is mandatory and it runs fast like C/C++/Rust. Compiled packages that are written in the low-level-variant can be used from the high-level-variant with minimal effort or without additional effort at all. The tooling to achieve this comes with the language.
The one major wart with Julia is reliance on GC, I'm interested to hear what workarounds exist. If no common usage patterns rely on the GC, it should be possible to write "recycling" code that doesn't incur GC pauses and hence, unpredictable latency.
I really enjoy using Julia, it's a great balance of concision, expressiveness, and performance.
I think it will also rocket up Julia's popularity and usage not just for ML but as a general purpose language
Is some concept of language support for traits/ interfaces and/or static typing part of this effort?
Also, would there be different levels of leanness for the static compile? I can see some people wanting binaries that use a minimal runtime or GC, but no heavy JIT etc so that a larger set of programs can be distributed but at some tradeoff.
We also have an example of something more similar to what you are asking with Javascript+wasm (or better Typescript+wasm). I think they are both a fertile ground for future growth.
As it stands, it is forced to follow some of Java design mistakes by not integrating modern features and then being forced to actually adopt them in a half-baked way due to market pressure, while striving not to break backwards compatibility with existing code.
Modern C++ also uses GC, even it is opt-in.
And several modern C++ features actually originated in D.
D has the benefit of not being constrained by C copy-paste compatibility like C++.
But yeah, it suffers from having a tiny community.
[0] - https://en.wikipedia.org/wiki/Oberon_(programming_language)
[1] - https://en.wikipedia.org/wiki/Limbo_(programming_language)
And feature bloat.
Modern languages can be bloated.
If Go's design was perfect, its eco-system wouldn't feel like Java 1.0, full with libraries to replicate what should be language features to start with.
The first time I saw "go generate" it was on Borland C++ 2.0 for MS-DOS, released around 1990.
Some of us care about advancing the state of art, instead of being stuck into the ways of the past.
I believe it's still in the roadmap for Go 2.0