When I’ve gone to CppCon in the past it was as someone who’d been using C++ for over a decade. The past week when I attended Open F# it was as someone who had only been using the F# language for a couple of months. That’s quite a different lens to be viewing the proceedings through. Outwardly the two conferences seem quite different: CppCon has 2000 attendees and five tracks of talks spread over five days while Open F# had less than 100 attendees and two tracks spread over two days plus a day of workshops. But inwardly, they’re both full of people who are passionate about the language and tools that they use.
Before I go much further I should probably address the question that might have popped into your mind when you saw the title of this post if you are a long time reader: “WTF? F#? I used to come here for C++ tips and tricks and an occasional Haskell post that I would skip. You don’t write anything for two years and now you come back with F#?”. I’ve been programming mostly in C++ these past few years, I just didn’t have much to say about it anymore. On my own time I’ve been doing some stuff that didn’t really generate any blog posts either. So, no blog posts for quite a while.
Recently the idea has come up at work to find a replacement for C++. Not just as in some engineers sitting around complaining that something needs to be done, but as in management buy-in that we need to make a move. Not to bag on C++, but the only real reason we use it at work as much as we do is that we’re caught in a vicious cycle of all our code is already in C++ so we write more C++, all our code code is in C++ so we write more C++, …. There are a few cases where C++ makes sense due to performance requirements or needing to be close to the metal to talk to the sensors in our instruments, but for the rest of our code we’re paying a high productivity tax to use C++ everywhere.
As evidenced by my Haskell posts I’m interested in functional programming. Turns out that my boss has also caught the FP bug (apparently if you put enough propaganda out there about the advantages of FP then eventually you’ll get the attention of someone in management). When he expressed an interest in FP my first thought was Haskell of course, but he wasn’t comfortable with that. There is still a lot of lingering fear out there that FP in and of itself is hard to learn, so he was leery of taking one of the strictest FP languages around and then having to have people get their heads wrapped around lazy evaluation as well. So he suggested F#, which I had looked at years ago when it first came on the scene but hadn’t really paid much attention to in the interim. He was more comfortable with it since it had Microsoft behind it with the whole .Net ecosystem available (and that C# could be an escape hatch if things go sideways). So I’ve spent the last few months getting a new project going with F#.
So that’s a very long winded reason for why I found myself at Open F# this past week instead of CppCon (funny that they were the same week). In the past few months I’ve formed a very positive opinion of F# and the conference has only reinforced it. One of the other senior engineers from work who has much less experience with F# and FP went with me and came away with a very positive feeling about the language as well. Hopefully we didn’t annoy the folks at the conference too much with our questions. We didn’t mean to come across like we were giving people the fifth degree, but we were on a fact finding mission.
Anyways, now that you know why I was there, I’ll get to what I thought the highlights were. Note that all of this is being filtered through the two objectives I had at the conference: figuring out if F# is the right language for my company and if I’m making use of the language properly (e.g. writing idiomatic code that avoids any pitfalls). The answer to both questions turned out to be yes (though Don Syme’s advice not to use fold runs counter to my own preference, a feeling that I didn’t seem to be alone in based on some discussions I had after his talk).
On Wednesday I attended Alfonso Garcia-Caro’s workshop on writing a progressive web app with Fable and Tomas Petricek’s on reactive and async abstractions. I chose the first workshop because I wanted to see Fable in action, even though I’m more concerned with using F# on the back-end at the moment. Being very impressed with Fable ended up being a recurring theme for the conference (so much so that now we’re talking about maybe switching our front-end development away from Typescript and React and towards Fable and Elmish). I’ve been playing quite a bit with async and observables in the past few months and Tomas’s workshop in the afternoon helped bring that knowledge into focus. We didn’t get to async sequences which was too bad because of the three technologies that’s the one that I have the least experience with and was looking forward to experimenting with. Guess I’ll have to figure those out on my own. The introduction to F# workshop did a good job of getting my colleague up to speed on the fundamentals of the language so that he wasn’t lost during the talks on the following two days and left him confidant about being able to get work done in F#.
Evelina Gabasova’s talk on using F# for machine learning was interesting both because machine learning is something I’ve been playing with lately and that it was a success story. Success stories were something I was looking for, and I found quite a few; even applying a grain of salt due to the self-selecting nature of a conference (there probably aren’t many companies that send people to conferences for a language that they’ve failed with). I wasn’t looking to get a comparison of numbers of successes to numbers of failures, just that there had been successes in diverse areas, and that’s what I found.
I chose to attend a couple of talks on more advanced subjects: Mark Laws’ talk on SRTP (if you have to ask what that mean then you probably don’t want to use it) and Jeremie Chaissing’s talk on applicatives. I had a hard time with Mark’s talk and the main take-away for me is that I shouldn’t use SRTPs until I’ve had a lot more time to study them, and even then I should probably think twice. The applicative’s talk was much more approachable, maybe because I’ve used applicatives before in Haskell. They aren’t something that you need all the time, but it’s good to know that they’re there if you need them.
Don Syme’s keynote about code he loves was very useful as far as learning idiomatic use of the language goes. Besides our disagreement on the use of fold (though I do agree that one should use something more specific as much as possible), I’d say that his reasoning on how to use the language made a lot of sense. I especially enjoyed how he spelled out the design goals of the language and then tied his opinions on language usage back to those goals. After his talk I had a decent idea that I was using the language in an mostly idiomatic way. If anything I’ve erred on the too functional side, which I don’t view as being too bad of a thing.
Since Darren Platt’s talk about using F# in a biotech company was of the here’s our experience with the language variety I found it very interesting. There was a good mix of what they found good about the language and what their experience was using it (unsurprisingly the experience was good). Similarly, William Blum’s talk about using F# to build a service at Microsoft was interesting for the same reasons. His talk also got into the recruiting question as well (i.e. how do we find F# programmers). The upshot was that they had had no problems scaling their team from three people to 15, though they didn’t specifically look for people that already had F# experience, just those that were smart and open to learning new things (something I already look at more than experience with specific technologies when interviewing).
Philip Carter’s talk about F# growth was encouraging as well. Beyond his cautiously optimistic take on various growth metrics as applied to F# he showed that Microsoft is behind F#. Maybe not to the extent that they’re behind C#, but they’re treating F# as much more than a red-headed step-child. A lot of the discussions I had around the conference reinforced this, especially when it comes to .Net core. Really, the main complaints I heard about F# were that people were running into some hurdles converting their code bases to .Net core from the .Net framework. It also seems like tooling (in general, not just the MS stuff) has improved immensely in the last few years. So it seems like our switch to F#, if it happens, is coming at just the right time.
There were lots of other great talks, and great discussions in between. The biggest surprise was Fable. Neither of us went in thinking about changing our front-end technologies, but Fable (and Elmish and all the other stuff that goes along with it) looks so compelling it’s hard not to be thinking about it now. In general the conference gave us lots of grist for the mill of driving adoption. Now the hard part of taking what we learned and trying to drive buy-in from the other engineers begins.