why use F# for scripting and automation?
19 points by kryptiskt
19 points by kryptiskt
As much as I enjoy using it, it's sad, but I have much less confidence anyone on a random team would be comfortable writing or updating F# code. It's not that hard, it's just another hurdle to get over. This might be the one case where "Nobody Ever Got Fired For Buying Microsoft" isn't true, as bringing in F# scripts is a lot more wild than just using Python, especially with recent uncertainty about Microsoft.
However, LLMs have provided a huge boon to dealing with weird things in the language.
if something broke, you get a red squiggly line as feedback
it points to where it broke immediately
Compile time feedback before running is a big reason I've tried multiple times to use F# as a scripting replacement. When it works, it's great, but Python tooling is much more consistent overall. As of a week or so ago, an .fsx (F# script) file in Rider didn't do this for me, while working well for the .fs program right next to it. When the tooling works, it's great and feels like a lite, batteries included, GC'd Rust. When it doesn't, I question why I didn't just use Python in the first place.
the script contains all the code you need to run it, including dependencies and versions
I can see this being a headache for IT/security, though I haven't used F# scripting in a professional setting enough to know if there are mitigations.
F# runs on .NET, which means you have access to a massive ecosystem of libraries and tools
This puts F# in the same category as Python and Go for tooling in terms of "What batteries are included."
I can see this being a headache for IT/security, though I haven't used F# scripting in a professional setting enough to know if there are mitigations.
It's called "host your own NuGet registry and configure developer desktops to use it" which every company I've worked for has done.
I agree with you completely that i don't have much confidence on a random team wanting to adopt F# when Typescript/Python/Bash is available. Before Typescript got popular, F# was in a much better position as a single full-stack language. Nowadays I can't really figure out where .NET/Java lands on the scale of convenience to perfection.
The Javascript ecosystem is currently on course to overtake all programming languages in popularity, JS/TS combined is almost at 10x the popularity of Java/.NET and even 2x of Python.
a random team wanting to adopt F# when Typescript/Python/Bash
as a single full-stack language.
The one professional use of F# that I know, had a successful web-based product and team that absolutely LOVED the language, but then they got overridden by higher ups and forced to convert to C#, supposedly to 'ease hiring.'
I overlooked the .NET ecosystem for a long time, but the idea of having a unified automation/scripting/web/application system on top of .NET seems extremely powerful.
I tried playing with f# for a little bit for a osu! sync tool (cause realm db format is supported natively in .net)
overall i would say ocaml’s tooling feels more well rounded (?) and all features mentioned in the post (type system, error msg, pipe operator, etc.) but arguably, using f# for network requests is way way way easier comparing with ocaml
but there are still stuff in ocaml that are better (at least for me). instead of writing xml with smth like Project >> ItemGroup >> Compile etc. i think ocaml’s dune using sexp is more ergonomic
I was "forced" to do scripting in Rust for a while and... I actually liked it. With scripts it's hard to fall into complex ownership issues and mostly every borrow checker problem has an easy way out.
And it was damn refreshing to have a good editing experience and type checking was nice for refactors.
I am mostly doing Python now for scripts, which is slightly worse in places, but nicer in others, but I think there's room for some statically typed language for scripting. Esp. if you can do inline dependencies (like the article shows for F#).
However, I think both Rust and F# are a bit too exotic, which is a bit of a minus because likely people will need to upskill. I think I've seen a few interesting projects in this space, but none have gained too much traction.