I decided to tackle this year's Advent of Code in F#. It's not only my first time using this language, it's my first time ever using .NET. I don'...
For further actions, you may consider blocking this person and/or reporting abuse
Great post. :)
I assume you are using VS Code with Ionide plugin? If you open a folder with an F# project (
.fsproj
) file, it will add an icon to the left that looks like this.When you click that, it shows the F# Project Explorer window. You can right-click on the project and Add File. That should create the file and also add it to the
.fsproj
automatically. The Project Explorer is still a little rough around the edges. But helpful for basic usage.On Windows, I've been using Visual Studio 2017. It has a robust Solution Explorer that feels like normally managing files in an editor, but it automatically takes care of the
.fsproj
stuff. So no need to add them through CLI. However, VS does not have a built-in terminal window, so I use the MS-sponsored Whack Whack Terminal plugin for that. (to run npm/etc. commands from within VS for Fable projects.)Thanks so much for the advice!
I was using Ionide but had a rough go from the start and immediately fell back to the
dotnet
command. I'll give it another go, but I've also been meaning to start learning a bit about VS, too - might be a solid excuse. That plugin will definitely help it feel a little more comfortable. I've had an Elm project in the back of my head for a while - no reason it couldn't be Elmish!MVU style is amazing. Go for it either way! Elm is better for learning to write pure functions TBH. Fable-Elmish is structurally and syntactically very similar while being far less restrictive. For the latter, I do recommend keeping side effects out of init/update if you want to keep the refactor/test benefits from having pure functions. (Cuz F# does not stop you from putting side effects in those functions.)
Interesting - I do love compiler-enforced discipline, but it's always nice to have an escape hatch - and F# seems like a more broadly applicable language if I'm going to invest some time in one or the other. I'll have to think about it.
Yeah, I vote for F#. But wanted to give a props to Elm for teaching me the value of pure functions. I came from C# to F# and still fell back to a lot of mutation-based/imperative solutions for a while. Elm forced me do pure functions (along with MVU, which structures most of the code to be written in pure functions) and experience their benefits. But if you understand that pure (aka referentially transparent, aka deterministic) functions produce output based only on their inputs. And if you understand the value of using them. Then it is pretty easy to understand whether you have written a pure function or not in F#, even without a compiler warning. Plus F# is great for back-end work too. (Kestrel on .NET Core is known to be a pretty fast web server.)
Awesome. I think Haskell drilled the concept in pretty well but I still always sort of miss the rigidity whenever it's gone. I'm heavily leaning F# now too - I'll have to look in to Kestrel!
Kestrel is the built-in .NET Core web server. It isn't functional or anything, but it is very fast -- look for aspcore. Giraffe is a F#/functional lib on top of Kestrel. I also wrote my own for API routing only.
Cool! Definitely looking forward to digging deeper in to this, thank you.
Following up ...Visual Studio proper was so the way to go
If you want a better performance, easier JS interop (than Fable) you have to use OCaml. F# was "OCaml for .NET" before, and it's still interoptable with OCaml. They classified OCaml, for example
;;
is optional;
is can be replaced with\n
(Newline), foreach loop addedfor ... in ...
so on. You can still use the OCaml syntax, using verbose syntax (It's still part of F# Grammar and Parser, it's not a new language). In my opinion, learning OCaml before learning F# will be more useful for you.I did learn OCaml before I learned F# - and strongly prefer the latter. Thanks for the tip, though!
I agree, JS interop via BuckleScript is really nice, but everything else was harder to use than the equivalent in F#
Ah, I just remembered it now. There is OCaml preprocessor or macro language named camlp. That makes you easier to code OCaml, makes you have more features like F# have. For example for each loop
Nice post! Every language really should have Pipes. They are super! I have only used them in Elixir, but man I loved it.
Lovely post and very inspiring. Arrrgh I don't need another language that I now want to try.
Neither do I, Mark. Neither do I :(
A bit of experience using ClojureCLR several years ago. I had mostly .Net experience at the time and wanted to explore so tried it out. I created some WinForms and Console apps, successfully passing stuff to and from C# code. I can't say there were any glaring problems with it, but eventually it was obvious that .Net was a 2nd class platform. Just, tooling wasn't there, so I just moved to the Java ecosystem instead. F# is a lot tighter with .Net of course. (Though I'm surprised nobody ever did a JVM port!) I ended up settling on F# as my go-to: after just not being able to refactor in Clojure due to lack of type safety, I did some complete rewrites of fairly large Compojure apps to Suave, and never looked back.
That makes a lot of sense - I have a feeling spending more time with F# is the answer for me as well
Re: compiler errors - meaning the quality of the errors?
On another note, I see you're in Boston. Do you have any interest in helping to revive the Boston F# Meetup?
Hey! Gosh, I'm so sorry I missed this.
Not necessarily the errors themselves, but the error messages. Those two compilers are extremely helpful, and will often nudge you in the right direction, which as a total beginner is extremely useful. The F# compiler is a little more matter of fact about what's wrong, like most compilers. I think as I get more comfortable I won't find it as opaque, and it's not a huge drag on the experience.
I absolutely am interested - send me a message!
Good stuff.
It was (I believe) the first .net language to get async support. We kind of take async/await for granted now but F# was a game changer for me.
The units of measure stuff is also really awesome! I don't think I've seen anything else quite like it baked-in, only in libraries.
I'm looking into Rust but f# looks awesome to learn.
Those are my two favorites, I think! Very different, both worthwhile.
Really happy to hear how easy it was to jump in. I think with .net core F# should be much more approachable than in the past!