> in practice, all the complexity of C# building disappears into Visual Studio
IMO, that's even worse.
It means that when you want to learn C#, you're also forced into learning a complicated tool that isn't really useful for much else.
At least when I'm learning Rust or Typescript, I can keep using my existing editor.
> A lot of people seem to think that the overall size and "complexity" of the language (and only the language) matters? Personally I don't think it matters how long the spec is if you and your team aren't using those features.
That works until you have to use code that does use those features.
> The ecosystem matters more. "What should I use to write a GUI in C#?" is a complicated question with tradeoffs, but none of them have anything to do with the language per se.
That's fair. At least to an extent.
The further you stray from the ecosystem's intended use cases, the more you have to depend on the quality of the language itself. Thankfully, for mature, mainstream languages like C#, there are a lot of things you can do before that point.
> in practice, all the complexity of C# building disappears into Visual Studio
> IMO, that's even worse.
To be fair, the more accurate way to phrase it is "disappears into .NET tooling". Because this part is also exposed through standard CLI of .NET, and isn't Visual Studio specific. Managing packages through npm and dotnet is quite similar, with a significant difference that the average dependency graph of a .NET application or a package is 10 to 100 times smaller than the one of Nodejs, and the compatibility breaks happen much, much more rarely.
> It means that when you want to learn C#, you're also forced into learning a complicated tool that isn't really useful for much else.
This is untrue. On top of Visual Studio, your choices are Rider, VS Code and VSCodium, Neovim and Emacs, and anything else that integrates through VSC extension bridges, LSP and debugger adapter protocols.
I also usually recommend to all newcomers to start with CLI to manage projects and packages, because it's more straightforward than navigating through all sorts of windows in an IDE, and because they also get know the basics .NET builds on top of. It's an experience that is very similar to using Cargo.
IMO, that's even worse.
It means that when you want to learn C#, you're also forced into learning a complicated tool that isn't really useful for much else.
At least when I'm learning Rust or Typescript, I can keep using my existing editor.
> A lot of people seem to think that the overall size and "complexity" of the language (and only the language) matters? Personally I don't think it matters how long the spec is if you and your team aren't using those features.
That works until you have to use code that does use those features.
> The ecosystem matters more. "What should I use to write a GUI in C#?" is a complicated question with tradeoffs, but none of them have anything to do with the language per se.
That's fair. At least to an extent.
The further you stray from the ecosystem's intended use cases, the more you have to depend on the quality of the language itself. Thankfully, for mature, mainstream languages like C#, there are a lot of things you can do before that point.