20 ms·

What's New in F# 9

283 points by neonsunset 2y ago

sevensor 2y ago
> There is also a new compile-time error for classes with over 65,520 methods in generated IL. Such classes aren't loadable by the CLR and result in a run-time error. (You won't author that many methods, but there have been cases with generated code.) The mind boggles. At any rate, F# is a terrific language. After excel, probably the second best thing Microsoft has ever released. Turns .NET into a reasonable platform.
- CharlieDigital 2y ago
  > After excel, probably the second best thing Microsoft has ever released. Turns .NET into a reasonable platform. I feel like C# is quite underrated. Very productive language that's relatively easy to teach to anyone that is already familiar with JS or TS. Used in a variety of contexts from game engines to enterprise backends to desktop apps. A few fumbles by Microsoft early on stunted its growth, IMO, but it's a really good and relatively easy to learn general purpose language.
  - brtkdotse 2y ago
    > A few fumbles by Microsoft early on stunted its growth Microsoft really, _really_ missed out on a huge opportunity to rebrand .NET into something else when they did the Framework -> Core transition. Despite .NET being cross platform for over ten years and winning benchmarks left and right people still see it a the “slow enterprisey framework that only runs on Windows”.
    - CharlieDigital 2y ago
      Yes, big time fumble. I've met a handful of folks who used it in the .NET Framework days and hadn't kept up with the changes in Core (multi-platform, object-functional hybrid, minimal syntax for console and APIs, etc.).
      - ngrilly 2y ago
        What do you mean by "minimal syntax for console and APIs"?
        metaltyphoon 2y ago
        Probably top level statements and minimal APIs from ASP.Net Core
        CharlieDigital 2y ago
        Minimal web APIs are structured a lot like Express (whereas .NET web APIs are more like Nest.js) https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-8.0 https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...
        ngrilly 2y ago
        Having recently joined a company using C#, and with a background using Go, Python, Node, and similar, I was worried about heavy "enterprise-style" APIs. I was happy to discover the new minimal web API while reading .NET Core documentation.
        jodrellblank 2y ago
        You no longer need imports, or namespace, class and main method boilerplate to write a basic C# program; there’s now a way to simply write some lines of code in a file with some implicit imports, and compile/run them like it was more of a scripting language. https://learn.microsoft.com/en-us/dotnet/csharp/tutorials/top-level-statements https://learn.microsoft.com/en-us/dotnet/csharp/tutorials/to... (If there’s other syntax changes, I don’t know them, AFAIK it’s the same C# you write)
        SideburnsOfDoom 2y ago
        > If there’s other syntax changes, I don’t know them The new syntaxes that come to my mind are: * File-scoped namespaces * "global using" * "using static"
    - Modified3019 2y ago
      Yep, I literally only learned it was cross platform last year when I noticed it as a package dependency. Mind you, I’m not a coder, and more just a Linux homelab hobbyist.
      - sundarurfriend 2y ago
        I was going to ask what the multiplatform deployment story was like, it seems like you've partially answered it - it seems like you ship it with .NET Core as a dependency, kinda like JRE for Java programs? How heavy of a dependency is it? And is there a dependency hell situation, if different programs require different versions of .NET Core?
        int_19h 2y ago
        There are quite a few knobs there. You can AOT-compile the bytecode, as well, and you can ship the whole thing as a single binary: https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview https://learn.microsoft.com/en-us/dotnet/core/deploying/sing... Size very much depends on what you actually use in the app, but on the order of tens of megabytes.
        ethbr1 2y ago
        Also, one of the major changes in the Framework -> Core (now just .NET) shift was making it legally permissible to redistribute the runtime? So you can ship .NET code with a .NET runtime all in your installer. Afaik, Framework was only distributable from Microsoft.
        telgareith 2y ago
        Nope, have always been able to ship the redist installers. Just like VC++. https://www.microsoft.com/en-us/download/details.aspx?id=21 https://www.microsoft.com/en-us/download/details.aspx?id=21 (scroll down to 'Installation Instructions') After all, not being able to ship the runtime with the software to buyers would have been... Bad. In the early '00s
    - tbrownaw 2y ago
      > Despite .NET being cross platform for over ten years and winning benchmarks left and right people still see it a the “slow enterprisey framework that only runs on Windows”. Do these people I've never heard of outnumber the people who did upgrade but wouldn't have if it had been branded as a separate product?
      - ngruhn 2y ago
        I’m definitely one of these people. Maybe I should give .NET a chance.
        CharlieDigital 2y ago
        It's quite nice now. Tooling is way nicer than it was 10 years ago. My team is all Apple silicon Macs and we deploy to AWS Arm64 instances. Unit tests in GH run on Linux workers.
      - monkaiju 2y ago
        I encountered this within the last week...
      - Kinrany 2y ago
        Less than 50% of software engineers ever used .NET for anything, so the answer is almost certainly yes?
  - sevensor 2y ago
    > I feel like C# is quite underrated That’s fair, I consistently underrate it myself. Last time I worked with C# was a big messy codebase written by mostly junior developers who didn’t understand what entity framework was doing behind the scenes. I came away from that experience with the impression that C# is a terrible language.
    - aithrowawaycomm 2y ago
      There’s an interesting problem with “practical” functional languages that we don’t really know what a crappy enterprise F# / OCaml / Haskell codebase looks like - though maybe Haskell is sufficiently popular in crypto these days that there’s some examples. But generally software in these languages is written by highly motivated developers with a lot of flexibility. OTOH a lot of bad C# and Java is written by developers with bad technical management who treats devs as code monkeys. Further a lot of the “technical enablers” of bad C#/Java are bespoke enterprise frameworks that simply don’t exist for functional languages. But in principle, enterprise Haskell could be quite vulnerable to a “productivity-boosting” language extension that locks older Haskell codebases into horrible typeclass golf. I say all this as someone who loves F# and would only take a C# job if I needed the money. But certainly a lot of the enterprise antipatterns can be clumsily implemented in F#, while a well-written C# codebase is usually pleasant and productive. In particular F# doesn’t totally escape problems like “the Nuget service locator is overengineered for our needs, but we are on a deadline and an excessive abstraction is better than hard-wiring everything.”
      - akra 2y ago
        My hypothesis is that F# is somewhat self selecting at senior/lead dev's who would have a lot of choice in the language that they get to choose not the army of "code monkey's" as you call them. Generally this would mean higher code quality on average.
  - algorithmsRcool 2y ago
    C# these days is GREAT, but F# still has features that C# doesn't like unions and much more powerful (and ergonomic) pattern matching. And line for line, F# is more effective at getting things done (and i would argue with less bugs)
    - runevault 2y ago
      The c# team is supposedly putting in serious work on Discriminated Unions. I'm really interested to see how it turns out because f# already does a great job with them.
      - Turskarama 2y ago
        Discriminated unions is probably the last "must have" feature I've been waiting for in C#. Better pattern matching would be nice to have but honestly not as much of a gamechanger.
        WorldMaker 2y ago
        The C# team for several reasons decided "rock solid" pattern matching was a higher priority than discriminated unions because good discriminated union code needs good pattern matching. In the last few versions of C# I think pattern matching has gotten really good. List Patterns finally exist now, and that influenced the new iterable collection initializers, which are also pretty good now. Last I checked, the C# team was still debating Dictionary/Hash key lookup Patterns and Dictionary/Key-Value initializers, and that's maybe my last big request in pattern matching other than native discriminated unions, of course.
  - zamalek 2y ago
    Sadly modern idiomatic C# is a bit of a nightmare these days. It's a heavily abstracted/"indirected" style, where you are basically forced to use a debugger to determine where a method call actually goes. The goal seems to be to make things as emergent as possible, with reflection and IL emit determining code flow as much as possible. I think that F# goes a long way to prevent this, by nature of being functional.
    - snoman 2y ago
      I’ve written a lot of modern C# and I don’t know what you mean - especially with regards to your comment about F# being different. Are you taking about the popularity of the mediator pattern (via Mediatr)?
      - zamalek 2y ago
        Maybe you're just extremely lucky. MediatR is part of the problem, yes. Way too much attribute/reflection magic there. One particularly good example is: attempt to add full support (i.e. query text generation) for PERCENTILE_CONT to EF. That will give a good idea of just how bad the idiomatic C# style can get. Now take the EF style of code/architecture and apply it to an entire product codebase - which is completely a understandable mistake to be made (it's not unreasonable to assume that EF would be a good example of C# code). You know you have a problem when you throw in the towel and have ThingDependencies classes all over the place. The aspnetcore internals don't vary too much from the abomination that is EF. "Just don't code like that," you might say. The problem with that argument is that pre-existing code exists, people don't code in isolation, and the cargo cult has a ton of momentum behind it. > your comment about F# being different. You'll struggle to write that style of code in a functional language. There is such as thing as healthy friction. F# has its own problems, but this is not one of them.
      - emn13 2y ago
        The default C# style has always preferred a large dose of unnecessary runtime flexibility. Sometimes that comes in the form of lots of dynamic dispatch, sometimes it's DI, sometimes it's non-sealed overly large base-class types, and sometimes its some combination thereof - but the net effect is that it's not possible to reason about code by just reading it. Tooling becomes worse and/or less valuable because tooling too cannot reliably trace all possible code paths. Additionally, Microsoft has an outsized influence on the C# ecosystem. As a result, they wrote quite a few architectural and style guidelines that, naturally, target themselves. It makes sense for a hyper-widely distributed library to consider things like binary compatibility as critical features, but the design rules that follow from that have zero utility for apps, and low utility for most libraries. The C# ecosystem also has an unhealthy veneration for MS provided code. While I'm sure most of the authors are quite competent, there's less experimentation and fewer hidden gems because the ecosystem is tilted towards being followers behind the framework providers path. As a result, it's much harder to refactor code in that style than code in a less (runtime) flexible style, and it's worse when the libraries heavily used are frameworks that have so many extension points. There's a tradeoff between runtime flexibility and codebase flexibility, and the default .NET C# style heavily leans towards runtime flexibility, which isn't a good tradeoff for most software.
  - the5avage 2y ago
    What is also great about C# is that the language server for editor support uses the real compiler. I once set that up with emacs and it is by far the best experience I had in emacs with any language.
  - mhh__ 2y ago
    C# is sort of underrated but gets a ridiculously easy ride for actively encouraging bloat and abstraction-ism. What should be "do a thing" is now design a thing to do a thing then call the thing-do-er IDoAThing. Alone this would not be so bad but the problem is that you only have this. Extension methods? Fuck off (but don't take them away). Roslyn is great though.
    - CharlieDigital 2y ago
      That's a function of the team, not the language.
      - mhh__ 2y ago
        Human behaviour in programming is of course totally independent of language and tools, indeed
        bigstrat2003 2y ago
        It is, in fact, independent. You can create horrible monstrosities in any language, or create great code in any language.
      - kristopolous 2y ago
        Both. The language can afford that usage through the design decisions. I kind of think the best languages would be those that make creating layers of spaghetti indirection nearly impossible. In practice, it's usually much more specious. Names like "CreatorImplementer", "FactoryAbstrator", "DeviceAccessory" and a half dozen equally amorphous things calling each other as if Thomas Pynchon was writing software. I think I've seen it in all languages I've worked on professionally. Maybe not in Perl.
        CharlieDigital 2y ago
        I mean, you can do the same in JavaScript and TypeScript as well as any number of other languages.
  - trallnag 2y ago
    > relatively easy to teach to anyone that is already familiar with JS or TS. What about Java?
    - throwaway675867 2y ago
      In my experience having mentored devs into F# on very large projects its easier to learn F# if coming from a JS, Python, Go, etc background than C# or Java even without previous .NET exposure. Not due to a skill issue, but more of a psychological one. IMO to be productive in F# code code tends to be simpler - many patterns that dev's valued learning in a OO context become a little obsolete or less needed as a whole. This is my anecdote but it is the C#/Java/etc crowd that tend to have the most negative immediate reaction to F# - they ask "where is X" and often I immediately say "X is bad, you shouldn't need X - think about why". They associate X with some kind of power/productivity gain, but don't realize there is many ways to do things. Kind of follows the paradigm of "frameworks/patterns are missing language features". If they keep at it then it eventually clicks but there is almost a psychological "unlearning" that needs to be done which at least in the C# camp creates an almost tribal tension between the two camps - its just too unfamiliar. Whereas for example TS dev's seem to find it somewhat familiar in parts; even people only ever done JS previously I've found have become good F# dev's. Could be because the flow more suits the way you would code in a dynamic language while still being strongly typed (e.g. REPL's, type inference, static modules, functions over classes, etc).
      - Multicomp 2y ago
        Vouched for this dead comment. If this really should be flagged to death, could I get a quick refresher on what parts are boring reading or off-topic? The comment is an anecdote and not data, but this does not seem like a flamey post, or a low effort post, or a strawman post.
        mkl 2y ago
        Probably automated. If someone creates a new account then immediately posts big comments, lots of comments, or links, the comments end up dead by default and need vouching. The dead spam comments often found at the bottom of threads are why.
  - bmitc 2y ago
    F# is much easier to teach and learn than C#.
- fuzztester 2y ago
  >At any rate, F# is a terrific language. Any downsides, in your opinion? I had toyed with it a few years ago, using that lightweight IDE called LINQPad, IIRC, but did not follow up, or keep track of its pros and cons or progress later. https://www.linqpad.net/ https://www.linqpad.net/
  - modernerd 2y ago
    Downsides: lack of jobs, libraries, learning materials, small community, little promotion by Microsoft outside of "what's new in F#" and other announcements. It's a shame because F# is a beautiful language — it's fun to read, write and maintain. .NET now works well cross-platform with editors other than Visual Studio. General perks of .NET like cross-platform compilation are a nice bonus, for example, on macOS I can: brew install dotnet dotnet new console -lang F# -o HelloWorldApp cd HelloWorldApp dotnet publish -c Release -r osx-arm64 --self-contained dotnet publish -c Release -r osx-x64 --self-contained dotnet publish -c Release -r win-x64 --self-contained dotnet publish -c Release -r linux-x64 --self-contained To get self-contained binaries (that don't need .NET to be installed locally) for those platforms. There is a decent multi-platform UI framework called Avalonia: https://github.com/fsprojects/Avalonia.FuncUI https://github.com/fsprojects/Avalonia.FuncUI There are good actively maintained web frameworks: https://fsharp.org/guides/web/#web-frameworks https://fsharp.org/guides/web/#web-frameworks There are some passionate people writing great books about F#: https://fsharpforfunandprofit.com/ddd/ https://fsharpforfunandprofit.com/ddd/ Most of F#'s adoption issues seem to be because: 1. It's tough to convince people outside of the .NET community to use .NET. 2. Most of the people using .NET use C#. 3. It's hard to convince C# users to adopt F#. (See https://www.reddit.com/r/dotnet/comments/16m0wdj/why_dont_you_just_use_f/ https://www.reddit.com/r/dotnet/comments/16m0wdj/why_dont_yo... and similar threads.) I'd love to work with F# full-time, but — short of starting my own company using it or convincing Microsoft to pay me to help them showcase its benefits — it's been hard to find work with F#, which drove me to spend time with other languages.
    - neonsunset 2y ago
      F# can also be compiled with NativeAOT. The main thing this target complains about is printfn and especially printfn "%A" which uses unbound reflection. So as long as you just Console.WriteLine instead it may not emit warnings: dotnet publish -o {folder} -p:PublishAot=true Note that -c Release is no longer required - it is now a default for 'publish'. Also, if you are doing a self-contained/non-AOT build, you may want to do it as follows to retain compact binary size: dotnet publish -o {folder} -p:PublishSingleFile=true -p:PublishTrimmed=true All the properties above can also be defined within respective .csproj/.fsproj files inside PropertyGroup blocks as e.g. <PublishAot>true</PublishAot> so you don't have to add them to a command every time. F# also has excellent support for scripting with fsi and .fsx format: https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-interactive/ https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp... Someone even made a tool for it which builds on top of bflat allowing to compile F# script files into native binaries directly without project setup: https://github.com/ieviev/fflat https://github.com/ieviev/fflat
egamirorrim 2y ago
This looks like a good set of improvements but goddamn F# is an ugly looking language
- pohl 2y ago
  To each their own, I guess. I find the various modern ML-influenced languages to be among the best looking.
  - sprkv5 2y ago
    I agree with you. The best looking ones are Gleam, ReScript and F#
  - runevault 2y ago
    I always miss pipeline operators in languages without them after F# exposed me to them.
- munchler 2y ago
  Really? It's a classic ML language. What about it specifically do you find ugly?
neonsunset 2y ago
Note - F# 9 also benefits from practically all performance improvements in .NET 9 itself, especially around object escape analysis: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/ https://devblogs.microsoft.com/dotnet/performance-improvemen...
fumeux_fume 2y ago
Had a crypto class that let us choose any language that used .NET. My homework in F# was so much easier to read than everyone elses. Would def use it more, but nearly 100% of my data science work is Python.
- gnarlouse 2y ago
  That’s so cool.
arunc 2y ago
What is the state of F# a replacement for C# to create GUI apps on Windows? Are there companies using F# for this purpose?
- neonsunset 2y ago
  There are a few options: https://github.com/fsprojects/Avalonia.FuncUI https://github.com/fsprojects/Avalonia.FuncUI https://fabulous.dev/ https://fabulous.dev/ (which targets Avalonia/MAUI/Xamarin) https://github.com/kekyo/epoxy https://github.com/kekyo/epoxy (Avalonia and WPF) > Are there companies using F# for this purpose? I can ask around if you're interested.
  - deleted 2y ago
    [deleted]
  - stackskipton 2y ago
    I'm in this world, few companies are doing GUI apps at all these days. Most have long converted to Web Apps. Since it's pretty tiny minority of .Net users use F#, I'm sure someone somewhere is using F# for GUI but it's going to be tiny shop somewhere.
  - arunc 2y ago
    Appreciate it, thanks!
- deleted 2y ago
  [deleted]
fluid_ident 2y ago
I really miss working in F#, such a productive language. But I still enjoy keeping tabs on the updates. I always thought the tooling was quite good, given the size of the community and Microsoft's apparent apathy towards it at times. The biggest pain point for me was accuracy in code test coverage.
sundarurfriend 2y ago
How does the versioning for F# work? These seem like a bunch of nice quality-of-life improvements, but a major version change doesn't seem warranted in terms of semantic versioning - no breaking changes - nor in terms of a major leap in terms of language features that a non-semver project might use as a reason to go version 8 to version 9. Another comment mentions .NET9 that recently came out, is that the reasoning here, to keep in stride with .NET version numbers?
- guhidalg 2y ago
  For both C# and F#, the version of .NET indicates the version of the build tooling (msbuild, compilers, nuget packages, etc...) that will be used to build the code whenever you invoke `dotnet build`. That means, for example, that the F# team _could_ have shipped a language change between versions 8 and 9, but if they didn't then at least they could have shipped a compiler change or an msbuild change that required .NET 9 for whatever reason. For developers, usually you can just update your code to the latest available runtime version unless you have to wait for your deployment environment to have the latest .NET version installed. Nowadays that's not necessary due to MSBuild changes to create self-contained deployments, but something to know.
  - WorldMaker 2y ago
    C# will deliver the 13.0 compiler with .NET 9.0. It is a fun coincidence that F#'s 9.0 release coincides with .NET 9.0.
- jbjbjbjb 2y ago
  A new NET version comes out yearly and the C# and F# versions align with the yearly version but C# is ahead by 4. Semantic versioning is overrated anyway.
  - WorldMaker 2y ago
    It is fun to point out that the VB.NET compiler is still at least 3 versions ahead. As far as I am aware VB.NET hasn't had a major version number bump since 16.0 (around .NET Core 3.x or .NET 5, as I recall), but the VB.NET compiler still also claims the 6 versions before .NET. C#'s (lucky) 13.0 in .NET 9 is also just partly related to the non-linear version numbering of .NET itself with the long shadow if .NET 4's many minor releases that were also "major", the Core divide, and the eventual "unfork" at 5.0. F#'s 9.0 matching .NET 9 is a fun coincidence, and also just because F# is younger and missed some of the .NET fun like 4.x "minor number is as important as major number" years.
jfausdfwsdfa 2y ago
> let notAValue: string | null = null When did F# get unions?
- datadeft 2y ago
  It had it since the first version as far as I know.
  - ctenb 2y ago
    You're probably referring to Disciminated unions aka sumtypes? That's not what the parent meant
    - datadeft 2y ago
      I thought those are the same and I realize that there is a difference.
- jfausdfwsdfa 2y ago
  Damn. It's only for nulls: https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1060-nullable-reference-types.md https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-10... Wonder if they will generalize: https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1092-anonymous-type-tagged-unions.md https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-10...
  - ctenb 2y ago
    At least they chose a syntax that makes it possible to generalize, which is a smart choice imho :)
    - robertlagrant 2y ago
      Yeah it looks a lot like Python's PEP 604[0]. [0] https://peps.python.org/pep-0604 https://peps.python.org/pep-0604
oDot 2y ago
Since the null-related blog post isn't published yet, anyone here knows the reason to implement null rather than write middle-layer in C# for whatever you want to use?
- neonsunset 2y ago
  At this point, almost all community and all standard library APIs use nullable reference types (and types that aren't NRTs are obviously expected to always have a value). This change in F# makes it able to interoperate with C# NRTs, where C#'s T? becomes F#'s T | null and vice versa. I feel like the ease of integration of F# into existing codebases is one of the major selling points. You don't need to write wrappers in order to consume most existing C# code, which, for example, enables writing a core with business logic in F# while keeping the IO in C# if necessary.
  - algorithmsRcool 2y ago
    F# has chosen this approach of implementing compatibility with newer C# features such as support for ValueTuple<T> and Span<T>. It has been pretty successful at keeping F# inside the compatibility story. ---EDIT--- Mean to post this under the GP
wodenokoto 2y ago
How is the F# story on Linux/MacOS? Is it like a windows thing that you can also do on Linux or does it feel like a fully supported language?
- algorithmsRcool 2y ago
  F# is full supported on Windows, MacOS and Linux via CoreCLR and several more platforms via Mono, just like C# is
- LAC-Tech 2y ago
  Never noticed anything odd using in in linux.
- runevault 2y ago
  Same as C#. Anything that doesn't rely on windows libraries (so like various GUI libraries from MS) works fine on Linux and Mac.
ducdetronquito 2y ago
I only toyed with F# recently, but coming from Python I really like that I can also use a REPL to experiment stuff: I wonder if experienced F# devs use it too. I hope to have time to build a small web backend project this winter, to get to know the language and ecosystem better. I heard good things about Oxpecker for the http part; do you have any recommendation for a good postgresql client/driver ? (I don't like ORMs) Cf: https://lanayx.github.io/Oxpecker/ https://lanayx.github.io/Oxpecker/
- yawgmoth 2y ago
  Npgsql is the popular C# driver, and has an F# wrapper. I'd start there.
  - ducdetronquito 2y ago
    Thanks :)
- deleted 2y ago
  [deleted]
- throwaway675867 2y ago
  As an polyglot dev who has the chance to use F# dev at times the REPL is how I POC most things - if I'm not sure of an API, even inlined into my actual codebase just hit the "Send to F# interactive" and it runs there and I can try things inside a module. Or when I want to try a new library, or when I want to do a quick benchmark, or as a substitute to a PS script, etc. You can even make F# scripts executable with the shebang `#!/usr/bin/env -S dotnet fsi` which we do a lot for scripts around our projects as an alternative to bash/python in our .NET projects where we already know a dotnet-sdk is installed. Usually runs faster too and typically just as concise. Just my anecdote opinion - the syntax and idioms of F# lean themselves more to REPL programming then C# which typically needs more OO structure rather than small code snippets strung together.
- raphinou 2y ago
  Here are 2 possibilities: - https://monazita.gitlab.io/monazita/ https://monazita.gitlab.io/monazita/ (i developed it for a project of mine while learning fsharp. Basically works but could be more polished and is pgsql only) - https://github.com/jacentino/DbFun https://github.com/jacentino/DbFun (more polished than previous project, and multi db)
algorithmsRcool 2y ago
F# has been my favorite language since I first encountered it in uni. F# was/is waaaay out ahead of C# with features like unions, null safety, pattern matching, records, more powerful type inference and generic constraints. Over the years C# has been implementing these features too, which is good, but they have been implementing them in incompatible ways, which isn't very good. Since the investment in F# has been much smaller than in C#, it hasn't been innovating as fast as C# and has been left behind in some ways. But it is still a great language and remains broadly compatible with the ecosystem and can deliver equal performance to C# with far less boiler plate
- neonsunset 2y ago
  Most incompatibilities can be summarized to "source generators" and tooling that relies on other forms of code generation. This can be fairly easily dealt with by writing a helper C# project with the necessary "glue". Other than that, is there something specific you have in mind? F# 9 even supports consuming ref struct generic arguments recently added to C# and plans to introduce their definition in F# itself AFAIK (which is likely going to be a nicer experience than in C#!). It has been doing impressively good job at keeping up thus far and deserves way more recognition for this.
  - hansvm 2y ago
    Off the top of my head, async is monstrous to integrate between the two languages. Even when it works it's slow.
    - neonsunset 2y ago
      This was addressed in F# 6: https://learn.microsoft.com/en-us/dotnet/fsharp/whats-new/fsharp-6#task- https://learn.microsoft.com/en-us/dotnet/fsharp/whats-new/fs... Asynchronous sequences (IAsyncEnumerable) support is provided via https://github.com/fsprojects/FSharp.Control.TaskSeq https://github.com/fsprojects/FSharp.Control.TaskSeq F# is a very capable language - a broad spectrum of tasks can be solved by just implementing a new CE, something I could not even think of in C#.
srid 2y ago
For WebAssembly, there is Bolero: https://fsbolero.io/ https://fsbolero.io/ Unfortunately, maintenance seems to have stopped since Jan, https://github.com/fsbolero/Bolero/releases https://github.com/fsbolero/Bolero/releases (I tried creating a sample project on Linux which didn't work to begin with)
- fayten 2y ago
  I know this is a few days at this point but Bolero has been in active development. All development work was done on the now deleted streamrendering and v0.24 branches. Version 0.24 was just published today: https://github.com/fsbolero/Bolero/releases https://github.com/fsbolero/Bolero/releases
xiaodai 2y ago
[flagged]
asdf123qweasd 2y ago
I dont know, i have used F# for a while now. My problem with it- is discoverability and reuseability of the created code. It is very hard to read and get in - compared to classic OO and its hard to reuse something created and custom tailored. My 2 cents, may be worth even less, due to my limited experience and a propably wrong approach by me.
- munchler 2y ago
  It takes a while to shed one's existing OO expectations, but after that, I think you'll find well-organized F# code to be easier to use than C#. Immutability and lack of side-effects makes it much simpler to reason about what someone else's code is doing, and then reuse it. If you have any specific examples of discoverability/reusability issues in F#, I'd be curious to hear them.
blastonico 2y ago
I love F#, but it depends almost exclusively on Microsoft, which is not a main priority. What if Microsoft decides to stop developing it?
- munchler 2y ago
  It's an open-source project with its own F# Software Foundation. If Microsoft drops it, I think it would continue. https://fsharp.org/ https://fsharp.org/
deleted 2y ago
[deleted]
gnarlouse 2y ago
What’s new in F# 9? Well of course that would be G#.
- amenhotep 2y ago
  It seems insufficient to accord you only one upvote for this.
725686 2y ago
I have never done F#, but when I was looking around it this seemed like a greate resource: https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/
- rmunn 2y ago
  That is indeed one of the best sites for people new to F#, both experienced C# devs and those relatively new to programming. It's rarely updated any more, so you won't find discussion of the new F# 9 features there, but the existing articles are excellent for getting your head wrapped around concepts like `apply` and `bind`.
shadytrees 2y ago
Rider's recent free non-commercial license makes F# a much more attractive option for macOS, I think
obeavs 2y ago
Well, I made a large, multi-year company/technology bet on top of F# with Phosphor. After over a year of trying to make it work, we completely rewrote the application in Typescript and Rust. The product we're building is an end-user programming tool where the traditional lines between front-end and back-end work blur, and the .NET ecosystem really didn't lend itself well to this. Our hope was that we'd be able to use the Fable library to maintain type safety across a variety of technologies while being able to interop and in and out as needed: Fable compiles F# code to JS, Rust, .NET, etc. The reality was that the interop story between the various libraries we'd use was much harder to achieve than initially expected, and managing and updating multiple dependencies and their bindings was an absolute PITA. The assumption that F# makes for beautiful, efficient code is still a safe one, I think. But the ecosystem and the way that it was designed makes it (in my view) applicable only for applications and software that have very traditional frontend/backend lines. F# would be used for the back-end only in that case. Today, two of the technologies I'm most excited by (and which we're using internally) are the Effect library, whose Schema library fills in a lot of the gaps in TS's type system, and Moonbit, which is what I imagine a modern version of F# would like, free of the MS/.NET dependencies. Moonbit is really, really well designed (designed by the creator of OCAML's version of Fable, ReScript), and it compiles directly to highly optimized JS, WASM or Native output. We're using Effect in production, and not yet Moonbit, but the promise Moonbit holds as a language built for an AI-first world is pretty fantastic.
- williamcotton 2y ago
  I’ve had a good experience exposing F# code that compiles to Typescript modules. The approach was to write the core business logic and validators in F# and the rest of the front-end application in Typescript and the back-end in C#. That is, core business logic and validators in F# and all of the IO in TS and C#.
- satvikpendem 2y ago
  Is your company related to Darklang by any chance? I recall they were a product similar to yours, written in F# as well, but I haven't kept up with them recently. Effect is pretty nice, I wish it existed in other languages than TypeScript too. Regarding MoonBit, it seems like its own proprietary programming language so I'd hesitate to move to that over something well known, what are your thoughts on that aspect?
textlapse 2y ago
Are there large, real world/OSS SW that uses F#?
- raphinou 2y ago
  Not pretending my project is large or important, but it is an example of a non trivial project written in fsharp: https://gitlab.com/myowndb/myowndb/ https://gitlab.com/myowndb/myowndb/
- onpikono 2y ago
  NRK, the Norwegian state television runs their web and streaming platform on F#. https://tv.nrk.no/ https://tv.nrk.no/
- fluid_ident 2y ago
  Jet.com. They were a (little) competitor to amazon before they were bought by Wally-mart. They are replacing the F# with Java though: https://news.ycombinator.com/item?id=39592760 https://news.ycombinator.com/item?id=39592760
  - lucidguppy 2y ago
    Its weird they didn't switch to C# - that would have been a much smoother transition to a memory managed brackety language.
    - WorldMaker 2y ago
      The rumors I've heard is that it is the "Oracle Golf Club Handshake Problem" in action: the current C-Suite of Wal-Mart got wined and dined and golf outing-ed a bit too much by Oracle who wanted a large contract expansion with massive revenue boost (for Oracle) and were promised a bunch of software resources/troubleshooting/consultant time in the next contract if they switched to far more Java. That sales job turned Java into a top-down mandate. It is a fun modern version of the "Nobody went wrong ordering more products and consulting from IBM" problem if IBM had an even more ruthless sales department and also owned too much of the database industry and too much of the Payroll/Time & Attendance industry (and worse, their legacy purchasing decisions and sunk costs) because no one has cracked down hard enough on vertical monopolies in the last century. Allegedly, of course. I'm sure Wal-Mart PR will happily tell you it was their own idea and how Java is the language of the future again, or something to that effect. Also, whether or not the rumors hold, it is hard to discount the pure Occam's Razor that it was just Wal-Mart's own idea to cut costs because of the simple dumb fact that labor costs in Wal-Mart's home labor markets for Java developers are certainly cheaper than .NET developers in the same job titles/experience levels. A mandate to switch to Java certainly was one cheeky way to do a slow layoff of expensive laborers without doing a real layoff.
Permik 2y ago
Kinda disappointed that they allowed null into the language, they should've just made some syntactic sugar or some auto bridge to reinterpret them nullable types as option types. Well, too bad. Not that I was a huge F# user anyway :D
- Smaug123 2y ago
  That would be a breaking change; certainly it's impossible to do that in the presence of reflection, and I imagine there are simpler cases. (See discussion on the similar https://github.com/fsharp/fslang-suggestions/issues/884 https://github.com/fsharp/fslang-suggestions/issues/884 .)
pjmlp 2y ago
A great programming language, pity that managment isn't that supportive of it, always feels like they consider it was a mistake adding it to VisualS Studio 2010, given how little of Microsoft own frameworks and Visual Studio tooling have first class support for F#. So we are mostly left with the community doing most of the work in a company with enought money to burn in deals like the Actvision Blizzard one, but not to staff the F# team appropriately (and they aren't the only one in such a state).
- neonsunset 2y ago
  Perhaps it could have been treated better, but then if you compare it with Kotlin, Scala or Clojure - F# ships with the main .NET SDK. It does not need to be installed separately, no user action is required to jump into an F# project immediately or to add an F# project to an existing solution. You can simply dotnet new classlib/console --language F#, dotnet build and it is ready to go. It could use more marketing, halo projects and word of mouth though.
  - pjmlp 2y ago
    Kotlin and Scala don't belong to any JVM implementation vendor, like F# belongs to Microsoft. And if consider Google to be a platform vendor with hands on Kotlin, then Android / Kotlin development experience is certainly much better than F# has ever achieved since its Visual Studio 2010's introduction. What F# has going for it, despite everything, is its great experience on Windows, versus Haskell and OCaml, which remain UNIX centric at heart.
fire_lake 2y ago
The Tail Call attribute is a huge improvement. TCO is a requirement for correctness and now we can enforce that at compile time!
- runevault 2y ago
  I wish every language with TCO supported some way to tell the compiler "if this cannot be optimized away I want an error." All it takes is a moment of inattention to screw up.
candl 2y ago
Should one use the result type for handling errors or exceptions or both? What's the rule in F#? When should you prefer immutability over mutability since both are possible in F# and it probably has a measurable impact on performance? When should you use objects instead of records or unions in F#? Since mutability is possible, any reason to not allow an explicit return or continue? It makes certain code patterns much less nested and easier to read.
infogulch 2y ago
louthy/language-ext [1] is a C# library which does its darndest to build a fully functional language inside C#. I found it very interesting and used it for an experimental project (which ended up failing, not sure if my usage of language-ext was partially to blame). People told me I should have just used F#. Anyone familiar with both that can compare them? [1]: https://github.com/louthy/language-ext https://github.com/louthy/language-ext

283 points by neonsunset 2y ago

> There is also a new compile-time error for classes with over 65,520 methods in generated IL. Such classes aren't loadable by the CLR and result in a run-time error. (You won't author that many methods, but there have been cases with generated code.) The mind boggles. At any rate, F# is a terrific language. After excel, probably the second best thing Microsoft has ever released. Turns .NET into a reasonable platform.

CharlieDigital 2y ago
> After excel, probably the second best thing Microsoft has ever released. Turns .NET into a reasonable platform. I feel like C# is quite underrated. Very productive language that's relatively easy to teach to anyone that is already familiar with JS or TS. Used in a variety of contexts from game engines to enterprise backends to desktop apps. A few fumbles by Microsoft early on stunted its growth, IMO, but it's a really good and relatively easy to learn general purpose language.
- brtkdotse 2y ago
  > A few fumbles by Microsoft early on stunted its growth Microsoft really, _really_ missed out on a huge opportunity to rebrand .NET into something else when they did the Framework -> Core transition. Despite .NET being cross platform for over ten years and winning benchmarks left and right people still see it a the “slow enterprisey framework that only runs on Windows”.
  - CharlieDigital 2y ago
    Yes, big time fumble. I've met a handful of folks who used it in the .NET Framework days and hadn't kept up with the changes in Core (multi-platform, object-functional hybrid, minimal syntax for console and APIs, etc.).
    - ngrilly 2y ago
      What do you mean by "minimal syntax for console and APIs"?
      - metaltyphoon 2y ago
        Probably top level statements and minimal APIs from ASP.Net Core
      - CharlieDigital 2y ago
        Minimal web APIs are structured a lot like Express (whereas .NET web APIs are more like Nest.js) https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-8.0 https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...
        ngrilly 2y ago
        Having recently joined a company using C#, and with a background using Go, Python, Node, and similar, I was worried about heavy "enterprise-style" APIs. I was happy to discover the new minimal web API while reading .NET Core documentation.
      - jodrellblank 2y ago
        You no longer need imports, or namespace, class and main method boilerplate to write a basic C# program; there’s now a way to simply write some lines of code in a file with some implicit imports, and compile/run them like it was more of a scripting language. https://learn.microsoft.com/en-us/dotnet/csharp/tutorials/top-level-statements https://learn.microsoft.com/en-us/dotnet/csharp/tutorials/to... (If there’s other syntax changes, I don’t know them, AFAIK it’s the same C# you write)
        SideburnsOfDoom 2y ago
        > If there’s other syntax changes, I don’t know them The new syntaxes that come to my mind are: * File-scoped namespaces * "global using" * "using static"
  - Modified3019 2y ago
    Yep, I literally only learned it was cross platform last year when I noticed it as a package dependency. Mind you, I’m not a coder, and more just a Linux homelab hobbyist.
    - sundarurfriend 2y ago
      I was going to ask what the multiplatform deployment story was like, it seems like you've partially answered it - it seems like you ship it with .NET Core as a dependency, kinda like JRE for Java programs? How heavy of a dependency is it? And is there a dependency hell situation, if different programs require different versions of .NET Core?
      - int_19h 2y ago
        There are quite a few knobs there. You can AOT-compile the bytecode, as well, and you can ship the whole thing as a single binary: https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview https://learn.microsoft.com/en-us/dotnet/core/deploying/sing... Size very much depends on what you actually use in the app, but on the order of tens of megabytes.
        ethbr1 2y ago
        Also, one of the major changes in the Framework -> Core (now just .NET) shift was making it legally permissible to redistribute the runtime? So you can ship .NET code with a .NET runtime all in your installer. Afaik, Framework was only distributable from Microsoft.
        telgareith 2y ago
        Nope, have always been able to ship the redist installers. Just like VC++. https://www.microsoft.com/en-us/download/details.aspx?id=21 https://www.microsoft.com/en-us/download/details.aspx?id=21 (scroll down to 'Installation Instructions') After all, not being able to ship the runtime with the software to buyers would have been... Bad. In the early '00s
  - tbrownaw 2y ago
    > Despite .NET being cross platform for over ten years and winning benchmarks left and right people still see it a the “slow enterprisey framework that only runs on Windows”. Do these people I've never heard of outnumber the people who did upgrade but wouldn't have if it had been branded as a separate product?
    - ngruhn 2y ago
      I’m definitely one of these people. Maybe I should give .NET a chance.
      - CharlieDigital 2y ago
        It's quite nice now. Tooling is way nicer than it was 10 years ago. My team is all Apple silicon Macs and we deploy to AWS Arm64 instances. Unit tests in GH run on Linux workers.
    - monkaiju 2y ago
      I encountered this within the last week...
    - Kinrany 2y ago
      Less than 50% of software engineers ever used .NET for anything, so the answer is almost certainly yes?
- sevensor 2y ago
  > I feel like C# is quite underrated That’s fair, I consistently underrate it myself. Last time I worked with C# was a big messy codebase written by mostly junior developers who didn’t understand what entity framework was doing behind the scenes. I came away from that experience with the impression that C# is a terrible language.
  - aithrowawaycomm 2y ago
    There’s an interesting problem with “practical” functional languages that we don’t really know what a crappy enterprise F# / OCaml / Haskell codebase looks like - though maybe Haskell is sufficiently popular in crypto these days that there’s some examples. But generally software in these languages is written by highly motivated developers with a lot of flexibility. OTOH a lot of bad C# and Java is written by developers with bad technical management who treats devs as code monkeys. Further a lot of the “technical enablers” of bad C#/Java are bespoke enterprise frameworks that simply don’t exist for functional languages. But in principle, enterprise Haskell could be quite vulnerable to a “productivity-boosting” language extension that locks older Haskell codebases into horrible typeclass golf. I say all this as someone who loves F# and would only take a C# job if I needed the money. But certainly a lot of the enterprise antipatterns can be clumsily implemented in F#, while a well-written C# codebase is usually pleasant and productive. In particular F# doesn’t totally escape problems like “the Nuget service locator is overengineered for our needs, but we are on a deadline and an excessive abstraction is better than hard-wiring everything.”
    - akra 2y ago
      My hypothesis is that F# is somewhat self selecting at senior/lead dev's who would have a lot of choice in the language that they get to choose not the army of "code monkey's" as you call them. Generally this would mean higher code quality on average.
- algorithmsRcool 2y ago
  C# these days is GREAT, but F# still has features that C# doesn't like unions and much more powerful (and ergonomic) pattern matching. And line for line, F# is more effective at getting things done (and i would argue with less bugs)
  - runevault 2y ago
    The c# team is supposedly putting in serious work on Discriminated Unions. I'm really interested to see how it turns out because f# already does a great job with them.
    - Turskarama 2y ago
      Discriminated unions is probably the last "must have" feature I've been waiting for in C#. Better pattern matching would be nice to have but honestly not as much of a gamechanger.
      - WorldMaker 2y ago
        The C# team for several reasons decided "rock solid" pattern matching was a higher priority than discriminated unions because good discriminated union code needs good pattern matching. In the last few versions of C# I think pattern matching has gotten really good. List Patterns finally exist now, and that influenced the new iterable collection initializers, which are also pretty good now. Last I checked, the C# team was still debating Dictionary/Hash key lookup Patterns and Dictionary/Key-Value initializers, and that's maybe my last big request in pattern matching other than native discriminated unions, of course.
- zamalek 2y ago
  Sadly modern idiomatic C# is a bit of a nightmare these days. It's a heavily abstracted/"indirected" style, where you are basically forced to use a debugger to determine where a method call actually goes. The goal seems to be to make things as emergent as possible, with reflection and IL emit determining code flow as much as possible. I think that F# goes a long way to prevent this, by nature of being functional.
  - snoman 2y ago
    I’ve written a lot of modern C# and I don’t know what you mean - especially with regards to your comment about F# being different. Are you taking about the popularity of the mediator pattern (via Mediatr)?
    - zamalek 2y ago
      Maybe you're just extremely lucky. MediatR is part of the problem, yes. Way too much attribute/reflection magic there. One particularly good example is: attempt to add full support (i.e. query text generation) for PERCENTILE_CONT to EF. That will give a good idea of just how bad the idiomatic C# style can get. Now take the EF style of code/architecture and apply it to an entire product codebase - which is completely a understandable mistake to be made (it's not unreasonable to assume that EF would be a good example of C# code). You know you have a problem when you throw in the towel and have ThingDependencies classes all over the place. The aspnetcore internals don't vary too much from the abomination that is EF. "Just don't code like that," you might say. The problem with that argument is that pre-existing code exists, people don't code in isolation, and the cargo cult has a ton of momentum behind it. > your comment about F# being different. You'll struggle to write that style of code in a functional language. There is such as thing as healthy friction. F# has its own problems, but this is not one of them.
    - emn13 2y ago
      The default C# style has always preferred a large dose of unnecessary runtime flexibility. Sometimes that comes in the form of lots of dynamic dispatch, sometimes it's DI, sometimes it's non-sealed overly large base-class types, and sometimes its some combination thereof - but the net effect is that it's not possible to reason about code by just reading it. Tooling becomes worse and/or less valuable because tooling too cannot reliably trace all possible code paths. Additionally, Microsoft has an outsized influence on the C# ecosystem. As a result, they wrote quite a few architectural and style guidelines that, naturally, target themselves. It makes sense for a hyper-widely distributed library to consider things like binary compatibility as critical features, but the design rules that follow from that have zero utility for apps, and low utility for most libraries. The C# ecosystem also has an unhealthy veneration for MS provided code. While I'm sure most of the authors are quite competent, there's less experimentation and fewer hidden gems because the ecosystem is tilted towards being followers behind the framework providers path. As a result, it's much harder to refactor code in that style than code in a less (runtime) flexible style, and it's worse when the libraries heavily used are frameworks that have so many extension points. There's a tradeoff between runtime flexibility and codebase flexibility, and the default .NET C# style heavily leans towards runtime flexibility, which isn't a good tradeoff for most software.
- the5avage 2y ago
  What is also great about C# is that the language server for editor support uses the real compiler. I once set that up with emacs and it is by far the best experience I had in emacs with any language.
- mhh__ 2y ago
  C# is sort of underrated but gets a ridiculously easy ride for actively encouraging bloat and abstraction-ism. What should be "do a thing" is now design a thing to do a thing then call the thing-do-er IDoAThing. Alone this would not be so bad but the problem is that you only have this. Extension methods? Fuck off (but don't take them away). Roslyn is great though.
  - CharlieDigital 2y ago
    That's a function of the team, not the language.
    - mhh__ 2y ago
      Human behaviour in programming is of course totally independent of language and tools, indeed
      - bigstrat2003 2y ago
        It is, in fact, independent. You can create horrible monstrosities in any language, or create great code in any language.
    - kristopolous 2y ago
      Both. The language can afford that usage through the design decisions. I kind of think the best languages would be those that make creating layers of spaghetti indirection nearly impossible. In practice, it's usually much more specious. Names like "CreatorImplementer", "FactoryAbstrator", "DeviceAccessory" and a half dozen equally amorphous things calling each other as if Thomas Pynchon was writing software. I think I've seen it in all languages I've worked on professionally. Maybe not in Perl.
      - CharlieDigital 2y ago
        I mean, you can do the same in JavaScript and TypeScript as well as any number of other languages.
- trallnag 2y ago
  > relatively easy to teach to anyone that is already familiar with JS or TS. What about Java?
  - throwaway675867 2y ago
    In my experience having mentored devs into F# on very large projects its easier to learn F# if coming from a JS, Python, Go, etc background than C# or Java even without previous .NET exposure. Not due to a skill issue, but more of a psychological one. IMO to be productive in F# code code tends to be simpler - many patterns that dev's valued learning in a OO context become a little obsolete or less needed as a whole. This is my anecdote but it is the C#/Java/etc crowd that tend to have the most negative immediate reaction to F# - they ask "where is X" and often I immediately say "X is bad, you shouldn't need X - think about why". They associate X with some kind of power/productivity gain, but don't realize there is many ways to do things. Kind of follows the paradigm of "frameworks/patterns are missing language features". If they keep at it then it eventually clicks but there is almost a psychological "unlearning" that needs to be done which at least in the C# camp creates an almost tribal tension between the two camps - its just too unfamiliar. Whereas for example TS dev's seem to find it somewhat familiar in parts; even people only ever done JS previously I've found have become good F# dev's. Could be because the flow more suits the way you would code in a dynamic language while still being strongly typed (e.g. REPL's, type inference, static modules, functions over classes, etc).
    - Multicomp 2y ago
      Vouched for this dead comment. If this really should be flagged to death, could I get a quick refresher on what parts are boring reading or off-topic? The comment is an anecdote and not data, but this does not seem like a flamey post, or a low effort post, or a strawman post.
      - mkl 2y ago
        Probably automated. If someone creates a new account then immediately posts big comments, lots of comments, or links, the comments end up dead by default and need vouching. The dead spam comments often found at the bottom of threads are why.
- bmitc 2y ago
  F# is much easier to teach and learn than C#.
fuzztester 2y ago
>At any rate, F# is a terrific language. Any downsides, in your opinion? I had toyed with it a few years ago, using that lightweight IDE called LINQPad, IIRC, but did not follow up, or keep track of its pros and cons or progress later. https://www.linqpad.net/ https://www.linqpad.net/
- modernerd 2y ago
  Downsides: lack of jobs, libraries, learning materials, small community, little promotion by Microsoft outside of "what's new in F#" and other announcements. It's a shame because F# is a beautiful language — it's fun to read, write and maintain. .NET now works well cross-platform with editors other than Visual Studio. General perks of .NET like cross-platform compilation are a nice bonus, for example, on macOS I can: brew install dotnet dotnet new console -lang F# -o HelloWorldApp cd HelloWorldApp dotnet publish -c Release -r osx-arm64 --self-contained dotnet publish -c Release -r osx-x64 --self-contained dotnet publish -c Release -r win-x64 --self-contained dotnet publish -c Release -r linux-x64 --self-contained To get self-contained binaries (that don't need .NET to be installed locally) for those platforms. There is a decent multi-platform UI framework called Avalonia: https://github.com/fsprojects/Avalonia.FuncUI https://github.com/fsprojects/Avalonia.FuncUI There are good actively maintained web frameworks: https://fsharp.org/guides/web/#web-frameworks https://fsharp.org/guides/web/#web-frameworks There are some passionate people writing great books about F#: https://fsharpforfunandprofit.com/ddd/ https://fsharpforfunandprofit.com/ddd/ Most of F#'s adoption issues seem to be because: 1. It's tough to convince people outside of the .NET community to use .NET. 2. Most of the people using .NET use C#. 3. It's hard to convince C# users to adopt F#. (See https://www.reddit.com/r/dotnet/comments/16m0wdj/why_dont_you_just_use_f/ https://www.reddit.com/r/dotnet/comments/16m0wdj/why_dont_yo... and similar threads.) I'd love to work with F# full-time, but — short of starting my own company using it or convincing Microsoft to pay me to help them showcase its benefits — it's been hard to find work with F#, which drove me to spend time with other languages.
  - neonsunset 2y ago
    F# can also be compiled with NativeAOT. The main thing this target complains about is printfn and especially printfn "%A" which uses unbound reflection. So as long as you just Console.WriteLine instead it may not emit warnings: dotnet publish -o {folder} -p:PublishAot=true Note that -c Release is no longer required - it is now a default for 'publish'. Also, if you are doing a self-contained/non-AOT build, you may want to do it as follows to retain compact binary size: dotnet publish -o {folder} -p:PublishSingleFile=true -p:PublishTrimmed=true All the properties above can also be defined within respective .csproj/.fsproj files inside PropertyGroup blocks as e.g. <PublishAot>true</PublishAot> so you don't have to add them to a command every time. F# also has excellent support for scripting with fsi and .fsx format: https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-interactive/ https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp... Someone even made a tool for it which builds on top of bflat allowing to compile F# script files into native binaries directly without project setup: https://github.com/ieviev/fflat https://github.com/ieviev/fflat

egamirorrim 2y ago

This looks like a good set of improvements but goddamn F# is an ugly looking language

pohl 2y ago
To each their own, I guess. I find the various modern ML-influenced languages to be among the best looking.
- sprkv5 2y ago
  I agree with you. The best looking ones are Gleam, ReScript and F#
- runevault 2y ago
  I always miss pipeline operators in languages without them after F# exposed me to them.
munchler 2y ago
Really? It's a classic ML language. What about it specifically do you find ugly?

neonsunset 2y ago

Note - F# 9 also benefits from practically all performance improvements in .NET 9 itself, especially around object escape analysis: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/ https://devblogs.microsoft.com/dotnet/performance-improvemen...

fumeux_fume 2y ago

Had a crypto class that let us choose any language that used .NET. My homework in F# was so much easier to read than everyone elses. Would def use it more, but nearly 100% of my data science work is Python.

gnarlouse 2y ago
That’s so cool.

arunc 2y ago

What is the state of F# a replacement for C# to create GUI apps on Windows? Are there companies using F# for this purpose?

neonsunset 2y ago
There are a few options: https://github.com/fsprojects/Avalonia.FuncUI https://github.com/fsprojects/Avalonia.FuncUI https://fabulous.dev/ https://fabulous.dev/ (which targets Avalonia/MAUI/Xamarin) https://github.com/kekyo/epoxy https://github.com/kekyo/epoxy (Avalonia and WPF) > Are there companies using F# for this purpose? I can ask around if you're interested.
- deleted 2y ago
  [deleted]
- stackskipton 2y ago
  I'm in this world, few companies are doing GUI apps at all these days. Most have long converted to Web Apps. Since it's pretty tiny minority of .Net users use F#, I'm sure someone somewhere is using F# for GUI but it's going to be tiny shop somewhere.
- arunc 2y ago
  Appreciate it, thanks!
deleted 2y ago
[deleted]

fluid_ident 2y ago

I really miss working in F#, such a productive language. But I still enjoy keeping tabs on the updates. I always thought the tooling was quite good, given the size of the community and Microsoft's apparent apathy towards it at times. The biggest pain point for me was accuracy in code test coverage.

sundarurfriend 2y ago

How does the versioning for F# work? These seem like a bunch of nice quality-of-life improvements, but a major version change doesn't seem warranted in terms of semantic versioning - no breaking changes - nor in terms of a major leap in terms of language features that a non-semver project might use as a reason to go version 8 to version 9. Another comment mentions .NET9 that recently came out, is that the reasoning here, to keep in stride with .NET version numbers?

guhidalg 2y ago
For both C# and F#, the version of .NET indicates the version of the build tooling (msbuild, compilers, nuget packages, etc...) that will be used to build the code whenever you invoke `dotnet build`. That means, for example, that the F# team _could_ have shipped a language change between versions 8 and 9, but if they didn't then at least they could have shipped a compiler change or an msbuild change that required .NET 9 for whatever reason. For developers, usually you can just update your code to the latest available runtime version unless you have to wait for your deployment environment to have the latest .NET version installed. Nowadays that's not necessary due to MSBuild changes to create self-contained deployments, but something to know.
- WorldMaker 2y ago
  C# will deliver the 13.0 compiler with .NET 9.0. It is a fun coincidence that F#'s 9.0 release coincides with .NET 9.0.
jbjbjbjb 2y ago
A new NET version comes out yearly and the C# and F# versions align with the yearly version but C# is ahead by 4. Semantic versioning is overrated anyway.
- WorldMaker 2y ago
  It is fun to point out that the VB.NET compiler is still at least 3 versions ahead. As far as I am aware VB.NET hasn't had a major version number bump since 16.0 (around .NET Core 3.x or .NET 5, as I recall), but the VB.NET compiler still also claims the 6 versions before .NET. C#'s (lucky) 13.0 in .NET 9 is also just partly related to the non-linear version numbering of .NET itself with the long shadow if .NET 4's many minor releases that were also "major", the Core divide, and the eventual "unfork" at 5.0. F#'s 9.0 matching .NET 9 is a fun coincidence, and also just because F# is younger and missed some of the .NET fun like 4.x "minor number is as important as major number" years.

jfausdfwsdfa 2y ago

> let notAValue: string | null = null When did F# get unions?

datadeft 2y ago
It had it since the first version as far as I know.
- ctenb 2y ago
  You're probably referring to Disciminated unions aka sumtypes? That's not what the parent meant
  - datadeft 2y ago
    I thought those are the same and I realize that there is a difference.
jfausdfwsdfa 2y ago
Damn. It's only for nulls: https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1060-nullable-reference-types.md https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-10... Wonder if they will generalize: https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1092-anonymous-type-tagged-unions.md https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-10...
- ctenb 2y ago
  At least they chose a syntax that makes it possible to generalize, which is a smart choice imho :)
  - robertlagrant 2y ago
    Yeah it looks a lot like Python's PEP 604[0]. [0] https://peps.python.org/pep-0604 https://peps.python.org/pep-0604

oDot 2y ago

Since the null-related blog post isn't published yet, anyone here knows the reason to implement null rather than write middle-layer in C# for whatever you want to use?

neonsunset 2y ago
At this point, almost all community and all standard library APIs use nullable reference types (and types that aren't NRTs are obviously expected to always have a value). This change in F# makes it able to interoperate with C# NRTs, where C#'s T? becomes F#'s T | null and vice versa. I feel like the ease of integration of F# into existing codebases is one of the major selling points. You don't need to write wrappers in order to consume most existing C# code, which, for example, enables writing a core with business logic in F# while keeping the IO in C# if necessary.
- algorithmsRcool 2y ago
  F# has chosen this approach of implementing compatibility with newer C# features such as support for ValueTuple<T> and Span<T>. It has been pretty successful at keeping F# inside the compatibility story. ---EDIT--- Mean to post this under the GP

wodenokoto 2y ago

How is the F# story on Linux/MacOS? Is it like a windows thing that you can also do on Linux or does it feel like a fully supported language?

algorithmsRcool 2y ago
F# is full supported on Windows, MacOS and Linux via CoreCLR and several more platforms via Mono, just like C# is
LAC-Tech 2y ago
Never noticed anything odd using in in linux.
runevault 2y ago
Same as C#. Anything that doesn't rely on windows libraries (so like various GUI libraries from MS) works fine on Linux and Mac.

ducdetronquito 2y ago

I only toyed with F# recently, but coming from Python I really like that I can also use a REPL to experiment stuff: I wonder if experienced F# devs use it too. I hope to have time to build a small web backend project this winter, to get to know the language and ecosystem better. I heard good things about Oxpecker for the http part; do you have any recommendation for a good postgresql client/driver ? (I don't like ORMs) Cf: https://lanayx.github.io/Oxpecker/ https://lanayx.github.io/Oxpecker/

yawgmoth 2y ago
Npgsql is the popular C# driver, and has an F# wrapper. I'd start there.
- ducdetronquito 2y ago
  Thanks :)
deleted 2y ago
[deleted]
throwaway675867 2y ago
As an polyglot dev who has the chance to use F# dev at times the REPL is how I POC most things - if I'm not sure of an API, even inlined into my actual codebase just hit the "Send to F# interactive" and it runs there and I can try things inside a module. Or when I want to try a new library, or when I want to do a quick benchmark, or as a substitute to a PS script, etc. You can even make F# scripts executable with the shebang `#!/usr/bin/env -S dotnet fsi` which we do a lot for scripts around our projects as an alternative to bash/python in our .NET projects where we already know a dotnet-sdk is installed. Usually runs faster too and typically just as concise. Just my anecdote opinion - the syntax and idioms of F# lean themselves more to REPL programming then C# which typically needs more OO structure rather than small code snippets strung together.
raphinou 2y ago
Here are 2 possibilities: - https://monazita.gitlab.io/monazita/ https://monazita.gitlab.io/monazita/ (i developed it for a project of mine while learning fsharp. Basically works but could be more polished and is pgsql only) - https://github.com/jacentino/DbFun https://github.com/jacentino/DbFun (more polished than previous project, and multi db)

algorithmsRcool 2y ago

F# has been my favorite language since I first encountered it in uni. F# was/is waaaay out ahead of C# with features like unions, null safety, pattern matching, records, more powerful type inference and generic constraints. Over the years C# has been implementing these features too, which is good, but they have been implementing them in incompatible ways, which isn't very good. Since the investment in F# has been much smaller than in C#, it hasn't been innovating as fast as C# and has been left behind in some ways. But it is still a great language and remains broadly compatible with the ecosystem and can deliver equal performance to C# with far less boiler plate

neonsunset 2y ago
Most incompatibilities can be summarized to "source generators" and tooling that relies on other forms of code generation. This can be fairly easily dealt with by writing a helper C# project with the necessary "glue". Other than that, is there something specific you have in mind? F# 9 even supports consuming ref struct generic arguments recently added to C# and plans to introduce their definition in F# itself AFAIK (which is likely going to be a nicer experience than in C#!). It has been doing impressively good job at keeping up thus far and deserves way more recognition for this.
- hansvm 2y ago
  Off the top of my head, async is monstrous to integrate between the two languages. Even when it works it's slow.
  - neonsunset 2y ago
    This was addressed in F# 6: https://learn.microsoft.com/en-us/dotnet/fsharp/whats-new/fsharp-6#task- https://learn.microsoft.com/en-us/dotnet/fsharp/whats-new/fs... Asynchronous sequences (IAsyncEnumerable) support is provided via https://github.com/fsprojects/FSharp.Control.TaskSeq https://github.com/fsprojects/FSharp.Control.TaskSeq F# is a very capable language - a broad spectrum of tasks can be solved by just implementing a new CE, something I could not even think of in C#.

srid 2y ago

For WebAssembly, there is Bolero: https://fsbolero.io/ https://fsbolero.io/ Unfortunately, maintenance seems to have stopped since Jan, https://github.com/fsbolero/Bolero/releases https://github.com/fsbolero/Bolero/releases (I tried creating a sample project on Linux which didn't work to begin with)

fayten 2y ago
I know this is a few days at this point but Bolero has been in active development. All development work was done on the now deleted streamrendering and v0.24 branches. Version 0.24 was just published today: https://github.com/fsbolero/Bolero/releases https://github.com/fsbolero/Bolero/releases

xiaodai 2y ago

[flagged]

asdf123qweasd 2y ago

I dont know, i have used F# for a while now. My problem with it- is discoverability and reuseability of the created code. It is very hard to read and get in - compared to classic OO and its hard to reuse something created and custom tailored. My 2 cents, may be worth even less, due to my limited experience and a propably wrong approach by me.

munchler 2y ago
It takes a while to shed one's existing OO expectations, but after that, I think you'll find well-organized F# code to be easier to use than C#. Immutability and lack of side-effects makes it much simpler to reason about what someone else's code is doing, and then reuse it. If you have any specific examples of discoverability/reusability issues in F#, I'd be curious to hear them.

blastonico 2y ago

I love F#, but it depends almost exclusively on Microsoft, which is not a main priority. What if Microsoft decides to stop developing it?

munchler 2y ago
It's an open-source project with its own F# Software Foundation. If Microsoft drops it, I think it would continue. https://fsharp.org/ https://fsharp.org/

deleted 2y ago

[deleted]

gnarlouse 2y ago

What’s new in F# 9? Well of course that would be G#.

amenhotep 2y ago
It seems insufficient to accord you only one upvote for this.

725686 2y ago

I have never done F#, but when I was looking around it this seemed like a greate resource: https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/

rmunn 2y ago
That is indeed one of the best sites for people new to F#, both experienced C# devs and those relatively new to programming. It's rarely updated any more, so you won't find discussion of the new F# 9 features there, but the existing articles are excellent for getting your head wrapped around concepts like `apply` and `bind`.

shadytrees 2y ago

Rider's recent free non-commercial license makes F# a much more attractive option for macOS, I think

obeavs 2y ago

Well, I made a large, multi-year company/technology bet on top of F# with Phosphor. After over a year of trying to make it work, we completely rewrote the application in Typescript and Rust. The product we're building is an end-user programming tool where the traditional lines between front-end and back-end work blur, and the .NET ecosystem really didn't lend itself well to this. Our hope was that we'd be able to use the Fable library to maintain type safety across a variety of technologies while being able to interop and in and out as needed: Fable compiles F# code to JS, Rust, .NET, etc. The reality was that the interop story between the various libraries we'd use was much harder to achieve than initially expected, and managing and updating multiple dependencies and their bindings was an absolute PITA. The assumption that F# makes for beautiful, efficient code is still a safe one, I think. But the ecosystem and the way that it was designed makes it (in my view) applicable only for applications and software that have very traditional frontend/backend lines. F# would be used for the back-end only in that case. Today, two of the technologies I'm most excited by (and which we're using internally) are the Effect library, whose Schema library fills in a lot of the gaps in TS's type system, and Moonbit, which is what I imagine a modern version of F# would like, free of the MS/.NET dependencies. Moonbit is really, really well designed (designed by the creator of OCAML's version of Fable, ReScript), and it compiles directly to highly optimized JS, WASM or Native output. We're using Effect in production, and not yet Moonbit, but the promise Moonbit holds as a language built for an AI-first world is pretty fantastic.

williamcotton 2y ago
I’ve had a good experience exposing F# code that compiles to Typescript modules. The approach was to write the core business logic and validators in F# and the rest of the front-end application in Typescript and the back-end in C#. That is, core business logic and validators in F# and all of the IO in TS and C#.
satvikpendem 2y ago
Is your company related to Darklang by any chance? I recall they were a product similar to yours, written in F# as well, but I haven't kept up with them recently. Effect is pretty nice, I wish it existed in other languages than TypeScript too. Regarding MoonBit, it seems like its own proprietary programming language so I'd hesitate to move to that over something well known, what are your thoughts on that aspect?

textlapse 2y ago

Are there large, real world/OSS SW that uses F#?

raphinou 2y ago
Not pretending my project is large or important, but it is an example of a non trivial project written in fsharp: https://gitlab.com/myowndb/myowndb/ https://gitlab.com/myowndb/myowndb/
onpikono 2y ago
NRK, the Norwegian state television runs their web and streaming platform on F#. https://tv.nrk.no/ https://tv.nrk.no/
fluid_ident 2y ago
Jet.com. They were a (little) competitor to amazon before they were bought by Wally-mart. They are replacing the F# with Java though: https://news.ycombinator.com/item?id=39592760 https://news.ycombinator.com/item?id=39592760
- lucidguppy 2y ago
  Its weird they didn't switch to C# - that would have been a much smoother transition to a memory managed brackety language.
  - WorldMaker 2y ago
    The rumors I've heard is that it is the "Oracle Golf Club Handshake Problem" in action: the current C-Suite of Wal-Mart got wined and dined and golf outing-ed a bit too much by Oracle who wanted a large contract expansion with massive revenue boost (for Oracle) and were promised a bunch of software resources/troubleshooting/consultant time in the next contract if they switched to far more Java. That sales job turned Java into a top-down mandate. It is a fun modern version of the "Nobody went wrong ordering more products and consulting from IBM" problem if IBM had an even more ruthless sales department and also owned too much of the database industry and too much of the Payroll/Time & Attendance industry (and worse, their legacy purchasing decisions and sunk costs) because no one has cracked down hard enough on vertical monopolies in the last century. Allegedly, of course. I'm sure Wal-Mart PR will happily tell you it was their own idea and how Java is the language of the future again, or something to that effect. Also, whether or not the rumors hold, it is hard to discount the pure Occam's Razor that it was just Wal-Mart's own idea to cut costs because of the simple dumb fact that labor costs in Wal-Mart's home labor markets for Java developers are certainly cheaper than .NET developers in the same job titles/experience levels. A mandate to switch to Java certainly was one cheeky way to do a slow layoff of expensive laborers without doing a real layoff.

Permik 2y ago

Kinda disappointed that they allowed null into the language, they should've just made some syntactic sugar or some auto bridge to reinterpret them nullable types as option types. Well, too bad. Not that I was a huge F# user anyway :D

Smaug123 2y ago
That would be a breaking change; certainly it's impossible to do that in the presence of reflection, and I imagine there are simpler cases. (See discussion on the similar https://github.com/fsharp/fslang-suggestions/issues/884 https://github.com/fsharp/fslang-suggestions/issues/884 .)

pjmlp 2y ago

A great programming language, pity that managment isn't that supportive of it, always feels like they consider it was a mistake adding it to VisualS Studio 2010, given how little of Microsoft own frameworks and Visual Studio tooling have first class support for F#. So we are mostly left with the community doing most of the work in a company with enought money to burn in deals like the Actvision Blizzard one, but not to staff the F# team appropriately (and they aren't the only one in such a state).

neonsunset 2y ago
Perhaps it could have been treated better, but then if you compare it with Kotlin, Scala or Clojure - F# ships with the main .NET SDK. It does not need to be installed separately, no user action is required to jump into an F# project immediately or to add an F# project to an existing solution. You can simply dotnet new classlib/console --language F#, dotnet build and it is ready to go. It could use more marketing, halo projects and word of mouth though.
- pjmlp 2y ago
  Kotlin and Scala don't belong to any JVM implementation vendor, like F# belongs to Microsoft. And if consider Google to be a platform vendor with hands on Kotlin, then Android / Kotlin development experience is certainly much better than F# has ever achieved since its Visual Studio 2010's introduction. What F# has going for it, despite everything, is its great experience on Windows, versus Haskell and OCaml, which remain UNIX centric at heart.

fire_lake 2y ago

The Tail Call attribute is a huge improvement. TCO is a requirement for correctness and now we can enforce that at compile time!

runevault 2y ago
I wish every language with TCO supported some way to tell the compiler "if this cannot be optimized away I want an error." All it takes is a moment of inattention to screw up.

candl 2y ago

Should one use the result type for handling errors or exceptions or both? What's the rule in F#? When should you prefer immutability over mutability since both are possible in F# and it probably has a measurable impact on performance? When should you use objects instead of records or unions in F#? Since mutability is possible, any reason to not allow an explicit return or continue? It makes certain code patterns much less nested and easier to read.

infogulch 2y ago

louthy/language-ext [1] is a C# library which does its darndest to build a fully functional language inside C#. I found it very interesting and used it for an experimental project (which ended up failing, not sure if my usage of language-ext was partially to blame). People told me I should have just used F#. Anyone familiar with both that can compare them? [1]: https://github.com/louthy/language-ext https://github.com/louthy/language-ext