7 ms·

A hobby audio and text analysis application I've written, with no specific concern for low level performance other than algorithmically, runs 4x as fast in .net

by adzm 1y ago

A hobby audio and text analysis application I've written, with no specific concern for low level performance other than algorithmically, runs 4x as fast in .net10 vs .net8. Pretty much every optimization discussed here applies to that app. Great work, kudos to the dotnet team. C# is, imo, the best cross platform GC language. I really can't think of anything that comes close in terms of performance, features, ecosystem, developer experience.

grumpyprole 1y ago
> C# is, imo, the best cross platform GC language. I really can't think of anything that comes close How about F#? Isn't F# mostly C# with better ergonomics?
- denismenace 1y ago
  He means the runtime ".NET CLR". They have the same runtime.
- Xss3 1y ago
  Lmao, functional programming is far from ergonomic
  - grumpyprole 1y ago
    F# is hardly modern functional programming. It's more like a better python with types. And that's much more ergonomic than C#.
    - ZenoArrow 1y ago
      Python and F# are not very similar. A better comparison is OCaml. F# and OCaml are similar. They're both ML-style functional languages.
      - grumpyprole 1y ago
        I'd much rather code F# than Python, it's more principled, at least at the small scale. But F# is in many ways closer to modern mainstream languages than a modern pure functional language. There's nothing scary about it. You can write F# mostly like Python if you want, i.e. pervasive mutation and side effects, if that's your thing.
        ZenoArrow 1y ago
        If Python is the only language you have to compare other languages to, all other programming languages are going to look like "Python with X and Y differences". It makes no sense to compare Python to F# when OCaml exists and is a far closer relative. F# isn't quite "OCaml on .NET" but it's pretty close.
        grumpyprole 1y ago
        It absolutely does make sense to compare it to the worlds most popular programming language, especially when dismissed as "functional programming". Who benefits from an OCaml comparison? You think F# should be marketed to OCaml users who might want to try dotnet? That's a pretty small market.
        ZenoArrow 1y ago
        Python is the world's most used scripting language, but for application programming languages there are other languages that are widely used and better to compare to F#. For example, C# and Java.
        grumpyprole 1y ago
        F# was pitched by Microsoft to be used in areas where Python dominates, especially for scripting in the finance domain and "rapid application development". So it doesn't make sense at all that C# and Java are a "better comparison".
    - raincole 1y ago
      It's so weird to describe F# as "Python with Types." First of all, Python is Python with Types. And C# is much more similar to Python than F# is.
      - grumpyprole 1y ago
        It all depends on the lens one chooses to view them. None of them are really "functional programming" in the truly modern sense, even F#. As more and more mainstream languages get pattern matching and algebraic data types (such as Python), feature lambdas and immutable values, then these languages converge. However, you don't really get the promises of functional programming such as guaranteed correct composition and easier reasoning/analysis, for that one needs at least purity and perhaps even totality. That carries the burden of proof, which means things get harder and perhaps too hard for some (e.g. the parent poster).
        maleldil 1y ago
        If purity is a requirement for "real" functional programming, then OCaml or Clojure aren't functional. Regarding totality, even Haskell has partial functions and exceptions.
        grumpyprole 1y ago
        Both OCaml and Clojure are principled and well designed languages, but they are mostly evolutions of Lisp and ML from the 70s. That's not where functional programming is today. Both encourage a functional style, which is good. And maybe that's your definition of a "functional language". But I think that definition will get increasingly less useful over time.
        maleldil 1y ago
        What is an example of a real functional language for you?
        1y ago
  - samus 1y ago
    That really depends on your preferred coding style.
  - CharlieDigital 1y ago
    Exactly what I've observed in practice because most devs have no background in writing functional code and will complain when asked to do so. Passing or returning a function seems a foreign concept to many devs. They know how to use lambda expressions, but rarely write code that works this way. We adopted ErrorOr[0] and have a rule that core code must return ErrorOr<T>. Devs have struggled with this and continue to misunderstand how to use the result type. [0] https://github.com/amantinband/error-or https://github.com/amantinband/error-or
    - raddan 1y ago
      Cool. I’ll have to check this out. I often find myself rolling my own “option type” when writing C#. Agreed with getting developers to see the value. The most convincing argument I’ve been able to make thus far has been “isn’t it embarrassing when your code explodes in production? Imagine being able to find those errors at compile time.” The few who actually understand the distinction between “compile time” and “run time” can usually appreciate why you might want it.
  - physPop 1y ago
    honestly this sounds like you've never really done it. FP is much better for ergonomics, developer productivity, correctness. All the important things when writing code.
    - Hendrikto 1y ago
      I like FP, but your claim is just as baseless as the parent’s. If FP was really better at “all the important things”, why is there such a wide range of opinions, good but also bad? Why is it still a niche paradigm?
      - raddan 1y ago
        It’s niche because the vast, vast majority of programmers just continue to do what they know or go with the crowd. I spend roughly 50% of my time doing FP and 50% doing imperative (most OOP) programming. I am dramatically more effective writing functional code. Like other posters, I am not going to claim that it is better at all things. OOP’s approach to polymorphism and extensibility is brilliant. But I also know that nearly all of the mistakes I make have to do with not thinking carefully enough about mutability or side-effects, features that are (mostly) verboten in FP. It takes some effort to re-learn how to do things (recursion all the things!) but once you’ve done it, you realize how elegant your code can be. Many of my FP programs are also effectively proofs of their own correctness, which is not a property that many other language styles can offer. Here’s an appropriate PG essay: https://paulgraham.com/avg.html https://paulgraham.com/avg.html
- raincole 1y ago
  Personally I love F#, but I feel the community is probably even smaller than OCaml...
  - gixco 1y ago
    I once got a temporary F# role without any F# experience simply by having 7 YoE with C# and the knowledge that F# exists. As much as I'd like to do more with it, the "just use F#" idea flaunted in this thread is a distant pipe dream for the vast majority of teams.
- actionfromafar 1y ago
  It is but in practice it’s very hard to find programmers for it.
devjab 1y ago
Having worked with C# professionally for a decade, going through the changes with LINQ, async/await, Roslyn, and the rise of .NET Core, to .NET Core becoming .NET, I disagree. I certainly think that C# is a great tool and that it’s the best it has ever been. It’s also relies on very implicit behaviour, it is build upon OOP design principles and a bunch of “needless” abstraction. Things I personally have come to view as anti-patterns over the years. This isn’t because I specifically dislike C#, you could find me saying something similar about Java. I suspect that the hidden indirection and runtime magic, may be part of why you love the language. In my experience, however, it leads to poor observability, opaque control flow, and difficult debugging sessions in every organisation and company I’ve ever worked for. It’s fair to argue that this is because the people working with C# are bad at software engineering. Similar to how Uncle Bob will always be correct when he calls teams out for getting his principles wrong. To me that means the language itself has a poor design fit for software development in 2025. Which is probably why we see more and more Go adoption, due to its explicit philosophies. Though to be fair, Python seems to be “winning” as far as adoption goes in the cross platform GC language space. Having worked with Django-Ninja I can certainly see why. It’s so productive, and with stuff like Pyrefly, UV and Ruff it’s very easy to make it a YAGNI experience with decent type control. I am happy you enjoy C# though, and it’s great to see that it is evolving. If they did more to enhance the developer experience so that people were less inclined to do bad engineering on a thursday afternoon after a long day of useless meetings. Then I would probably agree with you. I'm not sure any of the changes going toward .NET 10 are going in that direction though.
- OtomotO 1y ago
  I am paid to work in Java and C# among Go, Rust, Kotlin, Scala and I wholeheartedly agree. I hate the implicitness of Spring Boot, Quarkus etc. as much as the one in C# projects. All these magic annotations that save you a few lines of code until they don't, because you get runtime errors due to incompatible annotations. And then it takes digging through pages of docs or even reporting bugs on repos instead of just fixing a few explicit lines. Explicitness and Verbosity are orthogonal concepts mostly!
  - npodbielski 1y ago
Nullabillity 1y ago
> I really can't think of anything that comes close in terms of [...] developer experience. Of all the languages that I have to touch professionally, C# feels by far the most opaque and unusable. Documentation tends to be somewhere between nonexistant and useless, and MSDN's navigation feels like it was designed by a sadist. (My gold standard would be Rustdoc or Scala 2.13 era Scaladoc, but even Javadoc has been.. fine for basically forever.) For third-party libraries it tends to be even more dire and inconsistent. The Roslyn language server crashes all the time, and when it does work.. it doesn't do anything useful? Like cross-project "go-to-definition" takes me to either a list of members or a decompiled listing of source code, even when I have the actual source code right there! (I know there's this thing called "SourceLink" which is.. supposed to solve this? I think? But I've never seen it actually use it in practice.) Even finding where something comes from is ~impossible without the language server, because `using` statements don't mention.. what they're even importing. (Assuming that you have them at all. Because this is also the company that thought project-scoped imports were a good idea!) And then there's the dependency injection, where I guess someone thought it would be cute if every library just had an opaque extension method on the god object, that didn't tell you anything about what it actually did. So good luck finding where the actual implementation of anything is.
- Guillaume86 1y ago
  Try "go to implementation" in place of go to definition.
- Rohansi 1y ago
  I almost exclusively work in C# and have never experienced the Roslyn crashes you mentioned. I am using either Rider or Visual Studio though. > Like cross-project "go-to-definition" takes me to either a list of members or a decompiled listing of source code, even when I have the actual source code right there! If these are projects you have in the same solution then it should never do this. I would only expect this to happen if either symbol files or source files are missing.
  - CharlieDigital 1y ago
    I use VS Code on macOS for all of my C# code over the last 5 years and also never experienced Roslyn crashes.
munchler 1y ago
Except for F#, which also gets all the .NET10 cross-platform GC improvements for free and is a better programming language than C#.
- physPop 1y ago
  +1 F# is criminally under-used
  - throw954387543 1y ago
    I've used it, and am still using it, to generate lots of value in a very large org. Having a language where I can bring Go, Node, etc developers over and get relatively better performance without having to teach OOP and all the implicit conventions that are on the C# side is a bit like a cheat code. With modern .NET, its better than Java perf, with better GC, and having the ability to code generic Python/JS looking code whilst still having type checking (HM inference). There are C# libraries we do use but with standard templates for those few with patterns to interface to mostly F# layers you can get very far in a style of code more fitting of a higher more dynamic language. Ease of use vs perf, its kind of in the middle - and it has also benefited from C# features (e.g. spans recently) Its not one feature with F# IMO, its little things that add up which generally is the reason it is hard to convince someone to use it. To the point when the developers (under my directive) had to write two products in C# they argued with me to switch back.
  - lostmsu 1y ago
    I used it for many years but ended up switching to C#. The language needs better refactoring tools. And for that it needs something like Roslyn. The existing compiler library is too slow.
    - munchler 1y ago
      That would be nice, but refactoring canonical F# is still far easier than C# due to its referential transparency. https://dev.to/ruizb/function-purity-and-referential-transparency-7h1 https://dev.to/ruizb/function-purity-and-referential-transpa...
ComputerGuru 1y ago
C# will be a force to reckon with if/when discriminated unions finally land as a language feature.
- CharlieDigital 1y ago
  I think people who last looked at C# 10 years ago or haven't adapted to new language features seriously don't know how good C# is these days. Switch expressions with pattern matching are absolutely killer[0] for its terseness. Also, it is possible to use OneOf[1] and Dunet[2] to get access to DU [0] https://timdeschryver.dev/blog/pattern-matching-examples-in-csharp https://timdeschryver.dev/blog/pattern-matching-examples-in-... [1] https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/OneOf [2] https://github.com/domn1995/dunet https://github.com/domn1995/dunet
  - ComputerGuru 1y ago
    I write C# and rust fulltime. Native discriminated unions (and their integration throughout the ecosystem) are often the deciding factor when choosing rust over C#.
    - CharlieDigital 1y ago
      Very hard to imagine teams cross shopping C# and Rust and DU's being the deciding factor. The tool chains, workflows, and use cases are just so different, IMO. What heuristics were your team using to decide between the two?
    - azkalam 1y ago
      This surprises me. If you want the .NET ecosystem and GC conveniences, there is already F#. If you want no GC and RAII-style control, then you would already pick Rust.
  - mhh__ 1y ago
    > OneOf I do like/respect C# but come on now. I know they're fixing it but the rest of the language was designed the same way and thus still has this vestigial layer of OOP-hubris
buzzin__ 1y ago
Or you can use the "C# without the line noise", which goes under the name of F#.
- bonesss 1y ago
  Yeah, but if you use F# that then you’ll have all the features C# has been working on for years, only in complete and mature versions, and also an opinionated language encouraging similar styles between teams instead of wild dialects of kinda-sorta immutablity and kinda-sorta DU’s, and everything in between, requiring constant vigilance and training… ;) I’m a fan of all three languages, but C# spent the first years relearning why Visual Basic was very productive and the last many years learning why OCaml was chosen to model F# after. It’s landed in a place where I can make beautiful code the way I need to, but the mature libraries I’ve crafted to make it so simply aren’t recreate-able by most .Net devs, and the level of micro-managing it takes to maintain across groups is a line-by-line slog against orthodoxy and seeming ‘shortcuts’, draining the productivity those high level guarantees should provide. And then there’s the impact of EF combined with sloppy Linq which makes every junior/consultant LOC a potentially ticking time bomb without more line-by-line, function-by-function slog. Compiler guarantees mean a lot.
bob1029 1y ago
> I really can't think of anything that comes close in terms of performance, features, ecosystem, developer experience. This is also why I prefer to use Unity over all other engines by an incredible margin. The productivity gains of using a mature C# scripting ecosystem in a tight editor loop are shocking compared to the competition. Other engines do offer C# support, but if I had to make something profitable to save my own standard of living the choice is obvious. There's only two vendors that offer built-in SIMD accelerated linear math libraries capable of generating projection matrices out of the box. One is Microsoft and the other is Apple. The benefits of having stuff like this baked into your ecosystem are very hard to overstate. The amount of time you could waste looking for and troubleshooting primitives like this can easily kill an otherwise perfect vision.
5ersi 1y ago
Java? Is supported on more platforms, has more developers, more jobs, more OSS projects, is more widely used (Tiobe 2024). Performance was historically better, but c# caught up.
- mrsmrtss 1y ago
  Reified generics, value types, LINQ are just a few things that you would miss when going to Java. Also Java and .NET are both big, that's not a real argument here. Not that I would trust Tiobe index too much, but as of 2025 September C# is right behind Java at 5th place.
- throw45678943 1y ago
  My experience was that .NET programs were typically more tunable for greater perf than Java for many years now even if it didn't come free out of the box which generally is what matters with performance. The ability to optimise further what needs to be optimised means that generally you are faster for your business domain than the alternative - with Java code it generally is harder and/or less ergonomic to do this. For example just having value types and reified generics as a combination meant you could write generic code against value types which usually meant for hot algorithmic loops or certain data structures a big win w.r.t memory and CPU consumption. For example for a collection type critical to an app I wrote many years ago the use of value types would almost half the memory footprint compared to the best Java one I could find, and was somewhat faster with less cache misses. The Java alternative wasn't an amateur one either but they couldn't get the perf out of it even with significant effort. It also last time I checked doesn't have a value decimal type for financial math which IMO can be a significant performance loss for financial/money based systems. Anything with math, and lots of processing/data structures for example I would find .NET significantly faster after doing the optimisation work. If I had to choose the 2 targets these days I would find .NET in general an easier target w.r.t performance. Of course perf isn't everything depending on the domain.
whoknowsidont 1y ago
>runs 4x as fast in .net10 vs .net8. Is this open source? Do you have numbers? I've been coding in .NET since it was "a thing" and frankly I'm having trouble mapping the optimizations to a local application at that magnitude. The optimizations are seen at scale, they really won't mean much for your local application. Not a 3x+ improvement at least.

by adzm 1y ago

grumpyprole 1y ago

> C# is, imo, the best cross platform GC language. I really can't think of anything that comes close How about F#? Isn't F# mostly C# with better ergonomics?

denismenace 1y ago
He means the runtime ".NET CLR". They have the same runtime.
Xss3 1y ago
Lmao, functional programming is far from ergonomic
- grumpyprole 1y ago
  F# is hardly modern functional programming. It's more like a better python with types. And that's much more ergonomic than C#.
  - ZenoArrow 1y ago
    Python and F# are not very similar. A better comparison is OCaml. F# and OCaml are similar. They're both ML-style functional languages.
    - grumpyprole 1y ago
      I'd much rather code F# than Python, it's more principled, at least at the small scale. But F# is in many ways closer to modern mainstream languages than a modern pure functional language. There's nothing scary about it. You can write F# mostly like Python if you want, i.e. pervasive mutation and side effects, if that's your thing.
      - ZenoArrow 1y ago
        If Python is the only language you have to compare other languages to, all other programming languages are going to look like "Python with X and Y differences". It makes no sense to compare Python to F# when OCaml exists and is a far closer relative. F# isn't quite "OCaml on .NET" but it's pretty close.
        grumpyprole 1y ago
        It absolutely does make sense to compare it to the worlds most popular programming language, especially when dismissed as "functional programming". Who benefits from an OCaml comparison? You think F# should be marketed to OCaml users who might want to try dotnet? That's a pretty small market.
        ZenoArrow 1y ago
        Python is the world's most used scripting language, but for application programming languages there are other languages that are widely used and better to compare to F#. For example, C# and Java.
        grumpyprole 1y ago
        F# was pitched by Microsoft to be used in areas where Python dominates, especially for scripting in the finance domain and "rapid application development". So it doesn't make sense at all that C# and Java are a "better comparison".
  - raincole 1y ago
    It's so weird to describe F# as "Python with Types." First of all, Python is Python with Types. And C# is much more similar to Python than F# is.
    - grumpyprole 1y ago
      It all depends on the lens one chooses to view them. None of them are really "functional programming" in the truly modern sense, even F#. As more and more mainstream languages get pattern matching and algebraic data types (such as Python), feature lambdas and immutable values, then these languages converge. However, you don't really get the promises of functional programming such as guaranteed correct composition and easier reasoning/analysis, for that one needs at least purity and perhaps even totality. That carries the burden of proof, which means things get harder and perhaps too hard for some (e.g. the parent poster).
      - maleldil 1y ago
        If purity is a requirement for "real" functional programming, then OCaml or Clojure aren't functional. Regarding totality, even Haskell has partial functions and exceptions.
        grumpyprole 1y ago
        Both OCaml and Clojure are principled and well designed languages, but they are mostly evolutions of Lisp and ML from the 70s. That's not where functional programming is today. Both encourage a functional style, which is good. And maybe that's your definition of a "functional language". But I think that definition will get increasingly less useful over time.
        maleldil 1y ago
        What is an example of a real functional language for you?
        1y ago
- samus 1y ago
  That really depends on your preferred coding style.
- CharlieDigital 1y ago
  Exactly what I've observed in practice because most devs have no background in writing functional code and will complain when asked to do so. Passing or returning a function seems a foreign concept to many devs. They know how to use lambda expressions, but rarely write code that works this way. We adopted ErrorOr[0] and have a rule that core code must return ErrorOr<T>. Devs have struggled with this and continue to misunderstand how to use the result type. [0] https://github.com/amantinband/error-or https://github.com/amantinband/error-or
  - raddan 1y ago
    Cool. I’ll have to check this out. I often find myself rolling my own “option type” when writing C#. Agreed with getting developers to see the value. The most convincing argument I’ve been able to make thus far has been “isn’t it embarrassing when your code explodes in production? Imagine being able to find those errors at compile time.” The few who actually understand the distinction between “compile time” and “run time” can usually appreciate why you might want it.
- physPop 1y ago
  honestly this sounds like you've never really done it. FP is much better for ergonomics, developer productivity, correctness. All the important things when writing code.
  - Hendrikto 1y ago
    I like FP, but your claim is just as baseless as the parent’s. If FP was really better at “all the important things”, why is there such a wide range of opinions, good but also bad? Why is it still a niche paradigm?
    - raddan 1y ago
      It’s niche because the vast, vast majority of programmers just continue to do what they know or go with the crowd. I spend roughly 50% of my time doing FP and 50% doing imperative (most OOP) programming. I am dramatically more effective writing functional code. Like other posters, I am not going to claim that it is better at all things. OOP’s approach to polymorphism and extensibility is brilliant. But I also know that nearly all of the mistakes I make have to do with not thinking carefully enough about mutability or side-effects, features that are (mostly) verboten in FP. It takes some effort to re-learn how to do things (recursion all the things!) but once you’ve done it, you realize how elegant your code can be. Many of my FP programs are also effectively proofs of their own correctness, which is not a property that many other language styles can offer. Here’s an appropriate PG essay: https://paulgraham.com/avg.html https://paulgraham.com/avg.html
raincole 1y ago
Personally I love F#, but I feel the community is probably even smaller than OCaml...
- gixco 1y ago
  I once got a temporary F# role without any F# experience simply by having 7 YoE with C# and the knowledge that F# exists. As much as I'd like to do more with it, the "just use F#" idea flaunted in this thread is a distant pipe dream for the vast majority of teams.
actionfromafar 1y ago
It is but in practice it’s very hard to find programmers for it.

devjab 1y ago

Having worked with C# professionally for a decade, going through the changes with LINQ, async/await, Roslyn, and the rise of .NET Core, to .NET Core becoming .NET, I disagree. I certainly think that C# is a great tool and that it’s the best it has ever been. It’s also relies on very implicit behaviour, it is build upon OOP design principles and a bunch of “needless” abstraction. Things I personally have come to view as anti-patterns over the years. This isn’t because I specifically dislike C#, you could find me saying something similar about Java. I suspect that the hidden indirection and runtime magic, may be part of why you love the language. In my experience, however, it leads to poor observability, opaque control flow, and difficult debugging sessions in every organisation and company I’ve ever worked for. It’s fair to argue that this is because the people working with C# are bad at software engineering. Similar to how Uncle Bob will always be correct when he calls teams out for getting his principles wrong. To me that means the language itself has a poor design fit for software development in 2025. Which is probably why we see more and more Go adoption, due to its explicit philosophies. Though to be fair, Python seems to be “winning” as far as adoption goes in the cross platform GC language space. Having worked with Django-Ninja I can certainly see why. It’s so productive, and with stuff like Pyrefly, UV and Ruff it’s very easy to make it a YAGNI experience with decent type control. I am happy you enjoy C# though, and it’s great to see that it is evolving. If they did more to enhance the developer experience so that people were less inclined to do bad engineering on a thursday afternoon after a long day of useless meetings. Then I would probably agree with you. I'm not sure any of the changes going toward .NET 10 are going in that direction though.

OtomotO 1y ago
I am paid to work in Java and C# among Go, Rust, Kotlin, Scala and I wholeheartedly agree. I hate the implicitness of Spring Boot, Quarkus etc. as much as the one in C# projects. All these magic annotations that save you a few lines of code until they don't, because you get runtime errors due to incompatible annotations. And then it takes digging through pages of docs or even reporting bugs on repos instead of just fixing a few explicit lines. Explicitness and Verbosity are orthogonal concepts mostly!
- npodbielski 1y ago

Nullabillity 1y ago

> I really can't think of anything that comes close in terms of [...] developer experience. Of all the languages that I have to touch professionally, C# feels by far the most opaque and unusable. Documentation tends to be somewhere between nonexistant and useless, and MSDN's navigation feels like it was designed by a sadist. (My gold standard would be Rustdoc or Scala 2.13 era Scaladoc, but even Javadoc has been.. fine for basically forever.) For third-party libraries it tends to be even more dire and inconsistent. The Roslyn language server crashes all the time, and when it does work.. it doesn't do anything useful? Like cross-project "go-to-definition" takes me to either a list of members or a decompiled listing of source code, even when I have the actual source code right there! (I know there's this thing called "SourceLink" which is.. supposed to solve this? I think? But I've never seen it actually use it in practice.) Even finding where something comes from is ~impossible without the language server, because `using` statements don't mention.. what they're even importing. (Assuming that you have them at all. Because this is also the company that thought project-scoped imports were a good idea!) And then there's the dependency injection, where I guess someone thought it would be cute if every library just had an opaque extension method on the god object, that didn't tell you anything about what it actually did. So good luck finding where the actual implementation of anything is.

Guillaume86 1y ago
Try "go to implementation" in place of go to definition.
Rohansi 1y ago
I almost exclusively work in C# and have never experienced the Roslyn crashes you mentioned. I am using either Rider or Visual Studio though. > Like cross-project "go-to-definition" takes me to either a list of members or a decompiled listing of source code, even when I have the actual source code right there! If these are projects you have in the same solution then it should never do this. I would only expect this to happen if either symbol files or source files are missing.
- CharlieDigital 1y ago
  I use VS Code on macOS for all of my C# code over the last 5 years and also never experienced Roslyn crashes.

munchler 1y ago

Except for F#, which also gets all the .NET10 cross-platform GC improvements for free and is a better programming language than C#.

physPop 1y ago
+1 F# is criminally under-used
- throw954387543 1y ago
  I've used it, and am still using it, to generate lots of value in a very large org. Having a language where I can bring Go, Node, etc developers over and get relatively better performance without having to teach OOP and all the implicit conventions that are on the C# side is a bit like a cheat code. With modern .NET, its better than Java perf, with better GC, and having the ability to code generic Python/JS looking code whilst still having type checking (HM inference). There are C# libraries we do use but with standard templates for those few with patterns to interface to mostly F# layers you can get very far in a style of code more fitting of a higher more dynamic language. Ease of use vs perf, its kind of in the middle - and it has also benefited from C# features (e.g. spans recently) Its not one feature with F# IMO, its little things that add up which generally is the reason it is hard to convince someone to use it. To the point when the developers (under my directive) had to write two products in C# they argued with me to switch back.
- lostmsu 1y ago
  I used it for many years but ended up switching to C#. The language needs better refactoring tools. And for that it needs something like Roslyn. The existing compiler library is too slow.
  - munchler 1y ago
    That would be nice, but refactoring canonical F# is still far easier than C# due to its referential transparency. https://dev.to/ruizb/function-purity-and-referential-transparency-7h1 https://dev.to/ruizb/function-purity-and-referential-transpa...

ComputerGuru 1y ago

C# will be a force to reckon with if/when discriminated unions finally land as a language feature.

CharlieDigital 1y ago
I think people who last looked at C# 10 years ago or haven't adapted to new language features seriously don't know how good C# is these days. Switch expressions with pattern matching are absolutely killer[0] for its terseness. Also, it is possible to use OneOf[1] and Dunet[2] to get access to DU [0] https://timdeschryver.dev/blog/pattern-matching-examples-in-csharp https://timdeschryver.dev/blog/pattern-matching-examples-in-... [1] https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/OneOf [2] https://github.com/domn1995/dunet https://github.com/domn1995/dunet
- ComputerGuru 1y ago
  I write C# and rust fulltime. Native discriminated unions (and their integration throughout the ecosystem) are often the deciding factor when choosing rust over C#.
  - CharlieDigital 1y ago
    Very hard to imagine teams cross shopping C# and Rust and DU's being the deciding factor. The tool chains, workflows, and use cases are just so different, IMO. What heuristics were your team using to decide between the two?
  - azkalam 1y ago
    This surprises me. If you want the .NET ecosystem and GC conveniences, there is already F#. If you want no GC and RAII-style control, then you would already pick Rust.
- mhh__ 1y ago
  > OneOf I do like/respect C# but come on now. I know they're fixing it but the rest of the language was designed the same way and thus still has this vestigial layer of OOP-hubris

buzzin__ 1y ago

Or you can use the "C# without the line noise", which goes under the name of F#.

bonesss 1y ago
Yeah, but if you use F# that then you’ll have all the features C# has been working on for years, only in complete and mature versions, and also an opinionated language encouraging similar styles between teams instead of wild dialects of kinda-sorta immutablity and kinda-sorta DU’s, and everything in between, requiring constant vigilance and training… ;) I’m a fan of all three languages, but C# spent the first years relearning why Visual Basic was very productive and the last many years learning why OCaml was chosen to model F# after. It’s landed in a place where I can make beautiful code the way I need to, but the mature libraries I’ve crafted to make it so simply aren’t recreate-able by most .Net devs, and the level of micro-managing it takes to maintain across groups is a line-by-line slog against orthodoxy and seeming ‘shortcuts’, draining the productivity those high level guarantees should provide. And then there’s the impact of EF combined with sloppy Linq which makes every junior/consultant LOC a potentially ticking time bomb without more line-by-line, function-by-function slog. Compiler guarantees mean a lot.

bob1029 1y ago

> I really can't think of anything that comes close in terms of performance, features, ecosystem, developer experience. This is also why I prefer to use Unity over all other engines by an incredible margin. The productivity gains of using a mature C# scripting ecosystem in a tight editor loop are shocking compared to the competition. Other engines do offer C# support, but if I had to make something profitable to save my own standard of living the choice is obvious. There's only two vendors that offer built-in SIMD accelerated linear math libraries capable of generating projection matrices out of the box. One is Microsoft and the other is Apple. The benefits of having stuff like this baked into your ecosystem are very hard to overstate. The amount of time you could waste looking for and troubleshooting primitives like this can easily kill an otherwise perfect vision.

5ersi 1y ago

Java? Is supported on more platforms, has more developers, more jobs, more OSS projects, is more widely used (Tiobe 2024). Performance was historically better, but c# caught up.

mrsmrtss 1y ago
Reified generics, value types, LINQ are just a few things that you would miss when going to Java. Also Java and .NET are both big, that's not a real argument here. Not that I would trust Tiobe index too much, but as of 2025 September C# is right behind Java at 5th place.
throw45678943 1y ago
My experience was that .NET programs were typically more tunable for greater perf than Java for many years now even if it didn't come free out of the box which generally is what matters with performance. The ability to optimise further what needs to be optimised means that generally you are faster for your business domain than the alternative - with Java code it generally is harder and/or less ergonomic to do this. For example just having value types and reified generics as a combination meant you could write generic code against value types which usually meant for hot algorithmic loops or certain data structures a big win w.r.t memory and CPU consumption. For example for a collection type critical to an app I wrote many years ago the use of value types would almost half the memory footprint compared to the best Java one I could find, and was somewhat faster with less cache misses. The Java alternative wasn't an amateur one either but they couldn't get the perf out of it even with significant effort. It also last time I checked doesn't have a value decimal type for financial math which IMO can be a significant performance loss for financial/money based systems. Anything with math, and lots of processing/data structures for example I would find .NET significantly faster after doing the optimisation work. If I had to choose the 2 targets these days I would find .NET in general an easier target w.r.t performance. Of course perf isn't everything depending on the domain.

whoknowsidont 1y ago

>runs 4x as fast in .net10 vs .net8. Is this open source? Do you have numbers? I've been coding in .NET since it was "a thing" and frankly I'm having trouble mapping the optimizations to a local application at that magnitude. The optimizations are seen at scale, they really won't mean much for your local application. Not a 3x+ improvement at least.