←back to thread

Why F#?

(batsov.com)
438 points bozhidar | 2 comments | 01 Apr 25 12:34 UTC | HN request time: 0.404s | source
Show context
darksaints ◴[01 Apr 25 18:08 UTC] No.43549778[source]▶
I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems. More significantly, they are being passed up in favor of Rust, which is a great language but nonetheless a bad fit for a lot of problem domains, simply because Rust has a superior build system. Hell, 80% of the reason I choose Rust over C++ for embedded work is because of the build system.

It baffles me that there are languages with non-profit foundations and are financially backed by multiple corporations which still have bad build systems. It is the most important investment you can make into a programming language.

replies(7): >>43551301 #>>43552671 #>>43554790 #>>43554888 #>>43555737 #>>43556392 #>>43559547 #
jadenPete ◴[02 Apr 25 00:34 UTC] No.43552671[source]▶
It’s always puzzled me that so many languages have their own build systems and package managers. Why aren’t programming language-agnostic build systems like Bazel and Buck more popular? It seems so strange that every new programming language essentially has to reinvent the wheel multiple times, inventing a new build system, package manager, formatter, linter, etc. I wonder if we’ll ever see something like LLVM for these technologies.
replies(2): >>43556072 #>>43556707 #
1. Rohansi ◴[02 Apr 25 12:49 UTC] No.43556072[source]▶
Because there are differences that go beyond just the language syntax. The build processes are very different for C++ vs. C#, vs. F#, etc.

C++: invoke compiler for all compilation units, invoke linker to combine object files into executable

C#: invoke compiler once with all source files listed

F#: same as C# AFAIK, except file order matters!

replies(1): >>43557979 #
2. fodkodrasz ◴[02 Apr 25 15:43 UTC] No.43557979[source]▶
C++ I have worked only a little with it, more so with C, but AFAIK order of files does kind-of matter, so at least declarations need to be present in each file upfront before use.

C# has a multi-pass compiler so that it can compile and link the components from multiple files, without need of placeholder declarations, regardless of the order the symbols appear in the files.

F# has a single pass compiler, which keeps the compiler implementation simpler, but the file, and symbol definition order does matter that way. This is totally intentional, this is supposed to make the codebase more straightforward, with which I personally agree with. This avoids the need for declarations and centralization of them, the includes all the baggage that comes with that approach, and all the complexity C# has. I have rarely found a limiting factor, though there are some cases when it can be a bit inconvenient, for me the application setup/composition (~DI, but I prefer more static approach in F#) needed some cumbersome refactoring in some cases (have only vague memories by now, and yes, I know co-recursive types exists)

I really like F#, but rarely have to opportunity to work in it.