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.
That's interesting. In Haskell top-level annotations are not required but I don't think I've ever seen a real project without them - its basically a community standard that's universally adopted, in a community that doesn't adopt many standards.
It's useful to keep these anyway, as if you make a change that accidentally changes the type of some function, the error message makes it immediately obvious what you did. Otherwise it's hard to tell whether you messed up the function or the caller.
Also having type annotations makes code reviews easier. Basically people's brains can use the same optimization that compilers do.
There is also a helpful compiler command to generate updated signature files for you. Then you just glance at the git changes and see if you accidentally broke an API or not.
May I plug https://github.com/G-Research/ApiSurface/ ? It ensures this as part of your testing pipeline, and requires an appropriate minor or major SemVer bump if you alter the API in a non-breaking or breaking way.
We've been building a very technical product in F# + Rust for the last three years or so (think R lang + R Studio or Replit but for DSLs we built for finance and contracts).
While most folks tend to see F# as a .NET-oriented/back-end kind of language, they'd be missing some incredibly unique web technologies such as the Fable compiler (F# -> JS, Python, Dart, etc) and Elmish (Elm, but for F# with a JS target via Fable). It boggles my mind that more of the web dev community haven't discovered these tools.
These "communities" fall completely outside of MSFT's umbrella, but are transformative for how you think about architecting applications: Elm as an architecture (rather than as a language) enables a large amount of optionality in terms of what technologies one might use as a "reactivity layer" (e.g. can swap out React for SolidJS or even non-JS targets like Avalonia quite easily if it made sense to).
Our bet is that it enables us to future proof things in a number of unique ways as better WASM-based solutions come online as well that hopefully won't require shipping the whole .NET runtime (e.g. Bolero). The approach is also v helpful in managing state across an otherwise very complex application.
I looked at Fable and the resulting code just looked way more complicated than anything Javascript could write. I'm interested in F# still on the backend, but I don't think people "haven't discovered" Fable, it's just not a great alternative.
Yeah, I suppose it depends on what you're building.
Three years of building with it (plus constant re-evaluation of that decision) has supports our conclusion that it is far more concise and easier to manage (esp for less technical folks who need to sign off on the business logic/domain) than anything we'd have done in JS.
With that said, we're building a product that requires much more interactivity than most, and we're performing a lot of typical "back-end" logic in the client - that might color our evaluation.
To be sure, it hasn't been without tradeoffs, but we haven't found those tradeoffs to be at the language level.
FWIW the benefit tends to come in the long run. Same argument as TypeScript, really. You add some conceptual overhead to get code that fails less in the face of change, better refactoring, etc.
Is it really appreciably different from "transpilation" with TypeScript?
Like, I have seen a little of both (I've used a lot of TypeScript, but who actually looks at the output JS lol), and while I agree the JS output from Fable seemed surprisingly verbose, I'm not sure I see how it practically matters unless one is worried about bundle size or something.
I'm not talking about that JS output, I mean the F# itself. While I'm not the most familiar with F#, I've enjoyed other languages that transpile to JS a lot more.
For whatever reason, F# to me looks surprisingly verbose in Fable, which is odd because it's pretty terse on the backend.
> In theory Elm is just such a fascinating project... if it was not held back by the people developing it.
PureScript may be worth a look, it’s got several features that were rejected by Elm devs: typeclasses, ability to publish modules that use FFI to JS, runs server-side, etc.
Please PLEASE enough with the character assassination of the Elm guy.
He wants to run his own project his own way.
There's a small but dedicated residue of people who just can't stand being told "no" and go around crapping on the kid whenever they get a chance.
I get it. You don't like Evan's project management style. Move on already.
- - - -
The fact of the matter is that he's a person who took his thesis, made it into a product, and got traction in the real world. People have used Elm to make things. Things that go.
How many of us can say the same?
And that's before you get to all the fascinating and as yet still-too-obscure things that the OP talks about. Things that are in part a little more widely known and understood thanks to Elm project.
We should be open & honest in our discussions about whether we genuinely recommend a platform or project to others, including the details which underlies our thoughts.
As I go through rewrites and greenfield projects and so forth, I begin to realize that for any particular technology you are not simply having a relationship with a static list of pros and cons, but you're also having a living relationship with the team behind the work.
In other words, a bet on TypeScript is also a bet on the TypeScript team, and in my experience the TS team is very fast at their work. This makes me more forgiving of bugs. Similarly, a bet on Terraform is also a bet on Hashicorp.
Here we have someone recommending a choice of F# over Elm because betting on the leadership is allegedly not good. This is not character assassination. The commentator is not criticizing Evan on irrelevant private affairs and by extension saying that you shouldn't use Elm. Evan has created a company and is advocating for his product; he is a public figure and is being criticized on the grounds of project management.
This is not only about leadership style, but also founding. I don't know the current TS team, but I know its dozens of full time workers backed by microsoft, not only core devs, but community organizers, evangelists, etc. There is no comparison to an independent project.
Eh, it doesn't seem like character assassination. Dude chose his management style. That makes his project unfit for purpose for certain people. Those people are allowed to make that determination and state as such.
I remember when the Elm team first decided to lock down the Elm compiler, so that only the team in charge had special privileged access to modify it. I thought, "wow, this looks like a bunch of people who don't want to collaborate, who want to take their ball and tell others how to play with it, really putting the 'dictator' in BDFL." and you know what? that's fine. I don't harbor anything against them as people. But that left a permanently bad taste in my mouth and I'm unlikely to ever trust that group or a project they're managing.
Without this management style Elm would be the oppositive of what it is today
(simple language, very fast compiler, efficient tree shaking, no runtime exceptions) wanting to add at all costs Haskell features and JS direct sync interop.
Because of that management style, it has been bitrotting for FOUR YEARS and has even gotten forked by a couple people involved so at least some progress could continue.
I simply don't think locking down the compiler so only blessed Elm devs can modify internals was necessary. I don't think the flack given to people forking the repo was necessary. Say no to pull requests, fine. Don't try to control the technology.
From outside, with no knowledge of this "ELM Controversy", this is all very confusing.
I love the ELM Architecture. Why is there a problem if it is implemented in another language?
I'd think any functional language could implement the ELM Architecture, and thus be 'native', or more integrated into that particular languages ecosystem, and this would offer benefits beyond trying to integrate ELM into each individual ecosystem.
And doing this re-implementation, would in no way be a comment on the ELM founder.
Also, Doesn't Linus say "NO", quite a bit with Linux? Why jump on the ELM guy for doing same thing.
When Linus says no, he rejects features and pull requests. That's fine. That's responsibly shepherding your implementation.
That's not what Elm does. They lock down the compiler so only Elm devs can modify internals, which would be equivalent to Linus trying to prevent people from modifying the kernel.
They really don't like people forking their repo, which would be equivalent to Linus getting mad at people making derivative kernels (because it would "split the community.")
It's not just a matter of saying "no," it's trying to control what devs do to an UNREASONABLE degree.
The link is that Elmish is a competitor of Elm, and that the creator of Elm is a factor to the evolution of Elm. Leadership is a big deal in open source and is the sole differentiator behind the late iojs and OpenTofu. The matter of leadership is especially weighty for niche or emerging ecosystems like Clojure, Rust, or SolidJS.
FWIW my comment was along the lines of allergic reaction. I'm not an Elm fanatic, I'm just sick of seeing people snipe on the dude.
You're entitled to your opinion, of course, and you articulated it well. But again I see it as another example of someone not liking being told "no", no?
That's really reductive and biased against us, the potential user base of Elm that decided not to engage. Why is it that we don't like being told "no," as opposed to the Elm leadership and Elm community not liking being told "this isn't a 100% solution for me so I'd like to modify it"?
Obviously Elm is his passion project, that's fine. But nobody who locks down their compiler on a supposedly "open source" project can actually seriously expect others to engage with that in good faith.
Furthermore, the absolute state of just trying to modify Elm to be more fit for purpose is horrendous. Every time I see a parallel implementation or a fork, the author has to bend over backward with platitudes to placate the Elm masses and ensure them that this project isn't trying to "split the community," which is a nonsense idea to start with imo.
It feels cultish, on top of a project that is actively hostile to people who want to use it any way other than how the BDFL has mandated its usage. If you want to say the problem is with the users, that's fine, but that's exactly the attitude keeping me from ever engaging. I personally think the problem is with the people who want such fine control over their technology and community, as opposed to understanding that they can really only shepherd their implementation. That's about as far as their reach rightfully extends.
EDIT: also, the fact that they aggressively lock down their compiler and have such hostility to anyone working in parallel is imo the definition of "holding it back"
> That's really reductive and biased against us, the potential user base of Elm that decided not to engage.
My complaint isn't that you or anyone doesn't engage with Elm, that's your prerogative, of course.
My problem is that a small segment of people do engage with it whenever it comes up to smear the project in general or Evan in particular for nothing worse than wanting to run his own project his own way.
He's not an ogre? I mean here he is, look, he semms nice enough to me?
"The Economics of Programming Languages" by Evan Czaplicki (Strange Loop 2023)
https://www.youtube.com/watch?v=XZ3w_jec1v8
As far as I've seen, there was no attack on the person.
What I usually see are warnings about what happened to the project and how it is run, mostly targeted to the unaware. This is a sign of respect to people's time before they waste it on something that might disappoint them when they get to know the details.
Every time Elm comes up people climb out of the woodwork to cast aspersions on it for no better reason than that Evan wants to run his project his way. Some people evidently just can't accept that and have sustained a grudge that drives them to comment on it whenever it comes up.
Look, I get it, I'm still sore about Google Feed Reader, 'member that?
But enough is enough. It's old news. Get over it. Etc.
It's like if every time someone mentioned Caddy server there was someone bringing up that time Matt Holt put that header in and pissed off a bunch of people. Life goes on. We forgive and let things go.
It's high time for folks to forgive Evan for his mistakes. I mean, he's very young still, eh? Cut the guy some slack already?
Again, the things I read are not personal, grudges or inability to accept someone's personal choices. For starters, you write his name more than anyone else here. You're not doing him any favor specially when it comes to Streisand Effect.
When I propose a tool to my CTO I couldn't care less about the project's leadership personal choices.
Mature engineers think in terms of ROI, dependability, bus factor, predictability, funding, mind-share, hiring ease, license, etc.
But it would be naive and unprofessional of me to handwave technical issues with the tools. And ALL tools have hard edges and undesirable characteristics.
And putting a header in a HTTP server is not proportional as restricting who can change the source code of a compiler.
Evan wants to control the technology. That's a management decision that makes it unfit for purpose. This is a legitimate criticism that had long ranging impacts. I have seen no reason, no commitment from the management side, to believe this won't happen again. It is worth bringing up when there are similar alternatives without such a spotted history of lockdown and control issues from management. I know nothing about the fellow. This is not personal.
My understanding of this is that he managed to hype the language with certain killer features. A lot of people were enthusiastic and invested alot of time in learning and building in it. Evan than "suddenly" said they wanted to take the language in another direction and dropped some of the core features and pricipals that drew people in. While perhaps a mischaracterization, it comes a cross as a kind of "bait and switch" or at least undependable.
But the trail never ended at "one ought not critique my critique", so who are you responding to? If anything, saying that something is character assassination is a statement on what's off-limits for debate.
Totally agree. Even the mention of Elmish, which has nothing to do with the creator of Elm, is derailed into yet another discussion of why some people hate the creator of Elm. It is the deadest of beaten horses on HN.
He's absolutely entitled in running his project his own way. As such, it is obvious that adoption outside of his own circle is to remain minimal.
I would love Elm to be in a position where I could advocate for it at work (aside from it being a "neat hobby"). However, the simple fact is that the way Elm is run has lead to disillusionment among advocates of the first hour. And there is nothing to indicate that this will change.
And if the guy has inspired a new generation to create something to his own achievement, kudos to him. As far as I'm concerned Elm is not the enemy, JavaScript is the enemy.
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
Have to agree. Recently decided to try out Python instead. Everyone at work wanted Python, it's popular, so why not give it a shot. In constant regret, missing the type checking in F#.
for console apps, F# sadly suffers from general .NET issues for console apps. Very large size (>150MB for a simple app) and at least 400-700msec startup time
AOT compilation is actually usable in net7, and I'm told it's got much better in net8 - massively reduces startup time (and in net8 apparently binary size too)!
I concur. All the .NET devs seem to prefer C# and are afraid to go near F#. It seems to be out of their comfort zone.Once people learn to code one way, they
often don't want to try new things, since C# works and pays the bills, they don't even try F#.
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.
Noob question. I developed projects in OCaml (ocaml + opam + merlin + core/async) on linux/macos. I'm clueless about F#, I've always thought of that as some sort of JVM for Windows, not great for Linux. How would my experience compare if I was to use F#? not so much in term of language, but developer experience: IDE integration, richness of stdlib and third-party libs, build system, package management, tools stability.
I only tried F# for few days, but it was a pleasant experience on both macos and linux.
dotnet CLI should take care of build process, it can even generate self-sufficient executable (that bundle parts of .NET in them). The infamous required XML boilerplate has also been cut down to near-zero.
My biggest gripe is that Microsoft's debugger is closed-source and proprietary (though free for users of official VSCode builds). There is open-source netcoredbg by Samsung, so you can use VSCod[e,ium] with https://open-vsx.org/extension/muhammad-sammy/csharp , but YMMV.
JetBrains Rider is really excellent until you start getting up to like the 30-project mark. Stdlib is very extensive although has a bunch of annoying quirks due to being like twenty years old and due to having Linux retrofitted onto it; I have personally had to reimplement parts of its API from syscalls, but if performance isn't super-important for you then it's OK. MsBuild (the build system) and NuGet (the package manager) are both absolutely cursed, but if you are doing totally vanilla things then they're usable out of the box. The `dotnet` command line tools are weirdly inconsistent, sometimes buggy, and full of edge cases even in the places where they are self-consistent, but again if you're doing something super-vanilla then they should be fine.
I’ve never ran into an issue with 30+ projects open though I question why one would have so many in one project in the first place personally, but I never had an issue
F# also has an alternative toolchain based around Paket[0] and Fake[1]
FWIW I don't think there's much reason to use paket and FAKE these days. FAKE just shells out to msbuild (and usually via dotnet) and it's pretty easy to use targets/props files if you want to factor a few things out of project files. Although even that is of minimal benefit. Paket is still different, but it's not 2016 anymore. The default nuget client is stable and fast. IMO these tools served the community well for a decade or so, but it's not worth bringing into a new project.
YMMV with the build and package system depending on your experience. Sheet staying my career writing with JVM languages and then moving to C#, I far prefer MSBuild + NuGet over Maven or Gradle. But I know lots of folks who feel the opposite, so maybe it's just a matter of preference.
I primarily use F# on linux and the experience is very smooth.
editor: VSCode + ionide extension
stdlib: F# has its own stdlib but it can also access all of dotnet's stdlib seemlessly.
libs: Many of the 3rd party libs are written in C# in an OOP style but you can still use them. Most of the popluar ones have functional F# wrappers if you don't like OOP.
build: the dotnet cli is very advanced and not too hard to grok.
I haven't used F#, but I have had to build OCaml programs from source on Linux and my god OPAM is the worst thing since Autotools. Maybe worse - Autotools actually works!
OPAM - despite the appearance of a modern language management tool - seems to fuck things up almost every time I use it. And not just me. The amount of time I was spending helping coworkers fight it got so much I gave up and just added a caching system so they wouldn't have to deal with the pain of OCaml at all.
So if F# manages to improve on that even slightly I'd say it's definitely worth switching to!
Plus it's more portable than OCaml, which seems to view working on the most popular desktop OS in the world as beneath it.
F# is very cross-platform at this point because .NET 7 is very cross-platform. To install F# just install the .NET SDK. JetBrains Rider and VS Code with Ionide are the two cross-platform IDEs.
This is the type of feature that makes me want to use F#. Really great work, I would love to see similar work replicated in other languages (python's type checking libs especially). As an outsider it feels like the Bazel/Buck/Pants approach applied to type checking
Can anyone recommend a good hard copy book for F#? One that covers the syntax, language features, and covers functional programming fundamentals along the way?
Like, the F# book that Brian Kernighan would write?
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.
I had discovered Scott’s blog in the last couple of days while searching for resources related to writing lexers and parsers in F#. It is indeed a great resource!
Thank you for your other recommendations, I’ve just ordered both books!
He named UNIX, he invented the "Hello, world!" program, he's the K in K&R (The C Programming Language), he's the K in AWK, and he's the co-author of other classic works like The UNIX Programming Environment and more recently The Go Programming Language. He's currently a CS professor at Princeton.
EDIT: Why the downvotes? It's just terse, it's not at all rude.
Several other books that are good have been mentioned, I'll throw in one more, Stylish f# 6 by Kit Eason. He does a good job covering things and it covers features up through the .NET 6 version of F# so less stuff to learn once you're done with it.
I have a tangential question that is related to this cool new feature.
Warning: the question I ask comes from a part of my brain that is currently melted due to heavy thinking.
Context: I write a fair amount of Clojure, and in Lisps the code itself is a tree. Just like this F# parallel graph type-checker. In Lisps, one would use Macros to perform compile-time computation to accomplish something like this, I think.
More context: Idris2 allows for first class type-driven development, where the types are passed around and used to formally specify program behavior, even down to the value of a particular definition.
Given that this F# feature enables parallel analysis, wouldn't it make sense to do all of our development in a Lisp-like Trie structure where the types are simply part of the program itself, like in Idris2?
Also related, is this similar to how HVM works with their "Interaction nets"?
I'm afraid I don't even understand what the difference between code, data, and types are anymore... it used to make sense, but these new languages have dissolved those boundaries in my mind, and I am not sure how to build it back up again.
> Given that this F# feature enables parallel analysis, wouldn't it make sense to do all of our development in a Lisp-like Trie structure where the types are simply part of the program itself, like in Idris2?
Yeah, maybe, you for sure could, but in the context of F# as it exists, it may be hard to get from here to there.
> 'm afraid I don't even understand what the difference between code, data, and types are anymore... it used to make sense, but these new languages have dissolved those boundaries in my mind, and I am not sure how to build it back up again.
Yeah, good luck with that. I think maybe taking a mental step away from programing might help. It's true that human interpretation of the world often has these properties. And he generalization of the systems in no way invalidate the usefulness of the categorization system. Maybe it's helpfulnto consider the properties of your classes.
To risk your further descent into madness. I recommend the Lambda days talk on the Verse programming language [1]. Which has further contemplation on the topics you are thinking about. With an eye towards practicality.
It would be nice if I stopped needing to update the fsproj file for imports and hierarchy. If this could be dynamically built using a topological graph approach that would be a huge improvement. I don't use a heavy IDE so it's kinda tedious to need to update the fsproj file when i want to add a new file.
Personally I strongly prefer F#'s way, and I always enable it manually in C# by setting `<EnableDefaultCompileItems>` to `false`. It's so much easier to debug e.g. compiler deficiencies/bugs when you can just binary chop to find the file that's causing a problem, and the reason you can do this is the linear ordering of explicitly listed files. (In C# I generally just give up and hope that someone else will do it, because it takes so much longer; in F# it's trivial.)
What are you using as your development environment? Personally I don't find the overhead in Vim to be too onerous (`yypf"ci"NewFile.fs`), and even in Rider I routinely edit fsproj files manually. (I even create new projects mostly by hand.)
I got downvoted on the typescript subreddit when I mentioned how Type providers work in F# because "nah, it can't be working that way. The compiler can't be making http requests to make up types for an API" smh.
In fairness it is rather terrifying :P personally I pull all necessary information into some form of version-controlled storage, and then have a test to assert that the remote information is consistent with the stored version. Life's too short to have nondeterministic builds.
yeah that's fair. That's what I landed on too, and would think anyone using it seriously would be doing the same. But the fact that you could extend the compiler to program your own code generation in F# itself is amazing. Comptime in Zig reminds me of this too. I'd have to think OCaml has something similar, but I'm not too familiar with it.
Yep, implementing one (a solid one) is hardcore. But think about it. Building, say, an XML or SQL type provider is a big deal. Doing it right requires special talent, because you are essentially building a transpiler to seamlessly interface with F#.
But this is also it’s greatest strength. Having direct, type-safe access to structured data is truly awesome. What else compares? Certainly not conventional code gen.
Oh, don't get me wrong: Type providers are absolutely fantastic. Just, they are such a complex beast, most implementations I used so far are pretty fragile, at best. But tbh, even a fragile one is surprisingly useful
They've worked for several years now on dotnet, but the type provider author has to do some work to allow their type provider to compile and target that runtime.
> How do Source Generators compare with Type Providers in F#?
> If you’re an F# programmer (or familiar with the language), then you might have heard of Type Providers. Source Generators were inspired in part by Type Providers, but there are several differences that make them distinct. The main difference is that Type Providers are a part of the F# language proper and emit types, properties, and methods in-memory based on an external source. Source Generators are a compiler feature that analyzes C# source code, optionally with other files, emits C# source code to include back into a compilation.
Ah, okay I thought that source generators had more limitations compared to F#. Turns out they can make arbitrary calls, including across a network, which previously I thought was only in the domain of type providers:
> For Schema.NET, we do a HTTP request to get the JSON we need to build
Yes. The mechanisms are very different of course, but both the F# and C# components involved generate types with properties, methods, etc. that can populate IntelliSense.
Can you elaborate? From what I have seen the performance of OCaml isn't up to par with F#. The std. library is small compared to all of dotnet, not to say the surrounding ecosystem and third party packages and tools.
Syntax is of course subjective but to my eyes it's cleaner in F#.
Idk. Don't want to start a war but rather hear specific arguments for why you like OCaml more.
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.