Hacker News Reader

Comment by pelagicAustral | Hacker News Reader

I just turn my head to look at my bookshelf, and sure enough, there it is, my C# 6.0 & .NET Framework 4.6 book. That was the last version I worked.

Nice to read about all the changes in C#, I've been thinking a lot about going back to .NET, but at this point I would probably need some training. There are things like Blazor or .NET Core that I'm absolutely unfamiliar with.

I kind of miss Visual Studio for some reason, after what feels like a lifetime of web development in other open source tech stacks.

View on HN

I’m perhaps in a similar camp, years of experience during the .NET 4 era, a lot of TypeScript and Rust after that.

Recently, I went back to C# for a smaller project. The .NET ecosystem certainly has its advantages compared to the “wild west” of NPM, which includes Visual Studio/JetBrains Rider.

My main problem was that the language feels so dated at this point. Why can’t I make local variables immutable? Why are there still no algebraic types? Why do the new nullability rules feel so inconsistent and tacked on, with “String?” and “DateTime?” behaving completely differently?

I realize not everybody cares about these “modern” features as much as I do, but once you’ve wired your brain to think about program composition in a way that simply feels better to you, it’s very frustrating to go “back”.

Edit: It’s not like the C# team is unaware of or in any way against these proposals. There just seems to be little visible progress:

Algebraic types: https://github.com/dotnet/csharplang/issues/113

Const locals: https://github.com/dotnet/csharplang/issues/188

>Why can’t I make local variables immutable?

How it'd work in such a case:

You declare immutable variable "a" which's an instance of a class

and then you execute "DoSomething" method which mutates under the hood?

Compilation error? runtime error?

Anyway have you tried records?

I’d be fine with semantics similar to readonly fields (and incidentally, “const” in JavaScript): you can’t reassign the variable, but the contained object can do what it wants.

To your last question: Yes, records are really nice syntactic sugar for classes that want to behave like values.

It's usually on a syntactical level, to disable reassigning a value. For objects this means the reference is still mutable, value types are locked.

Js has const, C has const, Java final.

Imho it'd be awesome if mutability were not the default and we would have to mark mutability, but until then any variable that doesn't need it, is final. Which also helps skimming code

>Js has const, C has const, Java final.

C# has readonly and const

>Imho it'd be awesome if mutability were not the default

If they decided one day that - "let's make immutable by default", then it'd be performance hit - wouldn't it?

> If they decided one day that - "let's make immutable by default", then it'd be performance hit - wouldn't it?

Not really. It's just a syntactic default, reassigning local variables should be discouraged from except for iterators etc. It just fosters bad habits.

For example, A list can still be mutated like usual, the reference however may not change. This usually allows compilers to do optimizations in multithreaded situations. But that's not why I code that way, it reduces the cognitive burden of keeping track which variables are actual moving parts as opposed to context/names etc.

> C# has readonly and const

Haven't written C# in a few years, GP was talking about variables as far as I can tell and their lack of immutability.

C# does not (as far as I know) have readonly or const for local variables, only to fields. You can even have consts inside method bodies, but they are only actual compile-time constants.

codeflo means to declare a local variable that cannot be reassigned later.

    void Foo() {
        // this is possible in C# today, but only for compile-time constants
        const int Bar = 42;

        // this is what codeflo wants: variables that cannot be changed after declaration, but can hold runtime values
        readonly string text = $"Blah: {Bar + System.Environment.ProcessorCount}";

        // with such a variable, you wouldn't be able to reassign it later:
        text = "Some other text";
        // the line above would be a compile-time error, just like trying to reassign to a readonly field.
    }

I am sure you have heard this before, but F# sounds like it would be right up your alley. It has sane defaults (non-nullability, algebraic data types, etc.) while still targeting the CLR, enabling the usage of any normal C#/.NET library to be used within your application. Granted, there's _some_ friction going between C# and F#, but that is a small price to pay (IMO).

For me, another gripe is: “Why do I have to manage a csproj file?”

That’s one of the things that tangibly improved IMO: they removed the file list, so except still being ugly XML, the csproj is now very comparable to package.json or Cargo.toml.

A lot… A LOT better than package.json…

And can be edited without unloading the project first.

Better in what sense? Syntax aside, I don’t see a substantial difference in terms of file content. I do see a substantial difference in terms of tool capabilities (like .NET/NuGet’s inability to resolve conflicting diamond dependencies).

As much as I'm not a fan of the XML based project files, the csproj format is much more flexible/capable than package.json files. For example, you may want to have different versions of a package reference based on some condition. Would it be better w/JSON than XML? I think it's a toss-up.

That’s a good point. Rust’s cargo files have that feature as well. And I agree that surface syntax isn’t the main issue.

Lack of comment is a serious flaw for package.json syntax.

Csproj is one of the better build config setups, I'd say. In practice, the IDE handles it all if you want. What would you prefer instead?

csproj is fine these days. sln on the other hand...

Fun thing is the current explaination regards readonly locals: https://github.com/dotnet/csharplang/issues/188#issuecomment...

It is basically: if we introduce it, it gives us a tiny benefit for a gigantic amount of noise during every single code review. It boils down to comparing developer productivity vs. language safety.

I find the argument a bit weak since code review guidelines can end this conversation AND C# has already quite some code analysis code fixes to auto-fix language usage stuff (like file scoped namespaces or nullability checks). And that case of const and readonly can be algorithmically checked.

It does seem like a weak argument when it can be enforced/fixed by linters e.g. this is already solved in JS with eslint prefer-const rule

I suppose you can emulate it today with variable prefixes/suffixes and check the AST with a custom linter yourself

Especially since its not really a language safety feature. As a reader of code I much prefer knowing what I need to pay much attention and what not. As a writer I want to be reminded when I promised myself to not touch a variable.

Some of the comments in that thread must come from people who are lucky enough to have never had to read or refactor any large, convoluted methods. Knowing that this particular bool flag isn’t being flipped thrice, 100 lines down, is a godsend.

That is indeed a problem every once in a while. These people develop a framework and 3 languages. They do not built large systems.

But there are other groups at Microsoft which keep them on track with their real needs.

It’s pretty easy to pick back up and get in the swing of things - and very fun too. Lambda expressions and async programming might take the most study and practice to really feel comfortable using. Blazor server side is a new but very accessible paradigm, particularly with free component libraries like Radzen and MudBlazor. Dapper helps as an alternative for those not willing to go full EF for data access. Visual Studio 2022 is a nice, refreshingly automated environment. Azure has a ton of ridiculously fun tools like devops, key vault, functions, app service, etc.

Echoing the sentiment, I was a visual studio user for the best part of a decade, until Rider appeared on the scene. Rider/intellij is the new bar for developer tools today IMO.

but why?

I'm asking because I do use extensions like Roslynator for refactorings I'm not sure what I'm missing, what fancy Rider has?

Rider has all of ReSharper but without the performance hit that you get in VS + ReSharper.

Ok, but I've been talking about Roslynator (free refactoring extensions), not Resharper

I haven't tried Roslynator (since I stopped using VS years ago), and to be fair you said "extensions like Roslynator". Just trying to give a bit of an elevator pitch for Rider. The analyzers in Roslynator would definitely still work in Rider (that's just a Roslyn compiler feature), but not any extension-only refactorings, that's correct.

Caveat: I'm writing C++, not C# but, Rider does out of the box what I used extensions for for the best part of my time working in Rider to start with. The IDE is faster to start up, faster to use, the tooling works better than the visual studio tooling, the licensing is sane, the source control integration is an order of magnitude better than VS's. The code completion for intellij tools is what you'd expect, for VS it's... varied depending on whether or not VS has parsed your project yet (and good luck figuring out when that is).

Code formatting tool support was substantially better (although still not ideal) in rider than VS, and VCS backed project settings mean that we can have developers auto format locally rather than building out tooling to enforce it.

Cross platform support, with remote editing is also a huge one for me. I have a windows workstation and a Mac as a secondary workstation. Before, I had to remote into the mac and use XCode to debug/build issues on the mac, now I use rider with remote support for 95% of my mac needs, and on occasion when I do need to drop back to the mac, I'm using the same tool rather than xcode.

Until 2022 (which granted I haven't used), VS was 32 bit which despite MS's frequent assurances wasn't a problem, was. Running OOM was a regular occurance on large projects for me over the last 10 years.

Roslynator is a collection of refactoring enhancements for VS. Resharper/Rider add a ton of things beyond refactoring. Its unit test runner is way better (IMO) than VS's native test runner. Support for Unity & Unreal Engine development for game developers. Rider works on Linux, Mac and obviously Windows.

I've been a happy R# customer since 2006. Since then I converted to JetBrain's all products subscription - DataGrip is a really nice database management GUI that supports nearly every database you could ever want (from SQL Server to Postgres to MongoDb!) If you do any frontend development Webstorm is IMO a much better experience than VSCode.

If you want to come back and dip your toe in the water, Visual Studio 2022 is better than ever. But Rider is a great IDE and I’d recommend starting an evaluation of that.

I feel like 2022 is the slowest edition I have used. My 2017 instance is still significantly faster. I've also had a hell of time with "Hot Reloading" and even the debugger in general.

I think .net 3.1-6 has settled enough now that the confusion is more or less gone.

Absolutely; the language moves fast. Around 2015 I was using C# at work. Last year I did some code review on a C# project and at first I had no idea what I was looking at. The new features and design patterns used made it like reading a language I had never seen before.

Install ReSharper, write code your way, then click on the suggestions. It'll rewrite a lot fo code for you to the new style. Do that for a week and you'll get back.

I'm not spending as much time as I like coding C# nowadays but keep the R# subscription up, it's invaluable when I need to get back up and running.

Biggest chance in dot net core is IoC by default and syntax sugar ( eg. Tuples)

Since .net 6 things are changing more. Eg. The first time with a minimal API needs a bit of exploration. In general it's explained by global static functionality.

Blazer is c# and a different way of writing websites.

ASP.NET, Blazer and Maui are IoC by default because they are complex franeworks, .NET is not.

Almost all projects are using those frameworks.

Asp.net MVC 4.5/webapi and before did not have IoC build-in.

Right… so before people had to manually add ioc for all those projects then might ass have a default one, which is swappable if you don't like it.

I think you should reread what I said.

It wasn't there before, it is now. I didn't say anything about if it should be there.

Eg. I know an older developer who still doesn't see the benefit. So it's useful to mention that it's in there now.

Oh indeed. The language and the normal coding style evolved significantly, the base class library evolved and the whole base promise of the language switched from supporting UI apps and Windows services to be a top contender for any program type you currently can imagine.

Learn .NET Core (nowadays called just .NET). It is a fresh breeze to your memory. So easy, so rewarding compared to the complexity of Java or Node dependency trees.

> So easy, so rewarding compared to the complexity of Java or Node dependency trees.

How do Java dependencies differ much from C#?

Starting with the question maven vs Gradle etc. Maybe that is a bit more build system madness than package management madness.

Build system madness? Basically all projects are either build with Maven or Gradle?

Reply on news.ycombinator.com