I know not everyone likes them, but for typed languages I find it extremely hard to go back to languages without ADTs of some kind. I do Java for my current job, and Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would be done in three lines of F#.

Instead they've been, very slowly, turning C# into F#, which is even weirder to watch.

I miss writing it; I haven't had a job using it in a few years but I really enjoyed writing code in it when I did. Most of my personal projects haven't really been able to use .NET for awhile, so I never seem to have an excuse to play with F# in my personal time.

I never got into C#, so I can't say that I really feel the pain of the C# transition into F#.

[1] At least in the typed world. I'm also really partial to Clojure.

I'm not. I find F#s syntax much more pleasing and elegant, and I'm afraid F# will wither away when C# is a watered down version of it.

Something that helps, a ton, is as you're transitioning, you can write code almost identically to how you did before. It doesn't force FP on you at all. It's less useful if you try to do that, because you're not taking advantage of the language, but it makes testing your beliefs on how things work SUPER easy because you can set it up in the OOP way, get the result you expect, then set up in what you think is the correct FP way, and see if it matches.

The only issue is there's a severe lack of beginner friendly documentation (although it's leagues better than it used to be). I honestly think that if you're a C# dev, it's probably worth giving it a weekend or two to play with. ESPECIALLY if you like linq syntax.

To be clear, it's not like I'm new to functional languages and their type systems, I've been doing Haskell for forever, and I did F# for a multiple years, but Scala has never really clicked for me.

Personally, for doing JVM stuff, I'm a pretty die-hard Clojure advocate. I feel like it's easy for me to write Clojure in the way that I think, while still allowing me to mooch off the entire Java ecosystem, and if there are things that I don't like about the language it's really not that hard to macro in a new feature (though obviously this should be used sparingly).

I definitely recommend giving F# a try. I think it's an extremely underrated language.

That was a bit of a surprise - I’d forgotten how expressive Scala is. I didn’t need any “advanced” type system features. But my time to market was literally a couple hours instead of days like with C#, Java, Kotlin, Go, bending to fit the logic into the confines of their type systems. Kotlin is just awesome and very expressive. But it turns out, to me, Scala is somehow very natural - just write what you think, and it works.

Interestingly, that was also my experience many years ago when I first exposed myself to Scala in a numerical analysis class just to avoid Java, and it just worked right away. I recall well that surprised feeling. So I’m kinda happy to move back to Scala now. But I’ll also try to implement the same in F#, right after delivering the next feature set.

Do you have any recommendations for people who do not have C#/.NET experience who want to rip their toes in F#? The last time I tried the language I bumped my head on the .NET parts. :/

For the most part I didn't need most of the built in .NET libraries; the F# stuff was fine, but the ones I ended up using a lot were the threadsafe libraries for when I needed mutation across threads. ConcurrentDictionary was one I used an awful lot, ConcurrentBag occasionally, SemaphorSlim, and Interlocked Incrementors.

The reason that the .NET compatibility was handy to me was because it made it easy to get third party libraries without much fuss, which was great because they were generally pretty well supported.

The rule of thumb that I used was that F#, while it kind of looks like Haskell, is not Haskell, and specifically it's not lazy, and as such I always kind of pretended I was in the `do` block. Things execute top down, and you can mix in side effects wherever, so you kind of have to pretend everything is in an IO monad, or at least if you see anything that has a side effect in there.

[1] I was hired at Jet.com specifically because I had Haskell and Erlang experience prior. I had never written any significant C# code before.

Also, having the documentation split between the F# parts on one site and the .NET parts on another site was a bit of a pain.

It might have gone better if I was starting with a book instead of picking docs off the web.

https://fsharp.org/use/linux/

FWIW I think it works fine with Nix, so if you're not opposed to using that package manager it should pretty trivial to get different versions working with a nix shell and/or flake.

In F#'s case, there are plenty of good books, and then it is really needed to learn the platform.

Some well known ones => Stylish F#, F# in Action, Domain Modeling Made Functional

https://fsharpforfunandprofit.com/

From what I've seen, Scala3 is better in this regard (at least the magic part), but I since Spark doesn't support it yet, my exposure to it has been limited.

Thing is the community doesn't reach that often to them.

I'm almost of the mind to use F# or C# instead of waiting.

For one, they don't work for generic code where you want to discriminate. I.e., if you have a generic A or B type, you can't pattern match on it. And it's hard to add restrictions to the generic types such that it would work.

Such types sort of work in TypeScript, but TypeScript also has structural typing, meaning that it's designed for it.

Still, good to see Java joining the 21st century at least.

Same for C# with this new feature. Sum types (as I like to call tagged/type unions) are such an important tool to have, not having it makes languages resort to all kinds of abominations, e.g. exceptions, product types (= records, structs, etc) that are actually sum types, "null to signify something went wrong", etc.

Not having them from a language's start results in an std lib that does not use them and hence teaches new comer to the language a bad way to do it.

Pattern matching too.

This is a weird take, given that Java has had ADTs for years

Records https://en.wikipedia.org/wiki/Java_version_history#Java_16

Sealed classes https://en.wikipedia.org/wiki/Java_version_history#Java_17

And pattern matching for almost a year https://en.wikipedia.org/wiki/Java_version_history#Java_21

Otherwise big agree on how delightful to work with F# is.

Additionally, excited to now watch this go in and people on HN still act like C# is the same it was 10 years ago.

https://github.com/dotnet/csharplang/blob/18a527bcc1f0bdaf54...

In any case, welcome to C# and thanks!

Just a little bit of patience with the collections, I'm slowly learning to trust the native offerings, at least there's a regular List at the bottom now, much thanks to you.

I'm just used to using more descriptive type names, that's all. It bothers me to no end when I have to keep guessing and memorizing the correct primitive type for a concept. Also makes the code more difficult to read.

I'll have a look at the PR, thank you!

Heh yeah well, for better or worse, it seems to be C#’s design goal to have every single feature possible, with multiple variations of each of them. It means it’s able to cater to everyone and doesn’t turn people off the way strongly opinionated languages can. But it can make it a bit tricky to pick up.

I'd really push back against this - where do you see API duplication? IMO the C# team is _incredibly_ conservative with new language features and only add in things that fit a missing part of the language, and when doing so try to also weave in existing C# features to build upon.

I think if anything you may be referring to syntax options? There are a few syntactical ways to do the same things for sure, but I don't think that's bad, as each has their own use. But for bigger tentpole features like records or Span<T> or whatever, they are directly addressing a need and aren't just iterative versions of other things.

Is this just a case of "C# developers like to make up different names than established terminology"? (see: SelectMany, IEnumerable, etc.)

UPD. They have this in the FAQ:

  Q: Why are there no tagged unions?
  A: Union structs are both tagged unions and type unions. Under the hood, a union struct is a tagged union, even exposing an enum property that is the tag to enable faster compiler generated code, but in the language it is presented as a type union to allow you to interact with it in familiar ways, like type tests, casts and pattern matching.

    enum Option<T> {
        None,
        Some(T),
    }

But I see what they mean a bit with the C# example:

    union U 
    {
        A(int x, string y);
        B(int z);
        C;
    }

Take Option<Infallible>, it's a ZST, not only is there no "tag" there isn't any data at all. In type theory this is fine, we added an empty type to the unit type, we got a unit type.

- closed hierarchies of reference types that the compiler will verify at build time

- value types that use compiler tricks to behave like closed hierarchies (tagged unions)

- custom types that can have any implementation but can hook into the same compiler mechanisms to behave like a union of types

- ad-hoc unions of existing types

I’ve never felt like I’ve fully understood the implications of the expression problem https://en.wikipedia.org/wiki/Expression_problem but my best/latest personal hypothesis is that providing extension points via conventional polymorphism might be best suited for unknown/future clients who might extend the code, but unions with exhaustive pattern matching seem better suited for code that I or my team owns. I don’t typically want to extend that code. More often, I instead want to update my core data structures to reflect ongoing changes in my understanding of the business domain, more often than not using these Union-type relationships, and then lean on the compiler errors maximally to get feedback about where the rest of the imperative code now no longer matches the business domain data structures.

https://deliberate-software.com/christmas-f-number-polymorph...

OOP Approach with interface/inheritance:

Easy: Adding new types (variants) of a base class/interface. Hard: Adding new functionality to the base class/interface, as it requires implementing it in all existing types.

FP Approach with Discriminated Unions:

Easy: Adding new functions. Create a function and match on the DU; the compiler ensures all cases are handled. Hard: Adding new types to the DU, as it requires updating all existing exhaustive pattern matches throughout the codebase.

Here's some Kotlin code. Kotlin is great because it can do both really well.

  // Object-Oriented Approach
  interface Shape {
      fun area(): Double
      fun perimeter(): Double
  }

  class Circle(val radius: Double) : Shape {
      override fun area() = Math.PI \* radius \* radius
      override fun perimeter() = 2 \* Math.PI \* radius
  }

  class Rectangle(val width: Double, val height: Double) : Shape {
      override fun area() = width \* height
      override fun perimeter() = 2 \* (width + height)
  }

  // Easy to add new shape
  class Triangle(val a: Double, val b: Double, val c: Double) : Shape {
      override fun area(): Double {
          val s = (a + b + c) / 2
          return Math.sqrt(s \* (s - a) \* (s - b) \* (s - c))
      }
      override fun perimeter() = a + b + c
  }

  // Hard to add new function (need to modify all existing shapes)
  // interface Shape {
  //     fun area(): Double
  //     fun perimeter(): Double
  //     fun draw(): String  // New function
  // }

  // Functional Approach
  sealed class ShapeFP {
      data class CircleFP(val radius: Double) : ShapeFP()
      data class RectangleFP(val width: Double, val height: Double) : ShapeFP()
  }

  fun area(shape: ShapeFP): Double = when (shape) {
      is ShapeFP.CircleFP -> Math.PI \* shape.radius \* shape.radius
      is ShapeFP.RectangleFP -> shape.width \* shape.height
  }

  fun perimeter(shape: ShapeFP): Double = when (shape) {
      is ShapeFP.CircleFP -> 2 \* Math.PI \* shape.radius
      is ShapeFP.RectangleFP -> 2 \* (shape.width + shape.height)
  }

  // Easy to add new function
  fun draw(shape: ShapeFP): String = when (shape) {
      is ShapeFP.CircleFP -> "O"
      is ShapeFP.RectangleFP -> "[]"
  }

  // Hard to add new shape (need to update all existing functions)
  // sealed class ShapeFP {
  //     data class CircleFP(val radius: Double) : ShapeFP()
  //     data class RectangleFP(val width: Double, val height: Double) : ShapeFP()
  //     data class TriangleFP(val a: Double, val b: Double, val c: Double) : ShapeFP()
  // }

However the definitions make the 2 choices (adding new types vs adding new functions/operations) sound like a toss-up.

It is the fact that I tend to find the FP/DU approach so much more frequently useful for my/my team's own code that makes me wonder if I'm missing something.

Perhaps the important distinction I've been missing is in Wikipedia's definition:

"The goal is to define a data abstraction that is extensible both in its representations and its behaviors, where one can add new representations and new behaviors to the data abstraction, without recompiling existing code, and while retaining static type safety (e.g., no casts)."

... but when I'm working on my own/team's code, it is perfectly sensible to recompile the code constantly.

When you are extending, you actually want to choose the correct thing depending on what you need. Going the wrong direction is painful in both directions.

Personally I think one of the reasons sum types are greeted with such "oh my gosh where have you been all my life" reactions is precisely that we had type extension as our only option for so long. If we had had only sum types, and type extension was given to us for the first time in obscure languages 20 years ago and they only really started getting popular in the last 5 or so, I think they'd be considered in much the same way. Just as in a world with only screwdrivers, the invention of the hammer would be hailed as a revolution... and in a world with only hammers, the invention of the screwdriver would be hailed as a revolution. But in both cases the real mystery is how the hypothetical world got that far in the first place.

Not that they aren't useful; consider what it means that I'm analogizing them to something like a hammer and a screwdriver, not an oil filter remover or something. It is weird that we were missing one of them for as long as we were in the mainstream.

Though I do wonder as well how many people encountered them in their "spread their wings" phase and happened to be learning about sum types just as their general programming skill was leveling up in general, and conflate the two. When you learn how to use both skillfully, I really feel like the differences collapse quite a bit. I see so, so much bad code with type-based extension, but it's not because they're using type-based extension, but just that it's bad code, regardless. Of course bad type-extension code is worse than good sum types code, but there's still times and places for both approaches when you know what you're doing with both.

Maybe you can read all the public fields, but you can't actually modify them or create functions that modify the object. You then must wrapper around the instances and fight to bridge every little behavior between their code and yours.

This to me is evidence that one core tenet of OOP "Open to extension" is in-practice meaningless.

But this looks like a discriminated union which I'd recognise from F# or Haskell. The distinction I'd draw is that for a DU there are named case constructors. Yes?

"sum type" is the term of art in Computer Science theory, but "union type" is also used.

See

https://en.wikipedia.org/wiki/Type_theory#Sum_type

https://en.wikipedia.org/wiki/Tagged_union

There is no single "correct name" as there is no single "problem domain" that covers the algebra of type theory, and the pragmatics of programming in engineering, along with other areas.

sum types also have tagged and untagged variants. the untagged variants are less useful (more cumbersome) in case of sum types and hence often are not implemented in languages.

  var p = (x: 1, y: 2);
  var q = (u: 1, y: 2);
  var f = ((int x, int y) a) => a.x + a.y;

  p == q 
  f(p) == 3
  f(q) == 3
  p.GetType() == q.GetType()

  var r = q.x;

CS1061: '(int u, int v)' does not contain a definition for 'x' and no accessible extension method 'x' accepting a first argument of type '(int u, int v)' could be found (are you missing a using directive or an assembly reference?)

and if

  dynamic d = q;

  var s = d.u;

RuntimeBinderException: 'System.ValueTuple<int,int>' does not contain a definition for 'u'

at runtime, revealing the underlying CLR type.

Not always true in C#. Tuples can have member names

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

It does get used to but still reading the too many A|B|undefined gets tiring after a while. It also adds to laziness as you could take one thing and be fuzzy about returning a combo of three or more things. And as you go up the stack this gets more and more confusing.

C# forces you to deal with this in a constrained way which I like.

But perhaps there are folks who are excited by this that have a convincing argument? Please educate me.

I’m pretty sure you can implement the example in this proposal by declaring an empty interface and having some record classes that “implement” it. Does that lose something that I’m not seeing?

Also, the options may not share any surface area at all, so the “interface” for all the types may be empty which is a bit unnatural in OO.

But under the hood, it’s just this: a type hierarchy. But the hierarchy is closed for extension, and (this is the key part you’d not get if doing this “manually” as you describe) when code uses the cases, failing to account for a case will cause an error at compile time.

[1] https://en.m.wikipedia.org/wiki/Algebraic_data_type

[0] https://github.com/mcintyre321/OneOf

I think,.net team haven't added discriminited unions yet because it can be effectively simulated with interfaces.

With an interface, someone could add a new implementation, causing codee to fail at runtime.

https://youtu.be/aksjZkCbIWA

> Note: Have Mads write this part.

:)

Having _attempted_ (and being bitten by) far too much black magic with C# unions in the past (using FieldOffset), there is an unfortunate situation here: aliasing a pointer/ref value and value is UB. This means that a struct union of a u64 and an object would need separate fields for each, wasting 8 bytes. That is, unless the ryujit/gc is updated with knowledge about this.

It is possible to overlap fields in this way, though offsets occupied by an object reference shall not overlap with offsets occupied by a built-in value type or a part of another object reference.

Per .NET 8.0:

  using System.Runtime.InteropServices;
  var s = new S { Bar = "Baz" };
  [StructLayout(LayoutKind.Explicit)]
  public struct S {
      [FieldOffset(0)] public UInt64 Foo;
      [FieldOffset(0)] public Object Bar;
  }

System.TypeLoadException: Could not load type 'S' from assembly 'foo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' because it contains an object field at offset 0 that is incorrectly aligned or overlapped by a non-object field.

Interestingly, this code elicits a warning

ILC: Method '[foo]Program.<Main>$(string[])' will always throw because: Failed to load type 'S' from assembly 'foo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' because of field offset '0'

from the AOT compiler, but none from the C# compiler.

The C# compiler has very little knowledge of `[FieldOffset]`. It's expected that developers understand the runtime implications of this.

I know I know, pseudo OO took over the world, and then people revolted against it, so the easiest thing to do to stay relevant is to become "slightly functional with curly braces", rather than to actually try and do OO well.

But my question is: what is missing from the OO side? What would it take for C# and/or others to "do OO well"?

As for what C# could do better, the OO solution to the problem pattern matching solves is multiple dispatch - with single dispatch languages you need things like the visitor pattern. Making that a first class part of C# would be fantastic.

https://shawnhargreaves.com/blog/visitor-and-multiple-dispat...

Multiple inheritance. (j/k)

Having "interfaces" and "abstract classes" is just a kludge, multiple inheritance covers all of this with one language construct.

The "diamond problem" is a C++ issue, every other language solved it.

Also C++ has exactly what you want. No interfaces, multiple inheritance. People don't utilize it unless it's a GUI lib.

CLOS and Ocaml figured it out

https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...

https://github.com/dotnet/csharplang/discussions/5496

Which concepts or feature you have on mind?

  Siamese pet = ...;
  (Cat or Chihuahua) mostlyCats = pet;
  Dog dog = (Dog)mostlyCats;

I am unsure what that section entails...

Let's say I have a function like this:

  void ConsumeAB<T>(T ab) where T: IA, IB;  

  class ABC : IA, IB {}
  class ABD : IA, IB {}

        var items = new (ABC or ABD)[] { new ABC(), new ABD() };
        foreach (var item in items)
        {
            ConsumeAB(item);
        }

Edit: typo

Tearing can cause memory safety issue. Variant A can have an integer field and variant B can have a reference field in the same offset. Tearing can cause it to treat an integer as reference.

At the point where you have more than 5 cases, the GC overhead starts to get shrink in comparison to the calling convention and copying overhead anyway.

I was considering introducing the OneOf library into our codebase, but if this is < a year or so away it might not be worth the effort.

Really though, you don't need a library to do sum-types in C#:

It's best to just use records for now:

    public abstract record Maybe<A>
    {
        private Maybe() { }

        public sealed record Just(A Value) : Maybe<A>;
        public sealed record Nothing : Maybe<A>;
    }

You can then construct like so:

    var mx = new Maybe<int>.Just(123);
    var my = new Maybe<int>.Nothing();

   var r = mx switch
   {
      Maybe<int>.Just (var x) => x,
      Maybe<int>.Nothing      => 0
   };

And, if you want a load of pre-built ones, then my library language-ext will help [1]

[1] https://github.com/louthy/language-ext/

    public record UhOh<A> : Maybe<A>
    {
        public UhOh() : base(new Maybe<A>.Nothing())
        {
        }
    }

    Maybe<int> m = new UhOh<int>();

I implemented my own option types entirely differently via ref structs where the "non-option" becomes either a default of a value type or a null reference (size of a pointer). Then (in theory) the overhead is reduced to a single dereference with everything else being stack-allocated.

I then built the same thing as a non ref (regular) struct version for storing in a field. So I have Options.Quick and Options.Long namespaces with practically the same struct design just the former is a ref struct.

This has served me very well, is very fast. It just doesn't have the exhaustive checking and risks derefing a null reference, but in practice is not a big issue.

   if(option.IsT1){ doSomething(option.ValueT1)};
   if(option.IsT1){doSomething(option.ValueT2)}; // this would throw an exception, i.e. a bug, but its very readable to catch the bug

.NET releases are every November, and I would be very surprised to see this in November 2024. More likely November 2025 at soonest. But check back to that page later.

Union types (what the proposal here calls "ad hoc unions") are a separate, much harder feature whose value proposition is less clear. The cost of adding a new kind to the type system is quite large because it impacts method resolution, overriding, type inference, subtyping, least upper bound, generics, type promotion, etc.

It can be worth it (for example, we added tuple/record types in Dart 3.0), but the value proposition must be correspondingly high to justify it. It's not clear that union types meet that bar yet. In many if not most of the places where users are asking for it, it often seems like what they really want is overloading or some other feature.

Related issue: https://github.com/dart-lang/language/issues/83

But for the projects that fall right about in the middle where it could go either way and I could see either language working, I almost always pick rust with discriminated unions being the biggest reason. It's incredibly hard to go back to a language without even basic ADTs after seeing the light.

And *nothing* gets even fucking close in terms of productivity to C#.

Great language, mature and robust ecosystem with sane compilation times and

great tooling: package manager, test runner, strong debugger, one CLI with almost all tools needed.

I wish C++ was half as enjoyable as C# is.

What would you suggest I do to be productive with C#?

But this is rather silly, so I'm going to assume the question is more reasonable "What can I do as a Linux user to have positive experience with C#?".

In this case, the response is very simple - you just install the SDK (sudo apt/dnf install dotnet-sdk-8.0) and then pick either VS Code and base (and free and MIT) C# extension (you do not need DevKit) or combine csharp-ls and Neovim. Other text editors that support LSP will also work. Nothing else is required.

Rider is suggested but it is absolutely optional, especially if you are not looking for that kind of high-tier IDE and prefer simpler (and faster) text editing experience.

From a demand standpoint everyone uses the Microsoft variant because it's easy to use and hire for. There's a ton of documentation. Lots of issues are at the seems of different libraries, applications or frameworks you use. And in the Microsoft world it's frequently all the same. Everyone uses the same identity library, the same webserver, the same cloud, the same database, the same orm.

If you're into learning technology it's not for you. But if you're into learning about domains and business instead of tech or like having free time it's a great stack. Doesn't work well for b2c because of the cost, but works really well for b2b.

That said, in an enterprise setting, for all of Microsoft's other faults, C# is damn near bullet proof. Some enterprises, like mine, can't rely on community supported tooling for life-critical systems. If something breaks, we're near instantaneously on the phone to a dedicated support rep to fix the problem.

I learned C# and Java years ago during my IT degree but had long since forgotten them. The enterprise I work in uses C# a fair bit.

Only started to pick up C# again in the past few months, and holy heck, I forgot how pleasurable it is to work in C# again.

If the third-party components used in some software I help maintain supported JetBrains Rider, I'd use it in a heartbeat.

Visual Studio (not Code...) is okay, though I'm not tripping over myself to use it. PyCharm and IntelliJ have spoiled me.

Funny enough, it's the efforts of Omnisharp and the VSCode team that has so significantly improved the experience of using various other languages in open source editors due to the creation of LSP.

C# and dotnet are open source so what on Earth are you even talking about?

>squash my curiosity

Maybe increase your curiosity and try something new, change the 15 year trend and use an IDE. JetBrains Rider is great and cross platform.

"tolerance in that community for people who have those values"

More likely is they don't worry about this nonsense and just get work done, making a great language, platform and tools used extensively and productively in many companies. Why should they "think about you at all" as the meme goes?

Talk of culture, values, community, tolerance, "your characteristics". This all reeks of injecting extraneous personal feelings where they don't need to be. How about you just try the language, if you actually care to do so, and worry about the rest later?

C# gets compared to java a lot for a good reason, and yet the languages and ecosystems have since diverged in their priorities and abilities. This gets even more complicated when considering F# and Scala. Do you think Java would offer similar productivity, or are there aspects to the C# that are—in your personal experience—uniquely productive?

1) default C# IDE is junk compared to IntelliJ 2) Gradle give you insane level of control over project you can even build dynamic template tasks shown in IntelliJ UI using Kotlin/Groovy 3) JVM ecosystem is much bigger and default framework SpringBoot is ready to use with houndreds of integrations which are either non existent or hards to use in .NET as opposed to SpringBoot where you have batteries included approach e.g. want outbox pattern? Simply use modulith, convention over configuration will give you some nice defaults… 4) There are plenty of widely used langs compared to .NET if you don’t like modern Java (which is on the same level as C# IMHO) you have: Kotlin which is a better lang than C#, Scala, Groovy from the mainstream ones and Clojure and probably many more lesser known. 5) There is nothing as expressive as Groovy Spock for testing in .Net world.

There are issues I see but can be easy mitigated e.g. I don’t like default Java heavy ORM (especially mapping complicated two way relations) but it’s very easy to not use them and simply relay on mapping foreign key.

To sum it up I bet your issues are mostly you don’t know ecosystem well enough.

Compared to old VS: First and foremost: feature richness of refactorings, code inspections and plugins - basically in the IntelliJ you have everything Reharper plugin can do for .NET and probably more. Second IntelliJ can run on non-spying operating systems. Third it's much more resource friendly for bigger projects. Last but not least ItelliJ is keyboard user friendly (e.g. you can jump and resize windows using only keyboard).

Can't say much about vscode vs IntelliJ. When I tried it last time Java plugin was not there. I could not use ItelliJ keyboard shortcuts - also code formatting and refactoring options were worse than in the itelliJ. That's to be expected it's paid product after all.

I've never used visual studio before so I assume the comparison is going to turn up a different set of issues. However, being tied to windows is probably not a good thing in the long term.

- IntelliJ knows exactly what version of Java you want to run and develop against.

- Async is also trivial. Just fire off a virtual thread.

- it sounds like your company just picked a bad orm. Any good one is going to escape sql injection when binding variables. You are using binding right? If you to “write it in Java” there is also jOOQ.

The one thing I do think C# is far superior at is packaging and distribution. It’s beyond simple to package a C# application into stand alone binary, whether is be AOT or JIT.

I've only begrudgingly moved to C# over the last few years as my primary since MS has pretty much killed VB.

But yeah I think C# is often unfairly viewed as a boring enterprise-y language when it's actually become a very comfy swiss army knife.

I've developed on Ubuntu and Pop_OS! in C# for years and never hit a problem.

  sudo dnf install dotnet-sdk-8.0. 
  sudo apt install dotnet-sdk-8.0
  sudo apk add dotnet-sdk-8.0

Works like a charm.

Any more irrelevant things to say?

https://github.com/dotnet/core/blob/main/linux.md#packages

The fact that it's not there (and it can't be there) was exactly my point.

I use toilets normally. I don't throw excrements.

literally first link under "dotnet debian" is:

https://learn.microsoft.com/en-us/dotnet/core/install/linux-...

__________

wget https://packages.microsoft.com/config/debian/12/packages-mic... -O packages-microsoft-prod.deb

sudo dpkg -i packages-microsoft-prod.deb

rm packages-microsoft-prod.deb

sudo apt-get update && sudo apt-get install -y dotnet-sdk-8.0

Which means anything you write with it can't be included in any distribution.

It's quite limiting. Basically it's only useful for proprietary software shipped by 3rd party.

Quick search shows that SDK and runtime packages are available in the official feeds for

Archlinux: https://archlinux.org/packages/?sort=&q=dotnet

Fedora: https://packages.fedoraproject.org/pkgs/dotnet8.0/

Ubuntu: https://pkgs.org/search/?q=dotnet

I always wondered what is the motivation behind the negative comments like these on .NET submissions. Is this because .NET is mostly made by MS employees instead of Google (which is an AdTech company) or Oracle (which has a license trap JDK distribution)?

This is the motivation ↓

    apt install dotnet-sdk-8.0
    Error: Unable to locate package dotnet-sdk-8.0
    Error: Couldn't find any package by glob 'dotnet-sdk-8.0'

JIT: dotnet publish -p:PublishSingleFile=true -p:PublishTrimmed=true

AOT: dotnet publish -p:PublishAot=true -p:OptimizationPreference=Speed*

Use -o to specify destination.

By default targets the host's OS RID, but can be overriden with e.g. `-r linux-musl-arm64`. Cross-architecture compilation is supported within OS, and there is a nuget package that switches the publish to Zig toolchain to allow publishing for Linux under Windows without relying on WSL2: https://www.nuget.org/packages/PublishAotCross This only concerns AOT as .NET uses the same linker to produce the final binary as your regular C/C++ code. It is a true native executable through and through that is understood by all standard tooling like native code profilers. For JIT binaries, anything that .NET supports can be published for under any other OS and ISA.

* my recommendation as the size impact is negligible but codegen quality in edge cases improves quite a bit. Other flags that may be useful are -p:IlcInstructionSet=x86-x64-v3 (AVX2 and friends) and -p:IlcFoldIdenticalMethodBodies=true (it's disabled by default because it can mess up stack traces, naturally, in .NET 9, disabling stack trace information enables it as well).

Which is not distribution friendly. Thanks for finally understanding you were wrong all along.

Why is that?

Most of those products have the words "Visual" and "Studio" in the name.

Atmel Studio can come too.

- https://github.com/domn1995/dunet

- https://github.com/mcintyre321/OneOf

Quite good and ergonomic with the source generators removing a lot of the boilerplate.

I have a practical example here using OneOf with .NET Channels: https://chrlschn.dev/blog/2024/07/csharp-discriminated-union...

Every time I try to use it I'm left with a feeling it's not worth the hassle over C#.

C# has been quite nice for 10 years and they keep improving consistently with every version.

It forces you to reconcile your architecture as it gets bigger and before you accidentally turn it into a monolithic nightmare. IMO, It's more than just a preemptive defense against cyclomatic complexity. Going into unfamiliar F# code, the file ordering is usually a huge clue where to start reading first.

You're going to have patterns from the .NET Framework era being ported to .NET Core projects. It works, but you'll have two paradigms of doing things mixed into your project.

I envy people who only do hobbyist C# so get to work on code bases that have all the newest language feature usage.

I've been spending the past couple years migrating various platforms from Framework to the new .NET and as long as you've got a head on your shoulders it's not too bad. Also, new projects in .NET are fantastic to work with, imo.

But when you have to work on "diverse" development teams having some sort of patterns established (flawed as they are) brings some order to the insanity.

You kinda have to fight against the IDE to not do a lot of things a certain way. For example, it'll automatically namespace new files according to your folder structure. They've also turned a certain amount of automatic linting on to gently suggest/nag you to write in a particular way.Suggest you write classes in certain ways, use newer language features, declare variables in better ways, etc. You can ignore all the nagging, but it's also incredibly easy for the next programmer to walk in and use the quick actions functionality to 'fix' the code in a few clicks.

And the asp.net core team have been incredibly opinionated, forcing a lot of good coding practices on the community.

So on the plus side, they pretty much forced DI to be the way we all work now. It's worked really well. Most library authors have now embraced it with gusto and you'll have a hard time using new libraries in a code base that's DI incompatible.

The bad side is that sometimes they made bad choices, but they are more minor things. Like they bizarrely went all in on JWT tokens which work really badly for corporate apps. Or the IOptions pattern for global settings which sucks compared to normal env variables in any other language. Lots of confusion over how they work on forums and SO.

This is why I find a .editorconfig file to be incredibly helpful.

I think abstraction bloat is one of those things that's a preference. What's bloat to one is organization to someone else. When I hope into a python codebase and it's 900 line file doing computer vision madness, I hope and pray for abstraction bloat. I'm sure there are countless c# bloated codebases but I think that's mostly a function of c# codebases being inside megacorporate or government codebases. The bloat comes from the general inefficiency that those companies run at. I guess the same could be said by the scrappy python startups that put everything in a single file with no types or inversion of control or OOP.

I guess I'm saying that I'd rather deal with the bloat problem than the wild west problem. lol

( I'm someone who deals all day with legacy .Net framework projects, mixed with the kind of mix of .Net core 3, .Net 6, .net standard 2.0, and .Net 8 projects that you'd expect from a 20+ year old company with 260+ projects. And yes, I too envy hobbyists at time. )

Overriding equals to do memberwise comparisons on POCOs

Any checking of types where pattern matching would be better

Old-style tuples without names (old style is tuple.Item1, tuple.Item2, etc.)

Checking of multiple tuple values at once without pattern matching

Any code that could be refactored with the new LINQ methods

Long ifs/switches that could be replaced by pattern matching

Concatenate a lot of strings (one per line) so there wasn't a ton of horizontal scroll, particularly for SQL in C# code

using statements still needing a level of nesting

F# doesn't really buy you anything if you're already invested in C# (or even VB.net for those poor souls) unless you have a very specific use-case for it, IMO.

Try doing WinForms in F#...

Adding F# to the game would only complicate the scenario, because I would need to connect the F# interfaces somewhere to C# anyway, requiring an additional layer of mappings in many cases.

We've created very large scale applications in it requiring significant throughput. One of its benefits is also its disadvantages - we typically are quite productive in it and so don't feel the need to hire as many people in the team. Before LLM's were a thing we found we were wasting less time with boilerplate in general than our C# code for example. YMMV.

You're right that it's a second-class citizen.

This isn't true, C# has been adding new ABI features that didn't interact correctly with F# until the compiler and tooling catched up. For example, the spanification of C# was a huge a pain point and it still is when it comes to tooling.

For example, F# used to crash the CLR with InvalidProgramException when setting C# `init` properties. [1] It took almost three years, I think, to release the fix.

[1]: https://github.com/fsharp/fslang-suggestions/issues/904

Another rough example would be spans, and their more general feature, byref-like types (ref struct). These required plenty of compiler support, as they've got special lifetime rules (and more pending to implement `scoped`), they are banned as generic type arguments, and they require ignoring a special Obsolete attribute.

While these were added to F# timely, many language features still break when they interact with them: local functions, computation expressions (even the built-in ones), recursive type inference, and generic intrinsic methods such as `raise`, `defaultof` or `typeof`.

This wouldn't be so bad if C# hadn't "spanified" the shared framework and the entire ecosystem without CLS alternatives for many APIs.

So, these natural F# snippets don't compile:

  let numbers = [| for span in text.EnumerateLines() -> Int32.Parse span |]

  let checkNonEmpty (span: ReadOnlySpan<'T>) =
      if span.Length > 0 then span else failwith "Expected non-empty span."

Since its introduction that CLR has the notion of CLS, the Common Language Subset, that any language targeting the CLR should be able to understand.

Anything in the MSIL or metadata, that isn't part of that, requires additional effort from the respective language to be able to expose those features, and many of the more recent improvements, are more in the sense of CLR meaning C# Language Runtime, than Common Language Runtime.

Generally though, it's pretty easy. Sometimes you'll want to make bindings around various things (not that you need to, but it'll make things smoother).

It's not actually awful, it's just that there's no real documentation of "hey today we're going to take Serilog/whatever and show you how to configure it in F#" style videos, so depending on where your weaknesses lie it can feel frustrating.

What I’d love to see is a hybrid between C# and Rust that has the capabilities of both languages in “layers”.

So business logic would be written in a simple GC variant of the language that feels like C# but the underlying standard library and low-level packages could use Rust-like semantics.

This is already the direction that C# is moving in: it’s getting more and more features related to “ref” and other low-level primitives.

Sadly Rust and C# have fundamental incompatibilities such as different string encodings, so they can’t be directly merged.

How did we ever prioritize implementation inheritance over ADTs?

I don't know, but it was a mistake.

And I think the answer has a lot to do with the expression problem [1] and which kinds of extensibility were needed in the kinds of programs that languages at the time were designed for.

OOP with subtyping and virtual dispatch makes it very easy to define an interface with a set of methods, and then have an open-ended set of concrete classes that all reliably implement those methods. It makes it easy to say "I don't know what data types I'll need yet, but I do know what operations I'll need."

ADTs flip that around. That make it easy to express "I don't know what operations I'll need yet, but I do know what data types I'll need."

For the kinds of simulations that Kristen Nygaard and Bjarne Stroustrup were writing, and then later the large GUI applications that C++ users were building, it seems that the former was more useful than the latter.

[1]: https://journal.stuffwithstuff.com/2010/10/01/solving-the-ex...

Dynamic dispatch is for a fixed set of operations and open-ended data.

ADTs are for a fixed set of data and open-ended operations.

The idea would've been well understood, but if the goal of C++ was "C with classes" or more accurately "C + Simula" then it just wasn't part of the goal. And of course we got 20 years of essentially forgetting that sum types existed outside of ML languages until they were "rediscovered"

Like algebraic data types, multiple inheritance wasn't novel, but what were the big famous languages from that time which showed this was a must have for Bjarne's language?

It's not about what was popular, or that Stroustrup was at Cambridge not Edinburgh (all the exciting Programming Language theory stuff in that era like ML was from Edinburgh as you perhaps know). If ADTs were easy, C++ would have ADTs.

Rust is interesting but the compile times aren't great.

For instance, I use throwaway files instead of REPLs, even when I have access to one. I'm still running small and isolated experiments to build my understanding, but I get to use the editor I'm comfortable with and it's easy to copy the code into my project afterwards.

The other thing I used to use REPLs for was introspection/looking up documentation, which my LSP handles nicely. You can think of the LSP as a sort of REPL integrated seamlessly into the editor; when I have a question, I'll query the LSP by writing a line of dummy code that causes the LSP to generate an annotation with the answer. So for instance if I want to know if `foo` implements a certain trait/interface, I can write a variable declaration like `let x: Box<dyn MyTrait> = Box::new(foo)` and see if my LSP annotated that as a type error. I can do this very quickly and without leaving my editor, so it helps me stay in the flow of things.

https://fuqua.io/CSharpRepl/ For one

That statement was true - until 2016. Times change, Microsoft changed.

Azure has entered the chat.

Microsoft Orleans has entered the chat.

ASP .NET Core has entered the chat.

Ever played Halo online?

Used StackOverflow? (very likely)

Visited any website on Azure? (most likely)

Microsoft Orleans (Virtual Actor framework) powers the Halo server infrastructure since at least 2011 if not sooner, which arguably the Halo series is insanely popular, especially for online gaming. Also powers plenty of Azure itselfs own infrastructure. I've worked on dozens of scalable C# projects, and know plenty of devs from all over who have as well.

Orleans was so good, EA made their own version in Java which was extensively used there as well, though it looks to be dead, but Orleans is as alive as ever.

Not to mention plenty of Azure itself is open source, like say... Azure Functions, which run inside of ASP .NET Web Services... and are... you guessed it, C#. Plenty of services running on that platform.

https://github.com/Azure/azure-functions-host

https://visualstudiomagazine.com/articles/2018/08/22/bing-ne...

https://www.bing.com/version