A new F# compiler feature: graph-based type-checking

I would recommend two. F# in Action [1] by Isaac Abraham is a great (and recent) introduction to the F# language. For a more philosophical, domain-oriented book, you can't go wrong with Scott Wlaschin's Domain Modeling Made Functional book[2]. Scott's blog[3] is also must-read material.

[1] https://www.manning.com/books/f-sharp-in-action

[2] https://pragprog.com/titles/swdddf/domain-modeling-made-func...

[3] https://fsharpforfunandprofit.com/

Also Fable is pretty cool https://fable.io/

Here build times are not really an issue as it seems to be hot-transpiling to js, so save and site is reloaded almost instant (at least small sites):

My small tools site built with Fable: https://peheje.github.io/compare.html

If you look at the JS - that's of-course the production minimized build, the transpiled JS is pretty nice and readable.

Super simple site - vanilla JS seems wonderfully easy with F#, easy to hide its warts and build easy re-usable items.

But there's of course also smarter stuff with two-way bindings via html annotation and builders etc. I am actually using Feliz.ViewEngine, which is building the HTML using F#, but only for the navigation bar. Might try converting a page to it.

This is very neat, I love the idea of using the syntax tree to guide what can be parallelized vs. not.

As some additional background, there's a very good reason why the F# language typechecks files sequentially. Because F# supports type inference at every scope, a single change in the body of a function can result in cascading type changes across an entire project. This kind of change can not only affect other files, but other files inside of other projects in the same solution.

A way to curb these kinds of cascading changes is explicit type annotations and/or signature files, which "lock" the type signature for a given construct/file. And the F# compiler has had optimizations in place when signature files are used to know when to re-check stuff based on this. However, these didn't extend to the sequential typechecking of files, and for the large majority of codebases that don't use signature files, these optimizations didn't really kick in anyways.

While f# is definitely founded in functional paradigm. I feel like it's more a universal language.

Like Kathleen says in her intro to f#6

https://youtu.be/jOrgDoMuFog?si=Dnu8kPPi5QS5rNOR

"Im gonna do cool stuff like fold this unfold that. Dom said. Why don't you just write code?" (Paraphrasing it's first of the video)

F# is my go-to language for new backend projects and console apps. You can be as functional as you like, with imperative/mutable/OOP escape hatches available for those rare but unavoidable times you need them