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
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.
> 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.
> 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.
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.
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.
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#.
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?
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.
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.
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)
- 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)
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.
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?
So .NET and C# have moved recently-ish to yearly single digit incremented releases and I’m guessing F# is doing the same. Not sure if they intentionally made the switch when it would line up with the .NET version or if that’s just a coincidence. C#, for example, released version 13 for .NET 9.
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.
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.
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`.
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).
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.
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.
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
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.
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.
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#.
[+] [-] algorithmsRcool|1 year ago|reply
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|1 year ago|reply
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.
[+] [-] sevensor|1 year ago|reply
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|1 year ago|reply
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.
[+] [-] fuzztester|1 year ago|reply
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/
[+] [-] obeavs|1 year ago|reply
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|1 year ago|reply
[+] [-] satvikpendem|1 year ago|reply
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?
[+] [-] fumeux_fume|1 year ago|reply
[+] [-] gnarlouse|1 year ago|reply
[+] [-] neonsunset|1 year ago|reply
https://devblogs.microsoft.com/dotnet/performance-improvemen...
[+] [-] fluid_ident|1 year ago|reply
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.
[+] [-] ducdetronquito|1 year ago|reply
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/
[+] [-] raphinou|1 year ago|reply
- 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 (more polished than previous project, and multi db)
[+] [-] yawgmoth|1 year ago|reply
[+] [-] throwaway675867|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] sundarurfriend|1 year ago|reply
Another comment mentions .NET9 that recently came out, is that the reasoning here, to keep in stride with .NET version numbers?
[+] [-] sbelskie|1 year ago|reply
[+] [-] guhidalg|1 year ago|reply
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.
[+] [-] jbjbjbjb|1 year ago|reply
[+] [-] arunc|1 year ago|reply
[+] [-] neonsunset|1 year ago|reply
https://github.com/fsprojects/Avalonia.FuncUI
https://fabulous.dev/ (which targets Avalonia/MAUI/Xamarin)
https://github.com/kekyo/epoxy (Avalonia and WPF)
> Are there companies using F# for this purpose?
I can ask around if you're interested.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] 725686|1 year ago|reply
[+] [-] rmunn|1 year ago|reply
[+] [-] wodenokoto|1 year ago|reply
Is it like a windows thing that you can also do on Linux or does it feel like a fully supported language?
[+] [-] algorithmsRcool|1 year ago|reply
[+] [-] LAC-Tech|1 year ago|reply
[+] [-] runevault|1 year ago|reply
[+] [-] pjmlp|1 year ago|reply
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|1 year ago|reply
It could use more marketing, halo projects and word of mouth though.
[+] [-] candl|1 year ago|reply
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.
[+] [-] textlapse|1 year ago|reply
[+] [-] onpikono|1 year ago|reply
https://tv.nrk.no/
[+] [-] fluid_ident|1 year ago|reply
[+] [-] raphinou|1 year ago|reply
[+] [-] fire_lake|1 year ago|reply
[+] [-] runevault|1 year ago|reply
All it takes is a moment of inattention to screw up.
[+] [-] srid|1 year ago|reply
https://fsbolero.io/
Unfortunately, maintenance seems to have stopped since Jan,
https://github.com/fsbolero/Bolero/releases
(I tried creating a sample project on Linux which didn't work to begin with)
[+] [-] fayten|1 year ago|reply
[+] [-] asdf123qweasd|1 year ago|reply
[+] [-] munchler|1 year ago|reply
If you have any specific examples of discoverability/reusability issues in F#, I'd be curious to hear them.
[+] [-] shadytrees|1 year ago|reply
[+] [-] infogulch|1 year ago|reply
Anyone familiar with both that can compare them?
[1]: https://github.com/louthy/language-ext
[+] [-] blastonico|1 year ago|reply
[+] [-] munchler|1 year ago|reply
https://fsharp.org/