On pure pragmatic grounds, it's really difficult to justify any of these new languages when you compare the tooling and support of those that have either been around longer or have company/institutional support.

Yeah. That's why I talk about it. I want people to build good IDE support for Nim :)

Nim has been on a steady path of improving tooling support[0] since 2.0 release.

LSP is a lot more stable now than even a couple months ago.

That's what I love from community-driven languages: while BDFL isn't very passionate about tooling, people have spoken and gears are turning to improve it[1].

It also helps that there is a company around (Status) that's using Nim in production and wants to invest money and dev-time[2] in the language.

- [0] https://github.com/nim-lang/RFCs/issues/544

- [1] https://forum.nim-lang.org/t/10959

- [2] https://forum.nim-lang.org/t/10762

Nice, I'll have to check it out again this year. Might be a good chance to look into Helix, too.

That's why Go is actually perfect. Tooling works great and compile times are super fast. Language is super simple.

Go indeed makes it hard to justify languages like Nim.

I'm kinda scared I'll like Go so much and then my Java knowledge will quickly decay x)

on the other hand, the "Jai" beta is quite good in this regard.

I think this is not just a problem with ecosystems, but a consequence of the language design itself. Zig and Nim have extensive meta programming language facilities that making good autocompletion support is a very hard problem, while Java doesn't have such a complicated language design. (The problem with Java though is that it's instead hard to use without an IDE since there's too much boilerplate because of its spartan design).