5 ms·

I can chime in on this one. I think it's very much a 'culture' thing. So, I'm a *nix guy. You know, running Sway WM, using Doom Emacs as my daily driver, that

I can chime in on this one. I think it's very much a 'culture' thing. So, I'm a *nix guy. You know, running Sway WM, using Doom Emacs as my daily driver, that sort of a thing. Learned vim to write my thesis at night on an armchair where using the mouse was not comfortable. Not long ago I accidentally got involved with a kind of a .NET consulting gig. Rather, I got involved as a domain expert to help out some SaaS startup dealing with that domain, and it just so happened that they were writing their thing in C#. Before that I hadn't used C# at all, mainly dealing with Python and C++. I liked the language, I thought the tooling on Linux was pretty decent. The ecosystem was a bit lacking for the domain in question, but it had other nice things going for it. But there was definitely a bit of a culture clash with the .NET guys. As an example, I did my domain thing in a pretty much self-contained library. 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. Later, I had to touch the rest of the codebase a bit. 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'. And you know, I'm really not trying to diss those guys. They were nice, capable, smart, productive, good people. It's just that I was very evidently from a different 'tribe'. So, I personally like the direction that .NET is taking. I think that this release has very nice things in it. Such as the statically linked binaries, and compilation to webassembly. I also believe that modern .NET has a nice value proposition in being able to use your code across the board in many contexts and settings. On top of that, both C# and F# are nice languages. But I won't be looking for .NET jobs, or putting that .NET stint on my resume, lest some recruiter gets the wrong ideas!

fabian2k 5y ago
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.
- jgilias 5y ago
  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.
  - mycall 5y ago
    C# 9 and 10 added records, which is better for pure data objects. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/record https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
  - jiggawatts 5y ago
    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...
  - CuriousSkeptic 5y ago
    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.
svick 5y ago
> 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.
- jgilias 5y ago
  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.
kinjba11 5y ago
> 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.
- jgilias 5y ago
  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?
  - DeathArrow 5y ago
    >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.
    - tonyedgecombe 5y ago
      >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.
DeathArrow 5y ago
>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.
- tonyedgecombe 5y ago
  .NET does push you down that route though, at least on the UI side. Using WPF feels like wading through treacle to me.

fabian2k 5y ago

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.

jgilias 5y ago
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.
- mycall 5y ago
  C# 9 and 10 added records, which is better for pure data objects. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/record https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
- jiggawatts 5y ago
  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...
- CuriousSkeptic 5y ago
  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.

svick 5y ago

> 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.

jgilias 5y ago
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.

kinjba11 5y ago

> 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.

jgilias 5y ago
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?
- DeathArrow 5y ago
  >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.
  - tonyedgecombe 5y ago
    >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.

DeathArrow 5y ago

>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.

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