Funny you mention F# and Clojure, as these were the only contenders for a product I am building with a partner. We went with F# and are quite happy thus far.
What's the cross platform / native story for F# (for real) ? Can you build a relatively efficient binary that just runs and does not take an hour to open a gui window ?
I've been developing F# things on linux for close to a decade now (though my last official position doing so was ~7 years ago, it's just my default hobby language that I know best).
I have zero trouble developing on linux.
Building GUI or non-GUI software works fine.
I use Rider and work on web systems, a handful of scrapers that feed some data I collect, as well as various small GUI systems.
I think F# might have _the highest number of viable ways_ to build a GUI application if that's what you're looking for.
You can go the fable (F# -> JS transpiler) route and use any of the js tools (electron, nodegui, etc). The popular one's (react, preact, svelte, etc) have type definitions that folks have already written.
F# works with most of the dotnet gui libraries just fine, though I don't know for sure the story about winui, but from people I know working on production systems using it, they recommend to avoid it. So you've still got WPF, etc.
For the newer cross-plat stuff, there is Avalonia, Uno Platform, Xamarin (with the natives) or the newer version MAUI.
---
The thing here is that there aren't really limitations to almost all of the things I've listed above.
Transpilation targets work fine, as do the dotnet targets. Almost every one of these also has "Elmish" frameworks (Functional Reactive Programming state management) suited for the purpose:
I've never felt constrained building GUIs in F#, other than some of the dumpster fire that was Xamarin.Forms and the Xamarin build tools (native targets never gave me any problems that I can remember).
I took a partial Fabulous 1.0 (Xamarin Forms) application that I had only worked a couple days on, and out of anger with Xamarin build tools lifted and shifted to a react-native application. Almost my entire elmish (view-logic layer) was preserved, and I just had to change the view elements out from Xamarin.Forms elements to React Native elements.
---
I don't work with F# too much in an official capacity these days, but it's a decent tool to have as a default.
Our work is incredibly i/o-bound, so we would probably not see much of a performance difference no matter what language we chose. Additionally, our presentation layer is served directly from an in-memory, columnstore database and is divorced from our back-end by a batch ETL process.
To give a high-level overview of what we are doing, we call a series of APIs which can provide current-state metadata about a SaaS platform. We poll those APIs on a schedule and diff the results over time, providing to our customers a view of this change over time. So our work is to schedule these API calls, wait for the results, persist the results to storage, and then identify the deltas. Once this is done, we load into our presentation layer for customers to interact with.
We run an independent process per customer and use OS permissions to isolate these from one another, and plan to containerize these processes for further isolation. Customers each get a local ZFS dataset and a separate blob storage container. Isolation is a big deal for us, as the permissions we require to call these APIs for our customers end up being a de-facto global admin (this is a limitation of the SaaS vendor, not us). The dataset-per-customer model allows us to lose a single (and backed up, so not really single) encryption keyfile to forget everything sensitive from that customer.
This last paragraph only emphasizes that the language is not the most significant consideration for our work. We could probably orchestrate the API calls as effectively in shell pipelines. The diffing process is a bit hairier, and my current focus.
F# 6.0 added the 'task' computation expression, which is much more performant than the F# 'async' methods. It also makes interop with C# projects and libraries simpler, as is uses the same mechanism that C#'s async/await does. I have used it in production workflows without major performance issues FWIW.
I would be curious to hear more about this. My response to a sibling explains how we do not have huge performance considerations right now (and our i/o-bound nature). Due to the primary work of our product, we are utilizing async workflows extensively. We are on 6.0, and evaluating if we want to chase the 7 series release or just hop to the next LTS.
