I've had good experiences running F# on Linux. I used it to build an API generator from database schemas [0]. Similar to Go you can get a single static binary you can copy anywhere.
It's very convenient and you've got a massive number of .NET APIs to fall back on.
The language is a little complex though. That you cannot call interface methods on an object implementing the interface without explicitly casting to the interface [1] is pretty weird. And getters/setters are a little complex.
If you want an easy introduction to the ML family for educational/historic sake I'd always recommend Standard ML. But if you want a highly pragmatic, mature, strictly typed, compiled, cross-platform language F# is pretty compelling.
[0] https://github.com/eatonphil/dbcore
[1] https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...
The language, in general, wants you to be explicit about what you're working with. So implicit access to interface members isn't a thing, you need to say that "x is this interface type" or cast.
In F# 6 things are changing a bit, and may possibly change in the future. There are various classes of cases where the type information is known, but the compiler still required you to explicitly cast things to be happy. That's no longer case. This link[0] has 3 examples that don't compile with F# 5 but will compile with F# 6.
[0] https://sharplab.io/#v2:DYLgZgzgNALiBOBXAdgHwPToAQFMAeAhgLYA...
> implicit access to interface members isn't a thing, you need to say that "x is this interface type" or cast.
If the compiler already knows that it implements interface X Y and Z, it seems unnecessary to require it (unless those interfaces have conflicting names, in which case you would have to be explicit due to ambiguity).
I feel like many languages are walking away from being so explicit, in particular I've noticed C# becoming more implicit over the years.
Implicit upcast? That's amazing, I feel like that's going to help a lot with many branched functions.
Yeah, it's a good feature. It's been done carefully -- there's room to do more of this kind of upcast conversion in the future -- but there's also a danger of creating code that behaves weirdly, too. See here for some of the dangers in Scala 2: https://latkin.org/blog/2017/05/02/when-the-scala-compiler-d...
It's also important to add F# is an inspiration for an amazing MS Research effort, F* [1].
Furthermore, it is also worth checking Dafny [2] (Spec#'s successor). The relationship between Dafny and C# is equivalent to the relationship between F* and F#. Both languages try to refine their predecessors semantics and augment them with practical constructs to prove program correctness.
Some of the largest software artifacts ever verified have been implemented in Dafny [3], and F* is also looking quite promising.
[1] https://www.fstar-lang.org
[2] https://dafny-lang.github.io/dafny/
[3] https://www.cs.columbia.edu/~junfeng/17sp-e6121/papers/ironf...
Why oh why are people still putting special characters in the names of programming language?
# . + are bad enough... but * ?!? It can't even be used in filenames at all.
And while Google might be ok at indexing it... pretty much every other fulltext search engine will be useless. Not to mention it can't be used in package names, domain names, filenames, and a heap of other things.
Even an emoji (while still terrible) would be better under some circumstances.
"Go" was ridiculous enough, ironically from somebody who works at Google. But these people still putting special characters in the names must really not care about findability/disambiguation at all.
PHP might have got a lot wrong... but the name is great... it's just "PHP" everywhere, even the filename extension.
What makes you say that F# is an inspiration for F? I recently went through the F tutorial and saw no mention of that. Obviously F* is an ML, but it seems more like Ocaml than F#.
Might be referring to the fact that quite a bit of f-star is written in F# and that F# is an emit option?
That said, the F# code that you see in the compiler source looks syntactically more like OCAML and makes little use of .NET.
Excellent illustration of 7331's sister-level comment... your two *s have turned into markup
How does Dafny compare to M#, the unreleased language used for project Midori?
> That you cannot call interface methods on an object implementing the interface without explicitly casting to the interface [1] is pretty weird.
That's probably because in C#/.NET you can specify methods that are only valid when being used as this exact interface. Those are called explicit interface implementations and can contain completely different code than the class method.
https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
at least they picked cute bird face emoji for it :>
I am building a tabletop game trainer for Star Wars FFG as the RPG Sessions app is incomplete and trying to do all of the things manually or remember every rule + every modifier to the rule + what all of my NPCs stats are is impossible, and thus when one looks things up, it slows down gameplay a lot, especially during battles. Since the whole point of the system is to make battles feel fast and cinematic, and we want to strictly adhere to the rules as written so we are not constantly re-adjudicating (read: bickering over) house rules, we need something more.
Enter F#. I've been working on (yet not releasing a usable version yet bc I'm bad) this program entirely in F#, using Giraffe as the web layer, following the general architecture defined in Domain Modelling Made Functional, and using Dapper to write to a Sqlite database.
F# is amazing. I'm able to fully understand the codebase and follow exactly what happens from HTML Form request, through input validation, through the business logic, down to the database and back to the domain, then rendering out to a JS-free webpage via Giraffe.
It gets tedious doing the marshalling/unmarshalling from HTML form to input DTO to domain type to output DTO to database records to input DTO etc. and I need to learn both how to create DSLs (so users can type in rules from the book and the system will extract the keywords and compose them into the closest equivalent set of conditions and effects the system supports) and lock down my bounded contexts so I'm developing them in order of least to most entity dependencies rather than in order of where I feel I need them most, but I can't see a way where I would be able to build this in plain old C# without all of my above challenges + lots of boilerplate code to ensure my expected invariants are met and someone (me) hasn't changed an invariant out from under me somewhere else without realizing it.
Yeah, those boundaries between beautiful domain type <-> DTO <-> database is also something my team and I struggle with. In the end we're happy with just writing it out, but there is this nagging feeling that it could be more ergonomic.
I'd be interested to hear about other approaches. You could in theory just dump (automatically generated) JSON to the database and evolve your types with tagged versions, but then you have to write some boilerplatey converters between TypeV1, TypeV2, TypeV3, ...
I guess that's the price for staying away from full-blown ORMs?
It reminds me a bit of how in Elm you just suck it up and write the JSON en-/decoders by hand. Annoying at first, but then you get super obvious and maintainable code out of it, which is quite a joy.
> It reminds me a bit of how in Elm you just suck it up and write the JSON en-/decoders by hand. Annoying at first, but then you get super obvious and maintainable code out of it, which is quite a joy.
The F# take on Elm coders (Thoth.Json) can use reflection to generate them automatically. This is really useful at the prototyping stage.
Yup, I love Thoth. At work we just use System.Text.Json + FSharp.SystemTextJson though, that also generates (de)serializers, and it has a bunch of options to fine-tune naming conventions, sum type encoding, etc. Super useful and easy to hammer out the correct type for very big and nested JSONs.
I kind of like the Elixir Ecto approach where your "DTO"s are mostly plain old data with a single hidden attribute identifying the database table and some other db metadata. They're not live/active, you have to manually pass them to functions to update, but you avoid having two nearly identical types.
The biggest for me is needing to understand the .NET ecosystem without knowing C#. Then there's the lack of beginner information. I own several F# books and none of them assume you're coming from a scripting language background. I eventually gave up for good. OCaml doesn't have the .NET problem, but I found it to be unergonomic in a lot of ways.
Make no mistake, it's a cool language that I'd love to be good at. The code always looks elegant, I'm just terrible at writing it.
There's definitely room for a book or blog series along the lines of "F# for python programmers" or something.
Unfortunately there's some level of .NET tooling you need to understand before you can do much today, and several .NET concepts creep in with that.
The good news is that .NET Interactive is shaping up to be a great way to avoid most of that. At least so far all you need to do is install the .NET SDK, then install a VSCode plugin and you're good to go - just write code like you would in a python notebook, and acquiring packages is even easier than in Python: https://github.com/dotnet/interactive#notebooks-with-net
Linking your demo of VS Code Notebooks cause it was great: https://youtu.be/_QnbV6CAWXc?t=1298
I had the exact same problem. Even all the http servers had a lot of .net boilerplate to get started. A lot of that should be abstracted. I built an http server library that abstracts the .net parts. https://wiz.run/
The hello world server:
open Wiz.Server
open Wiz.Context
open Wiz.Route
let myHandler ctx =
ctx |> sendText "Abra Kadabra Kalamazoo!"
let myRoutes = [
get "/" myHandler
]
genServer()
|> setRoutes myRoutes
|> runthinking more about it, F# needs to appeal to non-dotnet developers and other developers looking for a functional language for real workloads.
F# currently seems easiest for c# dev to get started, but c# devs have almost no incentive to do so.
I could say the same thing about any language. For instance:
"Python needs to appeal to C# developers and other developers...
Python seems easiest for PHP devs to get started, but C# devs..."
And, the truth is, no, Python doesn't need to do that at all. It just has to be the best Python it can be.
I am a C# developer and I find F# very interesting. I love the functional paradigms in C# and I want to be able to use more of a functional style.
I like how well written F# code is less verbose while being very readable.
I want to learn another language. I was thinking about Go, Rust and Kotlin. I excluded Kotlin because it seems it doesn't bring me much value over C# and I excluded Go for the same reason.
I dabbled a bit in Rust, but so far I don't like it's verbosity, the fact that it is boiler plate-ish.
So I reminded myself of F# and started learning that. I know that it has a huge disadvantage compared to the others, it is far less popular, but on the other hand, I can use F# in the same projects I use C# and some of the thing I learn while learning F# might be applicable to C#.
I feel that F# is a niche language mainly because of of two things: Microsoft doesn't care much about it to push it and help it to thrive. And they don't push it because it has a small community. I seems that Microsoft is investing more resources in Python or Java than in F#. The other thing is that the largest community sees it as a Microsoft language and that is enough of a reason not to touch it.
Whatever growing adoption F# has its due to efforts of it's tiny but very enthusiastic community which is helping it to jump some barriers like frontend programming.
This was my issue when trying to learn clojure as well
Yes, my experience as well. Clojure is more "lisp for java programmers" than "java for lisp programmers".
Most of introductory material I found was good in explaining functional concepts, lisp approach to solving problems etc, but I thought assumed a working knowledge of the JVM ecosystem.
For someone utterly unfamiliar to Java/JVM world would find clojure extremely baffling, cryptic error messages, needing to be familiar with the rather large java standard library, etc.
That is the issue with any guest language, because it is impossible to hide the platform, unless the language is so constrainted that is practically useless.
It is a hard to swallow truth, but guest languages really require understanding of the underlying platform.
Another example, no matter one's opinion on C or JavaScript, mastering them is a much more confortable life on UNIX/POSIX platforms and browsers than trying to pretend they aren't there.
Agreed. I think you say it more succinctly.
It can also be frustrating if you know a little OO (but not how Java does everything) and then try to learn a functional language that sits on top of one of these OO tar pits of an ecosystem. I can write Python classes, but seeing the complicated mess of Java is frustrating as that has to be learned as well. Nothing against Java btw (it has its place), but it does seem to require a lot of boilerplate.
Same. F#, Clojure, Scala, & Kotlin have all been the same for me. Python's VM is written in C, but I have no reason to know C. In Clojure they have you call out to Java libraries a ton. Someone always tells me that this isn't true on here, but it was my experience as well. Having to learn so many tools like emacs or CIDRE or Leinegen was also a turn off.
I really love Clojure, but I have a lot of experience on the JVM so I didn't have to climb multiple learning curves simultaneously.
While the clojure ecosystem has a lot of wonderful, bright and helpful people in it, and clojure itself is technically impressive (esp. its collections implementation), the new user experience isn't great.
I'm not an experienced emacs user, so that makes it doubly difficult, as the ironed-out workflows seem to assume that you are (which is fair, as emacs and lisp are like peanut butter and jelly). However, these days it's fair to assume that a new clojure user is probably learning 'clojure', 'lispy ways', 'java/jvm', and 'emacs' simultaneously.
I think that calva/vscode has a lot of potential to drop emacs off that list, which is welcome, as its learning curve alone is legendary. If you look at that list, it should not be surprising that the community is small. There's so much to learn that I it seems too much to even start.
Haskell doesn't call out to anything.
I'm surprised, I found clojure even while I was a pretty much total beginner programmer fairly easy to get into, via clojure for the brave and true at least was very good for getting the basics.
Clojure for the brave and true shows the exact problem.
Chapter 1: install and learn the JVM
Chapter 2: Emacs
Chapter 3, finally start learning Clojure if you made through the first two chapters. Those first two chapters are going to filter out quite a few potential Clojure learners.
Even that involves downloading and installing a fair amount of build tool stuff which may be necessary, but just drove me away.
Kinda agree, but F# works much better for me with my knowledge of .NET than e.g. Clojure with my understanding of Java.
It's a cliche saying, but for me F# just works! (tm)
If you want to dabble in functional, C# is actually a compelling option now. Switch expressions and LINQ can take you a long way.
I strongly believe that functional programming is not a good fit for 100% of software architecture. The best is some sort of hybrid. Generally, the closer you get to the business logic, the more functional you would want to be. The serializers, http servers, etc. are probably not worth the squeeze to force into a functional domain.
I agree that 100% functional is not necessarily the way to go. That said, I am a big fan of F#'s "functional first" ethos, which drives you toward that sweet spot of a functional core inside of an imperative shell.
With C#, when I'm trying to use functional design, I often feel like I'm swimming against the current. The language has functional features, and it will certainly let you use them, but, LINQ aside, the path of least resistance is mostly imperative and object-oriented.
In F#, it's the other way around. It has a full suite of object-oriented features - still, after all these years, quite a bit more complete than C#'s suite of functional features - but the path of least resistance is mostly functional.
I don't want to say that's a universal best way to have things. But it suits my taste, because it makes the easiest way to do things correspond very closely with the way I like to see things done: distinct and well-distinguished layers of functional and object-oriented code, sorted according to where each is of the most utility. C#, by contrast, tends to guide you toward a foamy lather of functional and object-oriented code with no identifiable organizing principle.
This is the same issue I have with Javascript. If you don't have to use something, you just won't, or maybe I'm just lazy.
The creator of LINQ, Erik Meijer, wrote a fun article "The curse of the excluded middle: Mostly functional programming does not work". Yes it's tongue-in-cheek and highly provocative, but many of his points are true. There is a lot more yet to be learned from functional programming than LINQ and switch expressions.
This is such a weird article. All of his examples are insane strawman non-idomatic C# code, and then he complains when they don't do whatever he decides "an average programmer" would expect them to do. Huh? They were all either doing exactly what I expected them to do (silly things), or were so strange and alien that even Visual Studio has no idea what to do with them! I've never seen anything like that Cell<T> example and it doesn't come close to compiling. What a weird, weird thing to do: write code that literally does not compile and then complain about it!?
Is it meant to be tongue and cheek? I personally didnāt get that impression. I assumed he was using the non-religious meaning of āfundamentalistā: strict and literal adherence to a set of principles.
I mean it has a deliberately highly-provocative style. But the points he raises are all completely valid.
> The serializers, http servers, etc. are probably not worth the squeeze to force into a functional domain.
I used to think the same, but having now tried FP-style libraries for serializers (Thoth.Json) and HTTP servers (Suave), I think they are far superior to imperative or OOP alternatives. The ability to design these things in a declarative style makes the code much more robust and easier to read.
+1
FP is better on a 30 year timeframe but on a next-quarter timeframe probably still has not "crossed the chasm" ā you need not just something accessible like ZIO but you need to figure out what it's killer app is, which the FP community currently doesn't have a clue. "HTTP server but more declarative and made with monads" is not something people cannot live without
I think this depends on the relative weights you assign to learning a new language and program correctness.
Sure - C# is the best functional language, while Haskell has already been the best imperative language for a while now [0].
[0] https://stackoverflow.com/questions/6622524/why-is-haskell-s...
> It has a scripting mode where compilation is done on the fly. This makes it look and feel very similar to python but you still get type checking and much better performance.
This is a really wonderful quality in a compiled language. I wish there were more languages with this attribute (but itās a lot to ask for).
That feature was actually inherited from Ocaml. Both have a REPL and type inference powerful enough to insure that you never indicate types in Ocaml and rarely in F#.
The experience is close to having an elegant Python with types, definitely worth becoming more popular.
The only thing F# has in common with Python is that it is a simple language. Other than that they are different paradigms.
Crystal, the compiled-but-super-fast statically typed Ruby dialect.
Pretty much on point. I've been building a .NET, bootstrapped webapp (i.e., no Razor, no "cargo culting" so I can actually understand things from the ground up) piecemeal, every other weekend, in both C# and F#, and, like Java before it, _understanding the ecosystem and libraries_ is critical.
I can read OCaml and dabbled in it, but that doesn't help me write substantially better .NET because I will be iterating over lists or graphs in a different way, handling IO (and sockets) differently, etc.
But I can see how someone conversant with C# and the .NET ecosystem would really like F# since the barrier to entry is substantially lowered, and the code is just so much nicer and tidier.
Shame there isn't a proper AOT-compiled LISP for .NET (no, Clojure doesn't count, I never managed to get the .NET version to work for me).
F# has become my default goto language. It is absolutely amazing to create cloud services in it an I have a small ETL tool as well. I would not trade it for anything else.
In my area there was a huge push for functional programming and F# some years ago. A long time ago since I heard anybody working with F#. Clojure is somewhat popular though in fintech.
Functional programming is something I think one should learn cause the concepts are useful in other programming languages too. Over time what is useful in functional programming languages will be available in other languages. In fact, a lot already is. Functional programming is not an USP in my world.
When I started with C#, code bases were full of GoF patterns, if and switch statements were banned, there were hierarchies of inheritance, there were states spread out and encapsulated everywhere, static functions were banned. Today, code bases are mostly stateless except for things that needs to be reused, there are pure functions everywhere, inheritance is mostly used in libraries and where interfaces canāt be used (yet), switch is ok and pattern matching is around the corner in several languages.
More unpopular opinions. Immutability is overrated. In some programming styles, in some old languages there was a high risk of changing something by accident. Typical cause people did not know if they were working on a reference or a copy. Also, it was common to change fields on purpose. This problem does not really exist in a lot of programming languages today. But I do wonder if Go coders code benefit from some more immutability.
I think the future of F# looks very dark but the functional style of programming will for sure have its place. What could change this is if F# really excels in some area like Go have done.
After null, the worst calamities that hit the software world are Uncle Bob's principles and GoF patterns.
I mean what is more exciting than having to deal with FactoryFactoryFactory and AbsteactFactoryVisitorBuilderProxy written by others?
Having forced OOP is bad enough by itself but people found ways to make software development even worse.
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.