Hacker News Reader

The .NET people were likely right in your case. In C# structs are allocated on the stack, that's why you'd use them. Unless you have a specific reason you'd generally keep pure data objects as classes and not structs.

And there can certainly be a culture clash, there is a bit of a tendency towards more complex patterns in the .NET world. But you don't have to do that, and MS is quite explicitly adding versions with less boilerplate in this release, if you prefer that.

Just re-read C# documentation and remembered the situation more clearly.

Basically, I consciously researched the differences between class and struct in C# beforehand. And decided to use struct as the 'thing' was a kind of a coordinate that would be instantiated a lot for simple coordinate-space transformations, so it made sense for it to actually be a value type.

I should've been more assertive about it. Well, worst case some periodic imports are taking somewhat longer than they should.

C# 9 and 10 added records, which is better for pure data objects.

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

That's different, and in that case a struct is preferred.

Don't confuse inexperience with culture.

I'm from a mostly-.NET background I argue with typical .NET developers all the time.

I also argue with Java developers, and C++ developers, and...

Just to add some context. Another commenter mentioned gotchas that would make C# developers weary.

The fist that comes to mind is that with a class invariants of the type can be ensured in the constructor or by making the constructor private and exposing static factory methods. A struct, on the other hand, is always simply declared, so don't afford these protection measures. For some reason C# still supports constructors in structs though, and even uses the `new` keyword to invoke them. This creates a kind of trap where structs almost, but not quite, behaves like classes.

Another gotcha is the defensive copy semantics. When a method is invoked on a struct, and that struct is a readonly field, a copy of the struct is created for the method to avoid mutating the field. This is not at all how classes referenced by a readonly field behaves.

I guess the same can be said for the simpler case of just passing a struct as parameter to a method mutating its now local copy. Again different outcome for structs and classes.

Since the code look so similar (its just a different keyword at declaration site) it creates an uncanny valley tripping people up. Not least when refactoring between the two. After all, being a language with a GC means memory layout is seldom a primary concern for people.

However you can now declare structs readonly to avoid the defensive copy thing, or as a ref-struct to retain mutability, almost like a class. And as long as the default value is perfectly valid, like say (0,0) there shouldn't be much surprises anymore.

> While writing it I needed something that would be 'just data' without any additional 'functionality' attached to it, so I naturally reached for `struct`, given that it exists in the language. The .NET guys asked why it was not a `class` instead. See, somewhere deep inside they felt that not wrapping everything in a `class` is wrong on some fundamental level.

The difference between a class and a struct in C# is not the same as between a class and a struct in C++. In C#, structs can definitely be useful, but also have some gotchas, so they're mostly used only in performance-critical parts of the code.

If you visit a foreign tribe, I think you should listen to the locals, unless you are really certain your way of doing things is better in the local context.

Yes, of course, I applied 'when in Rome' a lot.

In this case though, the struct usage was completely in line with C# documentation regarding what structs are for. I wasn't trying to write C++ in C#. But hey, I do agree that code should be idiomatic to the particular community such that it doesn't feel out of place! In that case the struct did become a class.

Edit: Just re-read C# documentation on structs. Yes, it absolutely made sense to have a value type there. As in, the documentation mentions the use case almost verbatim.

> But I won't be looking for .NET jobs

Have heard this sentiment in more than one comment in places like HN. "The {tech} is great, but the culture was ... so I'm not putting {tech} on my resume". And So it becomes a self-fulfilling prophecy :). Yet some tech seem immune to this. They don't say "X is great but the culture was crap, so I'm abandoning X", they say "X is great but the culture was crap so I'm changing jobs".

It really drives home that culture is critical, and even the worst tech can be tolerable if it is thought of as cool. Though of course the thought of abandoning ship to learn the latest and greatest solely to avoid legacy C++98/Spring/WebForms/whatever is naturally appealing.

I see your point.

But then, do you really believe one would be a smart person if they were to look for .NET jobs where at the same time Windows is not the dominant environment that people use at work?

>Windows is not the dominant environment that people use at work

Are you sure about that? Maybe Windows is not dominant when you look at startups.

Anyway, what .NET has to do with Windows now? You can happily use it on Linux or macOS.

>You can happily use it on Linux or macOS.

I would say that has only just become the case and still isn't for desktop development.

>At one point there was something I felt was a 'one-line change', that took 12 files to edit. Mostly routing calls through different auxiliary classes because 'architecture'.

I won't blame .NET for this. Needlessly complicated architectures are because OOP everywhere minded guys, Uncle Bob and GoF patterns. If you worked with a Java shop you cold have been hit by the same scenario.

.NET does push you down that route though, at least on the UI side. Using WPF feels like wading through treacle to me.