Yes, and I think Julia is a perfect starting point for an extremely productive general purpose 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.
There is a common demand from people for extracting just a very concrete computation from a julia codebase and compiling it to a standalone library (or even just using it within an existing julia program, but guaranteeing certain allocation or real time behavior). For example, julia includes a pure julia implementation of libm, but we also maintain the openlibm C library, since we link it into some of our C dependencies that need good quality math functions. It would be nice just to compile the julia version and have it be a drop in replacement for the libm that can be linked. Of course for that you don't want the runtime, or GC or code generator. The challenge here is coming up with the right interfaces and abstractions to make this a feasible and useful thing, without splitting the community into those that care about it and those that don't. We've started some work in this direction, but it isn't really usable yet.
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.
Yes, for sure my suggestion was an incomplete answer, but still you would want the lower language be GC-aware/GC-compatible so I am not sure what the advantages of having two languages would be compared to having a GC language that can have non-GC modules/functions.
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.
