131–140 of 214 posts
Apologies, but here's the obligatory link to my OneOf exhaustive type matching library: https://github.com/mcintyre321/OneOf
One thing that I like about my lib is that is serializes to json pretty well, and i added some more special-case variants such as accumulative errors (AccResult) and some applicative lifting operations.
Earlier quoted context omitted.
I used VS for years before switching to Rider and honestly... just jump in, there's not much to know. If you've used ReSharper the features should seem pretty familiar.
What do you think is better in Rider? I’m using it myself for a few months now but feel like going back to VS all the time.
Rider was what I thought I'd give a go, with the idea that if it was really terrible I'd fire up a VM with Windows and VS.
As someone who's used Visual Studio since VS 2002, and ReSharper since (probably) 2006 - moving to Rider was pretty much run and go.
There's a few minor differences, but the only one that bugged me was the regional formatting options for the debugger. I still havn't figured out how to set it to use ISO8601 or something like it for formatting dates/times, and instead it picks something based on my OS configuration.
I've always seen switch statements as an anti-pattern in C#. These examples however, do demonstrate neat time saving techniques. Does anybody have examples of real-world use cases that take advantage of this that couldn't (or shouldn't) be solved in a more OO way (Visitor, Strategy, Template Method, etc)
Why are switches an anti-pattern? Switching a simple switch with a strategy pattern can make code far more complex and hard to understand. Switches are simple to code, simple to read, and easy to change.
Because the gods of OO decreed as such and now the logic must be distributed across a dozen classes/files.
Notice the language "that couldn't (or shouldn't) be solved in a more OO way", their goal is to create OO code, not simple to read and easy to change code.
I'm super embarrassed as a dotNet developer, at times 'engineer', that I don't know this.. I can't list how many time's I've ran into this kind of issue when trying to explain to a peer/intern.. (Only know I probably messed up a bit now) And HN links like this just remind me that I would love to take a 'bus mans holiday' just to catch up on the framework. This is a huge plus to the benefits of sending employees and m…
I find it helpful to read over them even when picking up a new language / framework to see how it has evolved over time.
Resharper has proven to be a great way for me to start learning and integrating new language features. I code in my original style and resharper suggests changes based on new features like pattern matching. At first I didnt see the benefit, but this is a hugely powerful feature once you start to wrap your mind around it.
I have clocked in way more hours in Rider than VS. I can flawlessly run and debug our decades old monolith with 40-50 projects and millions LOC, containing C#, VB, Web Forms, WPF, files with 80k lines... And all of our .NET Core services on MacOS, with all my unix-y tooling. There is “VS for Mac”, but it’s not really VS. It’s Xamarin Studio rebranded. Rider works excellent on my Linux box at home as well, where the a…
At this point I would not be sad if I was forced to use C# for some reason.
You should try it out sometime, regardless of coercion. There isn't much of a barrier to entry anymore. Even installing VS2019 is a pleasant experience now. I have yet to meet a developer who gave C# a legitimate try and then decided it was entirely not for them. That said, I only personally know developers who are working in the realm of B2B application development, so perhaps there are other incompatible use cases…
Even more pleasant (imo) is installing VS Code and .NET Core SDK.
Earlier quoted context omitted.
Their long game is to slowly convert C# into F# without anyone realizing it. They're roughly half way through already.
From the features they are porting into the language I think this is the case; albeit C# will always be the more verbose language and the features will feel somewhat clunky at times IMO. Pattern matching, async yield return, async/await, etc all were in F# in some form beforehand with features like records and DU's probably being investigated as well. When I read a new C# language version announcement it does feel li…
Heads up for C# devs, you should switch all your code bases to use (x is null) and !(x is null) instead of ==. The is operator can't be overloaded, and always compiles to IL eq, whereas == can be overloaded in custom types. Of course it would also be nice if everything was moved to nullable reference types [0], but that's a non trivial amount of work. Note that most C#8 features can be enabled manually through the cs…
Also, I don’t understand the scare over operator overloading. It’s not common and it works fine with nulls too as long as it’s implemented correctly. If it’s buggy, you’re screwed for other cases anyway, it isn’t much helpful to try to fix null checks only.
I find this advice overhyped because of these reasons.