14 ms·

Why F#?

• nickpeterson 1y ago
  Because it’s great, and people that think otherwise are dead to me.
  • MrMcCall 1y ago
    Curried functions combined with that magnificent pipe operator, overlaid on the .NET runtime. Don Syme et al knocked it out of the park. It's the one programming language that changed how I think about programming. I'm only talking about the version before type providers. Then it got messy. Before that, we could (and I did) recompile fsi.exe to do some custom prompt manipulation. It was a slog, but it worked, but then Microsoft faded from my life. Still, that early version (I believe 2.0) F# is just magnificent.
    • munchler 1y ago
      F# is up to version 9 now, and has only improved over time, IMHO. Type providers are a very small part of the story and can be avoided entirely if you want.
      • jasonthorsness 1y ago
        I tried F# when it was first released and was not a fan, but it sounds like that impression is a little outdated. C# has come so far in that time it’s almost a new language. I’ll have to take another look.
        • MrMcCall 1y ago
          I don't know what C# has for an interactive prompt nowadays, but F#'s commandline environment, via its fsi.exe, was a revelation back then. It prevented having to have entire solutions to contain test projects to explore different areas of the vast .NET framework, especially when just learning how to use specific methods or objects.
          • DeathArrow 1y ago
            For C# you can use LINQpad, a .NET scratchpad. You can even mix and match F# in it.
      • speed_spread 1y ago
        Why would type providers be avoided? It seemed to me like a nice metaprogramming feature, akin to what Zig does with comptime types (except runtime?)
        • Akronymus 1y ago
          Type providers can be extremely brittle IME. Altough, I guess if it is referring to version controlled example data that probably works better than referring to a DB or something like that directly that the dev has to provide.
        • munchler 1y ago
          Type providers are very powerful but involve running arbitrary external software at compile-time (e.g. a SQL Server or Postgres database). This can be difficult to set up and configure reliably in a multi-person project.
          • owlstuffing 1y ago
            You're not entirely wrong, but when it comes to SQL, the trade-offs are unavoidable. You either embrace a conventional, not-SQL approach with all its limitations, or you treat the database as the single source of truth (SSoT). Both have downsides, but configuring a designated local or shared database for this purpose is no less reliable than conventional approaches. As for type providers in general, I don't think databases are the best example of their typical use case. Most type providers don’t interact with external systems; they usually parse schemas, configuration files, or other structured data to generate strongly typed representations. The database-backed approach is just one variant, not the norm.
        • MrMcCall 1y ago
          For me, I already had all the featues I needed. Plus, I'm not going to be downloading, configuring, or running any separate code at runtime. The project is the project, it's going to process some files, communicate with some services, and communicate with the UI, if any. If I need to consume a service, it should be defined such that I manifest the interface module (perhaps via WCF) and then connect to it progressively from stub to ever greater functionality in test to final implementation. Trying to write a program to do all that at runtime is not sensible, IMO. Metaprogramming via reflection, however, was useful for exploring the vast .NET framework, and I used those to great effect, especially in exploring .NET's various UI frameworks (WinForms and Silverlight), but never to create code at runtime via the emit functionality. No, that's my job: to emit code that is tested and works and is comprehensible.
      • MrMcCall 1y ago
        I don't doubt it, but I don't run Microsoft software any more. I've seen enough embrace, extend, and extinguish in my lifetime to not depend on them for my code's execution environment. My current work needs nothing the .NET environment provides that I can't use python's standard libraries to get done, or bash and C if I need to. But I'm lucky to no longer be in a corporate environment, so I don't need to consume commercial services, which was much easier using WCF within .NET. Back in my previous life, constructing n-tiered services on top of SqlServer using WCF was slick, indeed. To any who are interested in how to construct such n-tiered applications simply but securely and precisely, I highly suggest Juval Lowy's IDesign system. He had three specific videos that I watched three or four times each until I understood his distillation of his vast expertise. Of course, Mr. Lowy is one of the co-designers of WCF, which was an excellent bit of tech.
        • munchler 1y ago
          FWIW, F# is an open source project controlled by the F# Software Foundation, the .NET Foundation, and Microsoft.
          • MrMcCall 1y ago
            > controlled by the F# Software Foundation, the .NET Foundation, and Microsoft. It is controlled by Microsoft. It's not going on my Linux or BSD boxes. I know how they work, and I want nothing to do with them.
            • lunarlull 1y ago
              Do you make sure to run a linux kernel with all the MS stuff patched out also?
              • MrMcCall 1y ago
                No, but if it came in the standard install there's nothing I can do about it save spending hours and hours auditing my install. I don't do that kind of thing nowadays. Separately installed software? Not a bit of it.
    • akkad33 1y ago
      It has great ideas but because of all these conveniences it is very bad for performance based programming making it slower than C#. I like the ideas in Roc language to make functional programming as fast as imperative by controlling allocations in things like closures
      • MrMcCall 1y ago
        That's interesting. Thanks for the heads-up.
  • deleted 1y ago
    [deleted]
  • turtlebits 1y ago
    It might be great, but IME, MSFT docs and tooling are subpar, and anything dotnet related is/was a disaster.
• eknkc 1y ago
  As far as I can tell F# is one of those things where every single user is extremely happy. This happens rarely and I really am curious about the thing but never had time to get into it. I'm also pretty well versed in the .net ecosystem so it's probably gonna be easy. Any tips? What kind of workflows might benefit the most if I were to incorporate it (to learn..)?
  • piokoch 1y ago
    "As far as I can tell F# is one of those things where every single user is extremely happy" Isn't it because language has rather small community of passionate people, who are devoted to their language of choice? F# popularity is somewhere between CHILL, Clipper and Raku langs, that are probably as obscure as F# for typical software dev.
    • psychoslave 1y ago
      I know Raku from Perl fame, and F# because it’s Microsoft, but CHILL and Clipper are totally new to me, so in my own humble experience these two latter look far more obscure. :D
      • orthoxerox 1y ago
        Clipper is old. It's dBase/xBase/FoxPro, pre-SQL DBMSs.
    • int_19h 1y ago
      I'm pretty sure that there's more production code written in F# than in all those other three combined.
    • DeathArrow 1y ago
      If we consider number of jobs, it's probably on par with Rust.
  • munchler 1y ago
    F# shines on the back end, where its functional-first style is very adept at crunching data. Think about data flows in your system: Any place where you use LINQ in C# today to select/filter/transform data might be even better in F#. Parsing is also a great F# use case (e.g. parser combinators), although a fairly narrow niche.
• aloisdg 1y ago
  F# is corporate friendly ML. Love it.
• lihaoyi 1y ago
  I learned F# in 2013 and had a lot of fun with it, some of that code remains on Github (e.g. a 2D platformer game for windows https://github.com/lihaoyi/FSharpMetro/tree/master/Application https://github.com/lihaoyi/FSharpMetro/tree/master/Applicati...). My experience was that it was a surprisingly nice language with a surprisingly warty user experience: papercuts ranging from naming conventions and function call styles (`|> List.map` vs `.Select`), basic syntax (`foo.[0]` to lookup arrays), type system features (F# doesn't have covariance/contravariance even though C# does), IDE support (back then was only Visual Studio, whose support for F# was inferior to C#). Ended up settling on Scala after that, as a language with its own Warts, but one that somehow managed to feel a more cohesive than F# did despite having largely the same featureset and positioning. F# was my first functional language and one that changed how I look at programming, but at the same time I'm happy to not actually have to use it for serious programming!
  • munchler 1y ago
    F# supports both functional and OO call styles. That's why you have both `|> List.map` and `.Select`. It can be a bit confusing at first, but the interoperability with C# is worth it. Array lookup in modern F# is just `foo[0]`. Subtyping is much less common in F# than in C#, so the need for covariance/contravariance is correspondingly lower. Personally, I've never needed it. F# support in Visual Studio is now excellent. You can also develop F# in VS Code.
  • bozhidar 1y ago
    I think these days F# is probably a big more polished than what you remember, so perhaps it's worth giving it another shot. Being a hosted language always requires certain compromises (something that was also apparent in Scala). I used to do Scala professionally in its early days, but for me it felt it added just as much complexity as it addressed. I focused on Clojure back then (on the FP side at least), and I do think that F# probably brings more to the table than Scala. (if one is not constrained to Java, that is) The tooling story is not great, but I've almost never seen great tooling for a language that's not super popular. I'm guessing what you get today with Rider is more or less as good as what VS has to offer.
  • djtango 1y ago
• Aldipower 1y ago
  "Why the F#?" perhaps would be a better title. :-)
• oguz-ismail 1y ago
  >whitespace is significant, like in Python hard pass
  • voidUpdate 1y ago
    I was with it until I heard no braces :/
    • pjc50 1y ago
      I have some good news for you about C#.
      • voidUpdate 1y ago
        I love C#, its a great language
        • ahoka 1y ago
          Perfect for blub programmers!
      • BeetleB 1y ago
        C# doesn't require braces...?
    • deleted 1y ago
      [deleted]
  • fire_lake 1y ago
    Static typing removes the downside of whitespace. Oh, and every language with line comments (so most of them) has significant whitespace.
    • AnimalMuppet 1y ago
      > Static typing removes the downside of whitespace. How so? > Oh, and every language with line comments (so most of them) has significant whitespace. Technically true, but that's not what people mean by "significant whitespace" in this context. So you're being pedantic rather than saying anything meaningful. But you made me think. The ultimate nightmare would be significant trailing whitespace - the spaces and/or tabs after all the visible characters change the meaning of the line.
• this_user 1y ago
  Because you love using Microsoft's shitty technologies, but also want to be completely unemployable?
  • gwbas1c 1y ago
    I've spent my entire career, 22 years, primarily in C#. I'm quite employable.
    • wiseowise 1y ago
      > Because you love using Microsoft's shitty technologies If we go by the joke in gp, this is you.
      • tialaramex 1y ago
        I don't have any problem with the idea that Microsoft's technologies are "shitty" after all the response of my work laptop to its mandatory Windows 11 upgrade was a non-copyable diagnostic message with an opaque code in it which, as I understand it, is basically the equivalent of "Huh, oops, maybe try again?" and my colleague spent a week trying to uh, share data from a "Sharepoint" table. But .NET's CLR doesn't seem especially shitty. It's not awesome, I don't feel that RIIR urge when I work with C# and I probably wouldn't with F# either but it's fine, it's like Java again, or maybe Go or Python. It's fine. I don't hate it and that's enough.
  • deleted 1y ago
    [deleted]
  • pacoWebConsult 1y ago
    It's pretty baseless to claim that modern dotnet is inherently shitty. They've made tremendous strides in the dotnet core era. F# making you unemployable is debateable, but I don't see what makes F# any less employable than most other FP languages. They have some niche applications that make it useful rarely, but when they're useful its a terrific tool for the job. F#'s ability to interop with the rest of the dotnet ecosystem positions it better than most functional languages for business usecases.
• amelius 1y ago
  I have a few questions. Can it do GUIs well? How about mobile? And how does it compare to e.g. Scala?
  • munchler 1y ago
    It can do GUIs well, although it takes some finesse to manage user state in an immutable-first language. Check out Fable for building web apps: https://fable.io/ https://fable.io/ I don't have much experience with Scala, but I think the two languages are pretty comparable in their respective ecosystems. The biggest difference I'm aware of is that Scala has typeclasses and F# does not.
    • int_19h 1y ago
      F# is not really that strong on immutability, though. Sure, variables and struct fields are immutable by default, but making them mutable is one keyword away. Similarly with classes - declaring readonly properties is more concise, but when you need a read/write one, it's readily available.
  • pjc50 1y ago
    Because it's a CLR language, it has access to all the same technologies as C#. That is, all the Microsoft native ones plus cross-platform with Avalonia. https://fsharp.org/use/desktop-apps/ https://fsharp.org/use/desktop-apps/
  • dagw 1y ago
    Can it do GUIs well? I don't know if I would say 'well'. For simple GUIs it's OK but, for non-trivial GUIs I would use the approach to write the GUI frontend code in C# and have it call the F# 'backend'. If for no other reason than that the support and documentation for doing GUIs in C# is much better. How about mobile? Never tried, but I'm guessing more or less the same story as above. I would probably start by looking into .Net MAUI for that. And how does it compare to e.g. Scala? The biggest difference is that Scala is a much bigger and more of a multi-paradigm language. F# feels smaller and more focused and on its ML roots and functional programming. Not saying that Scala is less 'functional' than F#, but Scala supports you writing your code in a much more OOP way if you want. Yes you can (and sometimes have to) do OOP in F#, but it doesn't feel natural.
• protonbob 1y ago
  > which is quite odd for what is supposed to be the flagship editor for F# The flagship editor is Visual Studio, not vs code.
  • bozhidar 1y ago
    But it's Windows-only, so it's not an option for me.
    • GiorgioG 1y ago
      Rider is an option for you. Community edition is free too.
      • LandR 1y ago
        Rider is now entirely free for non commercial use.
    • protonbob 1y ago
      Who said it was? It is the flagship editor though.
    • neonsunset 1y ago
      Why not VS Code with Ionide? It’s quite nice.
  • _7acn 1y ago
    The flagship editor is Rider
• a-french-anon 1y ago
  Why would Lispers feel at home with its (whitespace delimited) syntax? Quite the strange claim. I know this isn't a common rant, but I hate so-called functional language still bowing to the "infix mathematical operator special case" dogma, when those are just binary (variadic in Lisp) functions. Always found it pretty appealing, otherwise. And no ";;"!
• 7thaccount 1y ago
  F# is beautiful, but I could never crack the nut and get fluent in it. I think the big problem is I only know a little C#, so it is difficult to figure out the object oriented methods that F# depends on. It was the same thing with Clojure and Scala for the JVM. I have zero interest in first learning C# or Java, just to use those platforms.
  • netdevphoenix 1y ago
    you are not supposed to do oop in f#
    • 7thaccount 1y ago
      I'm aware, but you need to understand the .NET ecosystem to get anything practical done (at least when I was using it in 2017). All the books written on it (I own 3) are also the same way and assume you're a skilled C# dev.
      • miloandmilk 1y ago
        100% this, I spent many months going through the most recent books on F# including one which the latest version was only released last year I think. They all seem to try and shield you from the fact that you are much better placed if coming from C# (which everyone seems to refer to as .net these days) and have a solid understanding of the .net class library. All the main web frameworks sit on top of asp.net and pretty much all official documentation for that is in c# Such a shame because I learnt so much about types from trying to crack f# for real world application. fsharpforfunandprofit taught me heaps which I apply to other languages, but I don't want to become a c# developer which comes with all the years of changing best practices to be able to really be productive in f#. Sorry if I am coming across as bitter but I just can't see learning f# in isolation from c# which is an absolute shame.
        • neonsunset 1y ago
          What is the issue with learning C# alongside it, if only the bits necessary to improve the F# experience? Both are excellent languages.
• 867-5309 1y ago
  [flagged]
• rockyj 1y ago
  I did try F#, but I was new to .NET ecosystem. For 1 "hello world" I was quite surprised by how many project files and boilerplate was generated by .NET, which put me off. I am all for FP, immutable, and modern languages. But then where are the jobs and which companies care if you write good code? Now everyone wants languages which are easy to use with AI, while reducing workforce and "increased productivity". I have been programming for 20 years and know 4-5 languages, in India it was worse but in EU at-least I can make a sustainable living by writing Java / TypeScript. I cannot even find jobs with Kotlin + TypeScript which pay well, forget getting jobs in Elixir / Clojure / F# (there maybe a handful of opportunities if I will relocate for around 70K/year). That is why I have mostly given up on learning niche languages.
  • djha-skin 1y ago
    I learn them as a fun hobby, with no salary expectations. It keeps the dream alive, and I learn a lot from the Common Lisp community that I do use in my job.
  • owenm 1y ago
    I hear you on the opportunity side and I can't see that changing. The good news is in recent releases there's a lot less boilerplate - "dotnet new console -lang F#" results in two files, a short fsproj file and a single line of Hello World.
  • afavour 1y ago
    Opportunities do exist, even when they’re few and far between. I learned Rust in my spare time because I was really interested in it. Then we stumbled across something that would have really benefitted from a cross platform library and lo and behold, I got to use my Rust knowledge, even though the vast majority of my day job doesn’t use it.
  • neonsunset 1y ago
    As sibling comment pointed out, it's just .fsproj manifest and Program.fs file. What boilerplate do you speak of? It's on the opposite end boilerplate-wise to projects made in e.g. Java or TypeScript. For F#, projects are needed to make full applications or libraries. Otherwise, you can simply write F# scripts with .fsx and execute them via 'dotnet fsi {SomeScript.fsx}'. (obviously you can also specify dotnet fsi as shebang and integrate these scripts into general scripting on Unix systems - it's very productive)
• pdimitar 1y ago
  People will do anything except actually try Elixir. :D ...I mean: pipes, immutability, transparent mega-parallelism... helloooo? I tried F# some years ago (after I was fired from a shop that decided they will go all-in on Java and F# and dropping everything else overnight) and I was not impressed. I mean the language is really nice but the C# baggage and runtime was just a bit much. And I was not left convinced that immutability alone is worth the switch. I suppose we can call F# an FP gateway drug? Now arguably you get a runtime and some baggage from the Erlang runtime (the BEAM VM, where Elixir also runs), but the guarantees and features you get are invaluable, and have proven themselves many times over the last literal three decades.
  • weakfish 1y ago
    The shop went all in on Java and F#? Why not C# and F#? That’s really odd, unless there’s context I’m missing.
    • pdimitar 1y ago
      I wish they told me. They cut ties with most of their previous devs overnight, as if we were some enemies. Weirdest firing in my life and career to this day.
      • weakfish 1y ago
        That’s truly bizarre. Glad you’re out of that situation, doesn’t sound quite healthy from what you’re saying.
  • BiteCode_dev 1y ago
    If one need to get on Beam, is it better to start on Elixir or Gleam?
    • pdimitar 1y ago
      Elixir's ecosystem is much farther ahead than Gleam, so if you want to actually achieve stuff without pauses to fill the gaps yourself, then Elixir is the way to go. And don't get me wrong, I love the idea of Gleam, a lot (Rust syntax, strong static typing, what's not to love?). But my PL early adopter days are over.
• pimbrouwers 1y ago
  Our shop converted 6 years ago, from C# to exclusively F#. I also author and maintain some packages (falco, donald, validus and others). The language is tough to learn if you're coming from a C-style language. But worth the effort and experience. It's extremely concise a true delight to build programs in that are fast, robust and durable. There are a few drawbacks, depending on your perspective: - compilation is slower than c# and hot reload isn't supported (it's in progress) - there are very few opportunities to use it professionally - hiring devs can be challenging
  • cogman10 1y ago
    How does the typing system work for F#? From the article, it looks like it's mostly dynamically typed. Or is it inferred? Or is it something else? Like, if I write let hello value = print value hello "world" hello 2 Does that just work? To me, that'd be a point that might steer me away from the language. Deducible types seem vital to larger and long lived projects.
    • neonsunset 1y ago
      F# is a statically typed language with gradual typing and full type inference. Given let hello value = printfn "%A" value hello "world" hello 2 The binding "hello" has "'a -> unit" signature where 'a is a generic argument it accepts because the "printfn" binding with a given format specifier is generalized the same way and an unconstrained 'T (here 'a) is the most narrow type inferred for "hello".
      • debugnik 1y ago
        > with gradual typing Isn't gradual typing widely understood to mean "gradual between static and dynamic", which F# certainly isn't?
    • Nelkins 1y ago
      It's statically typed and inferred. With regards to your example, the print/printfn (equivalent of Write/WriteLine) functions are a bit funny in F#. They don't actually take bound string values directly. You need to specify the type (which could be a string, a number, obj, etc) https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/plaintext-formatting https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
• GiorgioG 1y ago
  As a 20+ year C# developer I’ve tried several times to learn/use F#. Despite being interested in FP, my brain is having trouble figuring out how to structure my code in F#. In C# I’d either build a service (or use the mediator pattern) for the domain and a repository for data access. With F# it’s functions all the way down and it feels unnatural (as silly as that may sound).
  • jcmontx 1y ago
    The secret is currying. Replace your DI for currying and you'll start to see somewhat similar patterns
    • Smaug123 1y ago
      By the way, I consider https://www.bartoszsypytkowski.com/dealing-with-complex-dependency-injection-in-f/ https://www.bartoszsypytkowski.com/dealing-with-complex-depe... to be the canonically correct way to do DI when you want to inject more than like two dependencies.
  • Akronymus 1y ago
    along with what jcmontx said: F# is structured bottom from top. As in you can't reference something that is later defined earlier. I find that naturally leads to getting a decent enough structure "for free" because it forces you to have your basic functionality early on and build on that later. That also, IMO, makes untangling/splitting up parts of the codebase easier as well.
  • MrMcCall 1y ago
    That makes sense when one is used to the Visual Studio organization of solutions and projects, with some main method somewhere being the entry point, unless it's a WCF service or somesuch that gets run via a service manager. I only used F# at its command line, fsi.exe, to give me commandline access to .NET for exploration, testing, and munging data. Over time, I built up quite a library of usable functions that I'd have the fsi.exe program pre-load when I kicked it off, leaving me at the prompt with all .NET namespaces and my code ready and accessible. Once you get access to your database's data, it's easy to write queries against it and then play with the data. I could then port the F# processing bits that worked into my C# projects as necessary, but it was far easier to do it that way than to write the logic deep within complex multi-project solution files, where the various classes are spread throughout the projects' files. I also just really enjoyed using F#.
• gwbas1c 1y ago
  > Why F#? I'm kinda wondering if anyone here with decent C#/.net experience can give their version of the answer? --- The article really didn't answer its own question. It basically says "How" instead of "Why"... ...Which as someone who's spent over 20 years in C#, and tends to advocate for "functional" style, leaves me with more questions than answers!
  • kowalgta 1y ago
    I've worked with .net professionally for almost 20 years. At the beginning with C# while last decade almost exclusively with F#. F# is just a better language. Simpler, more concise, more readable with stronger type safety. I will never go back to writing C# as I'm finding it too frustrating at times and unproductive.
  • malakai521 1y ago
    A nicer, cleaner and simpler syntax, superior pattern matching, active patterns, discriminated unions and computation expressions
    • int_19h 1y ago
      C# has the equivalent of active patterns these days.
      • malakai521 1y ago
        It does not
  • Foofoobar12345 1y ago
    Everything is an expression (i.e. its an actual functional programming language), and along with it comes a different way of thinking about problems. Coupled with a really good type system which has discriminated unions, you'll have much fewer bugs. Pro tip: don't write F# like you would write C# - then you might as well write C#. Take the time to learn the functional primitives.
• gwbas1c 1y ago
  If you've had C# and F# co-exist in the same codebase, how do they co-exist? Is it like C# and VB.Net where a project (dll) is either C# or VB.Net, and they can reference each other? Or: Is it more like the Swift / Objective C ecosystem where Swift, Objective C, and even straight C can co-exist in the same library? In a mixed C# and F# codebase, generally when do you favor C# versus F#? Coming from a C# background, what are the areas where F# is a better language? Any success stories for F#, especially if it co-exists with C#? Any horror stories?
  • neonsunset 1y ago
    You have likely heard "functional core, imperative shell". This refers to having IO-heavy code that favors imperative patterns be written in C# and then have the actual domain logic core written in F# which is much better at expressing it. Because both languages are hosted on .NET, you simply achieve it by having two projects and having one reference another. It is very seamless F# and C# types are visible to each other if marked to be so. The biggest advantage of F# is its gradual typing and full type inference which allows to massively reduce the amount of text required to describe application or domain logic. It is also extremely composable and I find doing async in F# somewhat nicer than in C# too. F# also has better nullability (or, rather, lack of thereof) assurances and, in my opinion, better UX for records.
    • gwbas1c 1y ago
      That's just like how C# and VB.Net can co-exist in the same project. Would you pick the pattern of: 1: C# Library with interfaces and/or abstract base classes 2: F# library with implementations of those interfaces and base classes 3: C# program (console, web service, GUI, ect) that specifies the implementations in Dependency Injection Or is there a simpler way for C# and F# to co-exist in the same project (dll or exe)?
      • int_19h 1y ago
        You don't really need to split 1 & 2, since F# can define .NET interfaces and abstract classes just fine. For that matter, you don't even need the interfaces if you wouldn't have had them in a C#-only solution. Just define the class in F# and use it directly from C#. You still need a separate assembly for F#, but that doesn't imply dependency injection - again, just reference it and use it.
• phplovesong 1y ago
  Last time i tried F# i got bit by the weird concurrency story. There was async/task and somwhow they did not play well together. Also the dev tooling (for vim) was subpar, compared to ocaml (lsp). Compile times also was on the slower side.
  • neonsunset 1y ago
    If you use task { } CE's you will get really good UX (it is recommended to use them over async CE's). They were introduced in F# 6.0 to address outstanding interoperability issues. As of now, writing asynchronous code is more convenient than C# (which is more convenient than Go or other languages which are less expressive w.r.t. writing highly concurrent code).
  • 110bpm 1y ago
    `async` is F#'s original implementation of async programming. It is the precursor to C#'s await/async. `task` targets the .NET TPL instead, which is also what C#'s await/async and all of .NET *Async methods use. While the `async` implementation still offers some benefits over `task` (cold vs. hot starts [0]), my advice is - if you're doing backend code on .NET, you should use task. The tigher integration with the .NET ecosystem & runtime results in better exception stack traces, easier debugging and faster performance. [0] https://github.com/TheAngryByrd/IcedTasks?tab=readme-ov-file#coldtask https://github.com/TheAngryByrd/IcedTasks?tab=readme-ov-file...
• twodave 1y ago
  In the case of F#, the use cases are diminishing with every new C# release, since C# is getting better and better at the things F# is supposed to be strong at (record types, pattern-matching, etc.). Better to write the thing in C# using modern features of the more popular and capable language.
  • marcosdumay 1y ago
    You may start to get a point when C# gets a two-directional type inference system. As it's now, any functional-looking code requires so much boiler plate that it's shorter and less bug-prone to copy your functions code everywhere you want to use them.
    • int_19h 1y ago
      Can you give an example of said boiler plate?
      • DeathArrow 1y ago
        Using OneOf library or something similar instead of discriminated unions / sum types. Trying to use a functional pipeline instead of DI.
      • marcosdumay 1y ago
        Just try to make any generic high order function in C#. Any one you can think of.
  • arwhatever 1y ago
    Unions remain the killer F# feature missing from C#. Also, basic object initialization in C# has turned into a nightmare with recent versions. You need a flowchart to select among the 18 syntax options which suite your current needs. With F# (and other newer languages), record fields are either `T` or `T option`. No need to worry about whether the value needs to be computed in a constructor and then remain immutable, whether it needs to be initialized by an object initializer and/or a constructor or not, whether it needs to remain interior-ly mutable throughout the life of the record, and so on. (Although as I recall you do still need to consider null values assigned to non-nullable references in your F# code that consumes C#.)
• fud101 1y ago
  I want to ask a weird question. I'd love to learn ASP.net but i can't bring myself to deal with Microsoft Windows and their tech. Is F# a way for me to learn enough NET to make some money?
  • jcmontx 1y ago
    I'm .NET dev and haven't touch a windows device since 2019. Work on Mac, deploy to Linux.
  • CharlieDigital 1y ago
    I am also a C# dev and haven't worked on a Windows machine in 5 years. C# and F# both work fine with Rider or VS Code on Mac or Linux.
  • lunarlull 1y ago
    > i can't bring myself to deal with Microsoft Windows and their tech Even in a VM? Why not?
• systems 1y ago
  The problem with F#, Clojure and Elixir (hosted languages) For F# , you need some basic C# knowledge For Clojure, you need some basic Java knowledge For Elixir, you need some basic Erlang knowledge I like all 3 languages but usually each vm have a primary language, and each hosted language eventually become hosted on that primary language not the vm I understand that for many task simple, to medium complexity, you might not need that, but it seem as you try to be more advanced you hit the wall of having to learn you host vm primary language
  • skrebbel 1y ago
    > For Elixir, you need some basic Erlang knowledge As an Elixir programmer, this does not resonate. Basically the only thing I've ever felt I needed to understand Erlang for was ets, but let's be honest, that's not really proper Erlang but just the terrible ets query syntax. And all this requires is "ability to read enough erlang term syntax to be able to understand the ets manual". I don't think I could write a single line of correct Erlang by heart. I feel like that's different in F#, where you still need to know lots of .NET internals which are all documented in C#y terms with C# examples etc. Elixir wraps pretty much all good Erlang/OTP internals in nice Elixiry modules, which solves that quite nicely. Elixir has its warts but this really isn't one of them.
    • graemep 1y ago
      Thanks. I know a bit of Erlang (put some effort into learning, but never used it in real life, probably forgotten what I learned) and want to learn Elixir which seems better suited to what I want to do in the short to medium term.
  • graemep 1y ago
    Erlang is not a difficult language. Unusual, but actually quite sane syntax. If you are already familiar with Elixir it would probably be pretty easy to learn the basics of Erlang.
  • innocentoldguy 1y ago
    I worked with Elixir for over five years without knowing anything about Erlang. I know Erlang now, but only because I was interested in learning it, not because I needed to do so to write Elixir code.
• nudpiedo 1y ago
  Same as many, I had wonderful experience with F# in the past, I would use it again if: - fable would 100% detach from dotnet - keeps up yo the LLM rush, specially vibe coding on cursor Last LLM experience it generated obsolete grammar (not much but a bit). Such la gauges are key for vibe coding experience and modeling.
• aaronmu 1y ago
  I've been using F# professionally for the past seven years across different contexts. First in a small software shop and now while bootstrapping a SaaS company. Some observations: * It’s easier to attract smart developers to an F# project than to a [mainstream language] project. This was one of my driving beliefs when I introduced F# seven years ago. https://www.paulgraham.com/pypar.html https://www.paulgraham.com/pypar.html. This is probably just as true for languages like Elixir, Clojure, ... But F# is what we went with. Small Software Shop Context * We operated in a small market where customers eventually dictated our tech stack (.NET & React). In that market, F# was a major advantage—it allowed junior developers to build apps that "just worked" with minimal regressions. Even with mediocre code quality, I felt confident that we could refactor safely at any time. * I constantly had to justify F# to clients, which was exhausting. We always delivered decent results, so it worked out, but my partners were never as confident in defending F#. Bootstrapping a SaaS Company * F# has been invaluable for shipping features quickly and taking shortcuts when needed. * Three years in, our codebase is large and contains its fair share of messy parts. But we can still develop new features at high speed with minimal regressions. Refactoring is relatively safe and straightforward. * Compilation speed is the Achilles’ heel. If you don’t monitor it, the compiler slows down to the point where it impacts productivity. Earlier this year, waiting over a minute for feedback after a small change became unbearable. A lot of our "clean-up" work focuses on optimizing compilation times. We're still learning, but we’re optimistic that we can restructure the project to significantly improve build performance. EDIT: maybe one more point. I see a lot of C# vs F# popping up here. Yes, C# has all the features that F# has. But do not underestimate how well designed F# is. It is an extremely simple language to learn compared to C#. There is a very limited amount of keywords to learn. And they compose extremely well. If you learned F# 7 years ago, took a break, and came back today, you'd simply write the same boring code that you would have written 7 years ago. And along the way you'd find out that some things have gotten a bit nicer over time.
  • GiorgioG 1y ago
    As a 20+ year C# dev...where do I learn how to structure apps in F#? In C# my ASP.NET Controller might use a service (or a mediator) to execute some domain logic and that in turn will use a repository pattern (or EF DbContext) to update/query a database. How are dependencies injected in? It seems like there are multiple ways of going about it, but I don't have enough knowledge of F# to know 'the proper way' to do it.
• loxs 1y ago
  I tried F# some years back when I was searching for a language to port my OCaml project in... It felt too much .NET-y and too much MicroSoft-y. And back then .net for linux had just been released and was somewhat unpolished. It seemed that I had to learn C# in order to use F# properly and it seemed that porting it to C# was the saner option. I went with Rust after all and it seems to have been the right choice.
  • airstrike 1y ago
    This rings true to me as well. I'm not sure what I get out of F# that I can't get from Rust, unless you specifically want .NET, which I don't.
    • UK-Al05 1y ago
      Less arduous memory management.
      • airstrike 1y ago
        I am not sure what you mean. My memory management for a recent 30k LOC app boils down to "thinking before cloning"
    • DeathArrow 1y ago
      You get speed of development, productivity, lots of libraries. You get something that is easy to learn and understand.
      • airstrike 1y ago
        Lots of libraries if you want .NET, right? But if you don't, Rust has way more libraries Speed of development is debatable. I think you can be pretty fast with both. Easy to learn I concede but it gets easier with time, until it becomes very easy
        • loxs 1y ago
• froggertoaster 1y ago
  Coming from a .NET developer - why NOT F#? * Network effect, or lack thereof. Very few people use it. * Its nature is contrary to the ecosystem. The CLR is fundamentally resistant to the paradigms that F# creates. Wonderful little language - one of my favorites - and we owe a lot to it for the great features that C# has. But it just hasn't picked up the critical mass it needs.
• jonsagara 1y ago
  The killer feature for me is type providers. I need to read a lot of CSV files of varying formats, and the CSV Type Provider lets me make quick work of them in a type-safe manner. https://fsprojects.github.io/FSharp.Data/library/CsvProvider.html https://fsprojects.github.io/FSharp.Data/library/CsvProvider...
  • Hojojo 1y ago
    Wow, that sounds awesome. I'm jealous.
  • deleted 1y ago
    [deleted]
  • owlstuffing 1y ago
    Agreed. Type providers bring metaprogramming to F# in a way that’s both powerful and innovative. The concept is amazing, enabling a new frontier for dynamically extending type safety. My only surprise is how little fanfare it has received since its introduction. For a more pragmatic take on static metaprogramming, the manifold project[1] for Java is worth a look. Unlike F#, which leans toward expansive schemas, Manifold focuses on contained, compile-time integrations—handling JSON, XML, SQL, GraphQL, and even other languages in a seamless, type-safe way. 1. https://github.com/manifold-systems/manifold https://github.com/manifold-systems/manifold
• raphinou 1y ago
  F# was for me the best functional language when I looked at rewriting a Ruby on Rails app. I wanted to go with a functional language, as it seems to better fit my thinking and reasoning, and I looked at Haskell, Ocaml, Scala, F#. Being a stranger to Microsoft technologies, F# was the least likely to be chosen, but easily became the first choice. Haskell's purity made it hard to adopt (for me), Ocaml's ecosystem is subpar (there wasn't even a clear choice for a library to interact with postgresql, I couldn't install the latest version due to its reliance on an obscure tool whose name I forgot and didn't get help on the forum), and Scala is seems complex.... F# was surprisingly easy to get started with. The community is mis-managed by a corporate-minded approach (requiring people to become member of the F# software foundation to get access to the official slack!), but its members are friendly, smart and ready to help. The ecosystem is great with access to all the dotnet libraries (some complain there's a mismatch as most of those are developed for use with C#, but I rarely got in trouble for using them). There are also great libs and frameworks available. Like https://github.com/SchlenkR/FsHttp https://github.com/SchlenkR/FsHttp to easily interact with http servers, to the point that I find it easier to use than a dedicated library. Or https://github.com/CaptnCodr/Fli https://github.com/CaptnCodr/Fli , to run commands. And last but not least, https://www.websharper.com/ https://www.websharper.com/ is the best web framework I have encountered across all ecosystems. Their reactive approach to web ui really allows me to develop complex interfaces in a maintainable way. This became a longer message than I thought, probably due to my enthousiasm for the language. For complete transparency, the situation is not perfect, and in my experience the tooling is not the best. If you want more info, I blogged about it a couple of months ago: https://www.asfaload.com/blog/consider-fsharp/ https://www.asfaload.com/blog/consider-fsharp/
  • bozhidar 1y ago
    Great story! Thanks for sharing it!
  • kqr 1y ago
    Curious since you don't expand on it on the blog: in what way did Haskell's purity make it difficult to you? Having used Haskell in production for a bit now, I don't even notice its purity. Most functions are in some kind of I/O context making it similar as other languages, except with the option of running without I/O capabilities for functions that shouldn't need it.
• shermantanktop 1y ago
  > Trivia: F# is the language that made the pipeline operator (|>) popular. I’m not a dabbler in exotic languages, so this definition of “popular” was puzzling. I’ve literally never seen that operator before. Maybe I need to get out more.
  • zdragnar 1y ago
    It exists in several similar languages such as elixir, and was even a proposal for ecmascript, but never really got traction.
    • WorldMaker 1y ago
      It made it to Stage 2, which is some traction: https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator It has been "stuck" at Stage 2 for a while, though.
      • shermantanktop 1y ago
        Thanks for that link! Now I want pipe operators...
    • sundarurfriend 1y ago
      I'm familiar with it via Julia, and I believe recent versions of R also have it.
  • sdsd 1y ago
    I've used it in Racket, which is not exactly "popular" but common in universities as a teaching language. I actually built a fairly popular Tor hidden search engine in Racket nearly a decade ago, but I quickly shut it down when I ran some stats on the most common queries.
• RKFADU_UOFCCLEL 1y ago
  F# is a very well-polished functional language. Think of it to Haskell as C# is to Java. No worries about space leaks or purely-academic syntax or monads (though you can get those if you need them). All with tight integration into one of the biggest, well-established ecosystem (CLI). It's managed by smart people who know how to keep it from derailing as it grows.
• jxjnskkzxxhx 1y ago
  Does anyone else find interesting that people who write blog posts saying "my favourite language is X", it's never a mainstream language..?
  • pantsforbirds 1y ago
    My favorite language is Python, but I wouldn't write a blog post about it because no one would care.
    • jxjnskkzxxhx 1y ago
      My favourite language is also python, and I would love to read your blog post on why your favourite language is python :-)
  • siknad 1y ago
    New mainstream languages are rarer than new better (in some way that can be favorable) languages.
  • mrkeen 1y ago
    Successful language designers select for what's popular, not what's good. C++ intersected the mass of C programmers with the new OO fad, and kept all of C's warts. Had Stroustrup made C++ better, he wouldn't have an army of adopters who already knew C. Maybe merit will win out in the long run [1]? I'm not hopeful. Java needed to be close enough to C++, and C# to Java. And Brendan Eich joined Netscape to "put Scheme in the browser". [1] https://www.theregister.com/2025/03/02/c_creator_calls_for_action/ https://www.theregister.com/2025/03/02/c_creator_calls_for_a...
  • iLemming 1y ago
    > people who write blog posts ... never a mainstream language Don't you find it amusing that food critics usually write about little-known or new restaurants and never do any fast-food chain reviewing?
• reverseblade2 1y ago
  Here's a Saas that actually makes money written fully in F# https://3dpack.ing https://3dpack.ing Here's a rust ray tracer compiled to web assembly written in F# https://ncave.github.io/fable-raytracer/ https://ncave.github.io/fable-raytracer/ source: https://github.com/ncave/fable-raytracer?tab=readme-ov-file https://github.com/ncave/fable-raytracer?tab=readme-ov-file
  • stefanfisk 1y ago
    The navbar takes up half my screen on an iPhone 13 mini :/
• justanotheratom 1y ago
  F# was my favorite language, but - You have to chose the language of the Domain that you are working in, e.g, Swift for native iOS Development. Supabase Backend requires TypeScript, etc. - LLMs don't care about F#.
• fnord77 1y ago
  > Trivia: F# is the language that made the pipeline operator (|>) popular. laughs in clojure
• lysecret 1y ago
  I worked a lot in F# and loved it. I love that it has a lot of great functional ideas without being too pedantic about being 100% functional all the time. (You can have mutating state or just call arbitrary C#.) I took a lot of its insights into my daily python code too. I especially love match.
  • mrkeen 1y ago
    There's no need to be functional 100% of the time, and it's not pedantry. You mark your functions and non-functions as such, so the compiler can get your back.
• BenGosub 1y ago
  Two nice things about F# are that you can introduce it into an organisation using the dotnet ecosystem and that you can use all libraries in dotnet, which is a huge advantage over OCaml. Otherwise, I am happy with OCaml, but F# has also a place in this world.
  • UlisesAC4 1y ago
    You can use adapters via Foreign Function Interface and interact with C++ code. The deal breaker is that memory is separated, C++ code has its own heap and Ocaml too. Quiet different to F# in which operating with C# is seamless and the runtime is the same.
    • DeathArrow 1y ago
      You can call C++ code from F#, too.
• hurril 1y ago
  F# is a wonderful language, one that I write as my daily for the second time during my carrier. It _baffles_ me how it isn't more popular than it is because it truly is very very good. And I say this as an experienced and avid functional programmer. We even do the frontend in it using Fable and Elmish, which is to say: we basically write our frontends in Elm, but the platform is .NET.
• darksaints 1y ago
  I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems. More significantly, they are being passed up in favor of Rust, which is a great language but nonetheless a bad fit for a lot of problem domains, simply because Rust has a superior build system. Hell, 80% of the reason I choose Rust over C++ for embedded work is because of the build system. It baffles me that there are languages with non-profit foundations and are financially backed by multiple corporations which still have bad build systems. It is the most important investment you can make into a programming language.
  • Lyngbakr 1y ago
    While I've never used it in anger, I really quite like dune. Was there something specific that makes you characterise it as "ridiculously bad"?
    • noahbp 1y ago
      Not Dune exactly, but having to run 'eval $(opam env)' in the terminal every time you open an OCaml project rather than the default being npm-like, where you can just open the directory and use the package manager command without having to think about it.
      • anentropic 1y ago
        (writing all the below while being aware you likely know much more about OCaml than I do...!) Possibly `eval $(opam env)` is something that should just go in your ~/.zshrc The OCaml folks have done some work recently to improve the onboarding documentation, which I think is going in a positive direction e.g. https://ocaml.org/docs/installing-ocaml https://ocaml.org/docs/installing-ocaml (the eval as a one-off post install command) And then guiding people to use 'switches' https://ocaml.org/docs/opam-switch-introduction https://ocaml.org/docs/opam-switch-introduction, which I totally missed when I started with the language. > Local switches are automatically selected based on the current working directory.
      • johnisgood 1y ago
• 110bpm 1y ago
  I put together a quick-start guide to F# Computation Expressions — showing how you can go from C# async/await all the way to Result<> workflows with let!... and!... expressions, and even a custom validation {} CE. [0] This is a practical side of F# that doesn’t get enough spotlight — but one I’m using daily. [0]: https://news.ycombinator.com/item?id=42636791 https://news.ycombinator.com/item?id=42636791
  • LinearEntropy 1y ago
    That was a great read. Thanks for sharing.
• kingkongjaffa 1y ago
  F# is great Even if you never write a single line, it’s a fantastic illustrative language. For example I refer to https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/ all the time for functional programming ideas.
• sklivvz1971 1y ago
  As a person who's worked with the author (a great guy!) and with the F# community on a very large F# project: don't bother with F#, professionally speaking. F# has many theoretical qualities, which make it fun if you like these things, but it also has some fundamental flaws, which is why it's not getting a wide professional adoption. - the build system was a mess last I checked (slow, peculiar) - syntax is not c-like or python-like (a big deal for a lot of people) - you can't hire developers who know it (and certainly the few are not cheap) - the community is a bit weird/obsessed/evangelizing (a turn off in a professional environment) - it's clearly a second class citizen in the .net world (when stuff breaks, good luck getting support) On the other hand - it has discriminated unions - units - etc. but do you need this stuff (not want: need)? most people don't.
  • debugnik 1y ago
    The build system is exactly the same as C#, MSBuild with its .NET SDK, and syntax and community are entirely subjective; F# has the least weirdo community I've personally seen for an FP language. Weak arguments to say the least. I'll give you the chicken-and-egg hiring problem and it being second-class to the .NET team, though; I'd add poor IDE support by modern standards, only Rider feels right. I love F# but I've moved on for these reasons.
• FrustratedMonky 1y ago
  F# on front page? And popular? ahhh, Its April Fools? JK, I love F#. Please get over the hump and be a big language.
• DeathArrow 1y ago
  Iove the ideas behind functional programming but I never properly learned a functional programming language. I will probably never have the opportunity to use it professionaly and learning it just for hobby doesn't make sense to me. If I am developing something in my spare time I also like to use something I can earn money with so I can hone and maintain my earning skills. Maybe sounds like min maxing. If I would be in a situation where I can develop software just out of pleasure or pure curiosity, I would use just whatever language I deem interesting.
• rawoke083600 1y ago
  I'm waiting for the excellent F# Article about railroad-coding to be posted here. Required F#e reading :) No not trolling. Am on mobile and traveling else I would have searched-posted
  • smcl 1y ago
    I assume you're talking about Scott Wlaschin's "Railway Oriented Programming": https://fsharpforfunandprofit.com/rop/ https://fsharpforfunandprofit.com/rop/
• dev_l1x_be 1y ago
  [dead]
• mesic 1y ago
  F# is getting some traction in Norway. I know for a fact that places such as NRK (BBC eqvivalent), Resoptima, Frende Forsikring and my current employer, REN are all using F#. I just gave a talk about how we use F# at REN: https://vimeo.com/1070647821 https://vimeo.com/1070647821
• protonbob 1y ago
  I've found that as C# gains much of the features that F# has and will soon gain more (pattern matching, functions as first class data types, great fp libraries, etc) the "moat" that F# has over C# has gotten smaller. I write most of my c# code in a primarily functional style, but I still have the advantage of using the libraries in their own native ways that follow the examples given by microsoft and other vendors.
  • runevault 1y ago
    Watching c# eat f# features as someone who has dabbled in f# lightly for over a decade has been wild. And supposedly DU's are in the works but multiple years out. Though one thing I doubt c# ever gets that I love when I'm writing f# is pipeline operators. I love the way they read, from object/collection being worked on and then a list of operations being run on it in order from left to right (or you can do right to left if you need to for some particular reason).
  • gdfsfs8895 1y ago
    [dead]
• DeathArrow 1y ago
  F# is a lovable language as in people are really enjoying using it vs not being bothered using it. Once every other month a new F# link lands on top page and receives a few hundred of upvotes. I think F# needs and deserves more publicity in order for it to win a larger audience. If only F# community would be half as vocal as Rust community.
• ClimaxGravely 1y ago
  I work in an industry where F# is a non-starter but I still love to use it outside of work. Also what I learn from F# and functional programming still benefits me in my day job (mostly c++). I think I tend to write a bit safer code after understanding the benefits of a functional language.