I'm not sure I care about the "run this in a browser" part (unless someone developed a WASM backend for it). And FOSS would be a requirement for me. Given those criteria, I would gladly pay a recurring subscription or donation for such a language.
For what it's worth, there are a lot of good interesting languages out there that aren't Python and have pretty good library ecosystems. Kotlin, Elixir, and Elm come to mind. But they don't exactly fit the Python niche.
What you're describing sounds to me like a modernized Common Lisp with commercial backing. Rework CLOS a bit, clean up some of the other crufty old weirdness, and give me a big selection of high-quality well-supported libraries like Numpy, FastAPI, Trio, etc.
The advantage of doing it in some Common Lisp derivative is that things like React JSX are pretty much "free" and wouldn't much seem out of place, whereas in Javascript they need a whole separate build/compilation step and are often portrayed as black magic fuckery.
edit 1: Arguably Julia could be used for a task like this, but its library ecosystem and language runtime are heavily skewed towards numerical computing and data analysis.
edit 2: Raku also sounds like a possible candidate here, but it obviously lacks widespread adoption and last I heard it fell significantly short of Perl 5 performance. I'm not sure what kind of library ecosystem it has nowadays and I doubt we're going to see big commercially-backed library development efforts for it, soon or ever. Perl 5 has a huge ecosystem of course, but it's such a nasty warty language with nasty warty tooling.
If you like Raku, and the large Perl 5 ecosystem, you might consider going the path of Raku, as it allows 99.9% of the Perl 5 ecosystem to be used as if it is Raku, by installing the Inline::Perl5 module. Once that it done, using a Perl 5 module is as easy as:
I use Clojure for that reason. You can use Python libraries with it as well as Java libraries and JavaScript libraries. Its reach is just phenomenal. And indeed, its React support is amazing.
Right. It clearly doesn't have a strong enough offering at the moment to attract anyone beyond a few early adopters.
> last I heard it fell significantly short of Perl 5 performance
Likewise. I'm pretty sure Perl still roundly trounces it for a lot of operations, especially in regex processing. I think it will need to be significantly faster than Perl before it will have a chance at gaining significantly more adoption.
> I'm not sure what kind of library ecosystem it has nowadays
The raku.land directory has less than a thousand packages and many seem to be jokes, unloved, poorly tested and documented, version 0.x, or even 0.0.x. [0]
The standard library is a different ballgame. It's generally well designed and very large, cutting out the usual blizzard of folk reinventing the wheel for basics. So that's good.
> I doubt we're going to see big commercially-backed library development efforts for it, soon or ever.
I agree.
> Perl 5 has a huge ecosystem of course, but it's such a nasty warty language with nasty warty tooling.
This is where I think Raku's strength lies.
A lot of the effort that went into Raku was to build a platform that could just directly use tooling and libraries of other PLs while insulating developers from their downsides.
That way you get to use Raku tooling, syntax and semantics at the surface level with other PLs' tooling and modules and performance. Kinda like using C code in a non-C PL, but generalized to using code from any other PL in Raku.
The exemplar was supposed to be Perl, but it was also supposed to extend to many other PLs. Starting 7 years ago this became the Inline family.[1]
Inline::Perl is the most mature. Imo it's remarkable. But it was always supposed to just be the first one to get the polish to demonstrate that the approach works and works great. About a year ago the author behind it said it was nearly time to do the same for Python modules. And now I see a GSOC proposal to do that.[2]
The Inlines hide the warts (though you do have to read the modules' documentation to know what their API's are etc).
I think the impact of Inline Python will be huge because it takes away the complaint about reading Perl documentation and code. Instead you read Python API docs but get the benefits of using Raku.
(And, in the wings, there's Inline::Ruby, Inline::Lua, and so on.)
Somewhere I have posted code that uses Inline::Perl, Inline::Python, Inline::Ruby, and I think maybe Inline::Go to convert Base64. (Perhaps other language interfaces as well, I don't quite remember)
While there were some quirks, It worked rather well.
For what it's worth, there are a lot of good interesting languages out there that aren't Python and have pretty good library ecosystems. Kotlin, Elixir, and Elm come to mind. But they don't exactly fit the Python niche.
What you're describing sounds to me like a modernized Common Lisp with commercial backing. Rework CLOS a bit, clean up some of the other crufty old weirdness, and give me a big selection of high-quality well-supported libraries like Numpy, FastAPI, Trio, etc.
The advantage of doing it in some Common Lisp derivative is that things like React JSX are pretty much "free" and wouldn't much seem out of place, whereas in Javascript they need a whole separate build/compilation step and are often portrayed as black magic fuckery.
edit 1: Arguably Julia could be used for a task like this, but its library ecosystem and language runtime are heavily skewed towards numerical computing and data analysis.
edit 2: Raku also sounds like a possible candidate here, but it obviously lacks widespread adoption and last I heard it fell significantly short of Perl 5 performance. I'm not sure what kind of library ecosystem it has nowadays and I doubt we're going to see big commercially-backed library development efforts for it, soon or ever. Perl 5 has a huge ecosystem of course, but it's such a nasty warty language with nasty warty tooling.