I've met a handful of folks who used it in the .NET Framework days and hadn't kept up with the changes in Core (multi-platform, object-functional hybrid, minimal syntax for console and APIs, etc.).
You no longer need imports, or namespace, class and main method boilerplate to write a basic C# program; there’s now a way to simply write some lines of code in a file with some implicit imports, and compile/run them like it was more of a scripting language.
It's a beginner friendly and "demo mode" set of features to reduce boilerplate for small programs, such that the minimal "hello world" program is literally 1 line of code.
And a working minimal ASP web app with a http endpoint is not much longer.
C# and .NET was from day 1 designed for "programming in the large" so that large codebases can be sensibly organised.
This however causes some overhead, such that a person coming from Python might have looked at the standard C# "hello world" example with using statements, namespace, class and method wrapping the 1-line payload, and conclude that the language is impossibly clunky and cumbersome. My opinion is the opposite; managing e.g. 50K lines of code without those ways of organising code, is going to be impossibly clunky and cumbersome.
However, it is also true that demo mode is great for 1-file demos that get right to the point.
I think the using statements are fine, even for one-file demos. Python, Go and Node don't have implicit imports like C# and it's fine. I'm actually not entirely sold on the implicitness. Forces the reader to look at the .csproj file and the target framework documentation what is implicitly imported.
Most of the verbosity comes from classes and namespaces. Go and Rust have shown it's possible to design a language for "programming in the large" without classes for everything and with less verbose namespaces.
But to be fair, I'm just getting started with C# so my comment above is likely wrong and biased. Happy to be proven wrong :)
C# has several constructs like anonymous types, tuples, named tuples, and records (for structs and classes). Each has different use cases (and sometimes limited scopes like anonymous types) that can serve different contexts for data modelling.
> with less verbose namespaces
This is, once again, the function of the team and not the language. There is no hard mandate on how namespaces are selected so verbose namespaces is a result of teams preferring it over more concise naming. Part of that might be purely practical. Whereas in JS, you would import a local module by path, C# imports via namespace and convention is to use pathing, but C# will of course allow any namespace convention you like for local modules and does not constrain to strict pathing.
> Most of the verbosity comes from classes and namespaces. Go and Rust have shown it's possible to design a language for "programming in the large" without classes for everything and with less verbose namespaces.
The statement that "C# and .NET was from day 1 designed for programming in the large" is true and factual, supported by design documents that pre-date .NET 1.0, i.e. in the late 1990s
The statement that more-lightweight ways have since been developed of approaching the issue is more subjective. But IMHO it is also largely true, as the programming language world has moved on since then. The C# design has been extended a lot, but is constrained by being backwards-compatible. In some ways it is of its time.
e.g. We might not be "entirely sold on implicit usings" but it was a way to get from existing syntax, to a 1-liner
"hello world". I think that global usings are fine, when used very sparingly. e.g. I am happy for a test project to have a global using Xunit because it will be used so widely in the project code. But not many more global usings.
I very much agree with your comment. C# managed to evolve and adopt many “modern” features while maintaining backward compatibility, which is quite impressive.
Having recently joined a company using C#, and with a background using Go, Python, Node, and similar, I was worried about heavy "enterprise-style" APIs. I was happy to discover the new minimal web API while reading .NET Core documentation.