Yes the big stdlib is the secret sauce. c# is great but the framework offers so much. Imagine taking a non trivial 5 year old javascript project and upgrading it .. but with .NET that is well written to use the framework features it's often quite achievable. I've upgraded a number recently and mostly it's been quick and successful. Because of the sensible stdlib!

I’m excited about Blazor and compiling dotnet to WebAssembly. There are some newer Blazor libraries built with the goal of having {no|minimal} JavaScript being written by application and web developers.

Of course, there’s lots of room to grow towards that goal.

To the contrary, I think it makes the code easier to understand. The syntactic sugar that gets added to C# is almost universally driven through studying extant usage and codifying common patterns. Instead of jumping through flaming hoops of boilerplate code to make, say, asynchronous network requests work, there is now a specific syntax for sequencing asynchronous calls that keeps related code more closely related in the source.

Specific syntax for patterns makes intention more clear, and shifts responsibility for getting it right from the developer to the compiler.

I'm with you on the terseness. I've been finding myself asking people to be "clear, not clever" with usage of some of the sugar, whereas previously adopting new syntax hasn't been so much of a challenge. It's definitely a balancing act between being easy to read and causing the reader to have to context switch while reading. Most of the sugar in C# hits all the right spots though.

I have no doubt that some of this newer syntax is clever, and very welcome to many, but not everyone will realize that it's far more beneficial in the long term to cater to the common denominator.

I think everyone just has to accept that

if (expression is {} val)

Is the right way to code, even if it looks ugly.

> C# to add loads and loads of syntactic sugar

well some is necessary. example: init-only-Setter, was impossible to do before. You could not write the same Code, without it. No matter what you did.

using declarations where also necessary to increase readability.

and nullable reference types also were important!

You could use an explicit private readonly field and a property getter, or even just a public readonly field. I would argue its only sugar.

Are you referring to the init only setters?

If so, it isn’t just sugar, they added a new hook for it in the internals, rather than just relabelling a technique to accomplish a similar (but not equal) end.

It doesn't scale that well, as you need ctor parameters for every property, so API additions may also be breaking changes.

well that would be different to instantiate tough. it would be Class(1, 2, 3) instead of Class { Value1=1, Value2=2, Value3=3, }

actually record types are more syntactic sugar around what you said than initonly, which opens up a new way of writing code

A great deal of the “loads and loads of syntactic sugar” serves the purposes of making C# more functional-friendly. You might explore the new features from that paradigm, to help you reason about it.

Do you have any pointers on a gentle introduction to docker and kubernetes in the .net world? Most of the docs seem to be tuned to Linux ecosystems... which makes sense given the heritage.

I’d recommend embracing it: the Microsoft Linux .NET containers are solid. It’s not that hard writing .NET code on Windows and deploying to Linux containers.

I work for a large Unnamed Parcel Service, we've got a ton of legacy applications on pretty much every platform you could name from the last 50 years. But all our new application are .Net Core in Linux containers running on Azure Kubernetes Service.

I'm really only using it on Linux. VS and VSCode (with the Docker and .NET plugins) can generate docker files with one click/command for .NET projects, which also use the right dlls from your project as entrypoints, etc.

From that it's just standard Docker - it doesn't matter that you are running .NET core in it really. You can do anything you could normally in Docker and K8S.