Hacker News Reader

Comment by elamje | Hacker News Reader

As someone who uses .NET daily, but loves Clojure and other functional programming paradigms - Records seem like a very compelling feature. Immutable data structures without any hassle to set up. Simply write “record” where you would normally write “class” and boom, you are working with immutable objects. This is one step closer to one the best features of Clojure IMO -everything is immutable.

Additionally, there seems to be another new way to accomplish this. Normally class properties are accessed via get; and set;

Now we have the ability to use get; and init; which effectively makes the object immutable/read only after initialization. The syntax is just a little cleaner and more obvious to the reader how the property should be used.

C# has really been adding some great features the past few years and is certainly getting more expressive and concise which I appreciate.

View on HN

You probably know, but F# exists if you want a functional language in the .NET ecosystem.

Granted, you end up dealing with a bunch of OOP libraries still since .NET is very C#-centered, but the language is pretty good and the integration is painless.

If I wrote a F# codebase at a lot of companies I would find myself swiftly booted out the door.

Oh yes you'd definitely get booted for using F# in a C# shop. I love F# but would never use it at my current job because nobody else on my team knows anything about FP, even though the language itself can be learned in about a week since it's so simple.

My comment was a glib comment and wasn't supposed to be taken too seriously.

Fair enough, but it also outlines a bit of truth that you shouldn't necessarily go against the grain of the programming culture of a workplace just due to personal preference.

Yes, I’d love to use F#, but not a lot of opportunities out there.

And .NET, like you mentioned, is very C# focused which would become frustrating at times.

My experience with F# over 7 years of production coding is for most needs there is already an F# .NET library or wrapper over an OO library. It's mostly only very specialized needs that drive me to an OO .NET library.

Aren’t records pretty trivial to create as a custom class in C#?

they compile to classes in the background. the benefit is in the succinct syntax, value-type style equality checks and built in immutability (via the new init-only properties).

Absolutely not.

Records generate a lot of code when you compile them, including methods to compare by value.

The boilerplate required to do that in C# without records is extensive and hard to maintain. Even structs, which are supposed to be value objects, are not easy to compare by value.

I'll put it this way: records are important enough that I stopped using C# because it lacked something like records, and now I'm going to pick it up again.

If you want to see how much code you get 'for free' by defining a record that you used to have to do manually, check out the generated C# here (structural equality, GetHashCode, Deconstruct, cloning for 'with', pretty printing, etc)

https://sharplab.io/#v2:EYLgtghgzgLgpgJwDQBMQGoA+BYAUANwgQAI...

That’s neat!

It’s also generating code for the main method, which is also a new c# 9 feature

Aren't records meant to be immutable?

I don't understand why properties have setters in the generated definition of the record. I'm missing something.

Constructor-defined properties of records are implemented using auto-implemented properties with the new init keyword, so:

    public int MyProp { get; init; }

instead of

    public int MyProp { get; set; }

Apparently those are implemented using readonly backing fields while still retaining property setters.

Thing is, you can do it but with ceremony.

You have to override Equals() and GetHashCode() for starters. Then you also need to make sure you only have getters and no setters (or private setters). In some cases you need to make your empty constructor private and force a specific constructor to be used. If you have multiple constructors it means you will have different invariants which puts you in class land, you are better off with classes then anyway. Also if your immutable objects have many methods..that also puts you in class land.

Just that alone makes it cumbersome.

So a new record type that behaves somewhat like a struct would be perfect. Or the F# way, which is basically perfection.

I also want to stress that this is per class. Which in reality is madness.

If you have just 50 immutable classes you have to replicate those 50 lines of boilerplate for each class and make sure it's bug free. It clutters your classes up and it's just plain gross.

It's going to be way better that the platform supports this kind of data structure natively instead of us building out the monstrosity ourselves.

By the way, plenty of the features of C# is basically syntax sugar, gets compiled down to more vebose code anyway. We think we write one or two lines of happy code, but underneath it might get turned into 20 lines. Luckily we mostly don't have to see/deal with it unless you are trying to squeeze your apps performance to the max (or have a nasty bug that cannot be caught by normal means), but at that point it might make more sense to use a lower level language.

There is no correlation between lines of code and performance. Longer code is often faster, while short, succinct code is often slower.

Record looks like scala case classes. I miss them; they save a lot of mucking about (like, loads). Immutability is an extra, it's the brevity it brings.

Reply on news.ycombinator.com