I'm not so sure. Both Go and Rust seem like examples of very popular ecosystems with a set of common, "blessed" tooling. (They didn't have everything from the get-go, e.g. rust-analyzer was very popular before it became part of the Rust project, but it still demonstrates that a large ecosystem can rally around a set of common tooling.)

That's a fair point, but I don't think it's really fair to say Gleam has everything necessary included when it's brand new. Because it currently doesn't suffer from the problems of the JS ecosystem doesn't mean it won't in the future.

(As another example besides rust-analyzer, there's also all the Go dependency management tools that existed before native Go modules, e.g. Dep, Glide, Go Package Manager, etc.)

> This is undoubtedly true, although if Gleam ever becomes as popular as JavaScript, there will almost inevitably be the same set of choices to be made for Gleam.

Huh? I don't think so at all, Go and Rust did this same thing (include great and easy to use tooling as part of the language), they are super popular now and the tooling is still great.

Go originally didn't include a great way to manage dependencies. That fortunately got fixed. I think my initial statement of it being inevitable was an exaggeration. My point was that I don't think you can fairly compare a new language with one that has existed for decades as if there's not a chance it will end up having similar problems.