Why Roc could be the First Mainstream Purely Functional Programming Language

Roc[1] is a work-in-progress programming language that aims to be "fast, friendly, and functional". Its been speadheaded by Richard Feldman[2], an evangalist for Elm[3] and functional programming in general. It is very clear that all of the people working on it have reflected deeply on what has worked well across a variety of different programming languages, both new and old, and as a result are building something that I think is truely groundbreaking. There are some new ideas (that I hope will be more widely adoped) and some not-so-new ones where their contribution is simply to bring all of the great ideas floating about into one package.

Functional Programming is already mainstream

First and foremost, the biggest reason why I think Roc has the potential to go mainstream is because functional programming itself moves ever closer every year to going mainstream. In the 20th century functional programming, and especially pure functional programming, was considered a niche academic area of study, unsuitable for industrial applications due to performance and poor ergonomics. However, this has become less of a concern as performance has become less of a priority (yay for Moore's law) and the ever growing complexity of software has required that our tools provide us with a sound layer of abstraction. There are a number of programming languages that have caught some traction in recent years, like Elm and Clojure, but most notable is the sheer amount of concepts that have been "borrowed" from functional languages. Basically every single one of the most used programming languages has or is adopting many of the patterns first developed in the functional programming space like higher-order and annonymous functions, ad-hoc polymorphism[4] (typeclasses/traits/abilities, whatever you want to call them), and monadic-based effects like promises and futures. Another pattern that is becoming increasingly popular, and which I believe will become as common as those others in the next five years, is disjoint unions/tagged unions/sum types (again, whatever you want to call them). All of this is to say that it is not as crazy as it once was to suggest that a mainstream programming language could be a purely functional one.

Static but Structural Typing

The tide is also most definitely turning back to static typing. Many popular dynamically typed programming languages like JavaScript[5], Python[6], and Ruby[7] are adopting static type systems. Most of the new languages to become popular come with static typing from day one, like Rust, Swift, and Kotlin. The many compelling reasons for doing so are perhaps a separate discussion but there's no doubt that the needle is swinging back towards static typing. The key difference about static typing today from static typing of the Java and C++ days is that we (rightfully) want type systems that are more flexible and don't get in the way of us expressing ourselves how we want to. Many of these newer type systems use, to varying degrees, structural typing[8] over nominal typing[9]. As long as the data looks a certain shape then the function can work with it, it doesn't have to be modelled by a particular class in order to just work with it. Structural typing is not new in the pure functional programming space: PureScript has row polymorphism[10] which can be thought of as a formalisation of structural typing over associative arrays. However, Roc takes it to the next level by allowing disjoint union types to be described structurally too[11]. Functions can take some set of tagged types and return the same or a different set of tags, all without having to define explicit types for each possible grouping.

Another aspect of type systems that is desirable is for it to not stop us from running some code that we know works even when the rest of the codebase still has type errors. The gradual type systems being built atop the most popular dynamically typed languages naturally allow you to run code that doesn't type check as having them pass need not be a blocking part of building the code; you just need a program that can strip out the types to be able to run the code in an experimental way. Roc has similar functionality: it will compile the code even if there are type errors, crashing if as part of the execution it reaches code that it cannot verify.[12] A lovely feature in making the use of a static type system that bit more ergonomic and one that I think we will be key in winning over the people that love dynamic typing.

Approachability

One of the biggest influences on Roc is Elm, in particular Elm's approachability to people who have not done functional programming before and who don't necessarily have a strong academic background. What to include in the language and what to exclude is carefully considered; weighing up whether the additional expressiveness is worth the added complexity to more novice developers. Moreover, the error message are the absolute gold standard; helpful rather than annoyances. The Elm compiler is your friend, not your examiner. The Roc team aim to replicate this although they are not there yet. As an industry, I think adopting this mentality towards the design of tooling in general would be a huge step forward.

Multi-platform

The most unusual part of the Roc project compared with other pure functional programming languages is that it aims to be multi-platform. The world's most popular programming languages -- your Javas, your JavaScripts, etc. -- are so popular because a variety of different software can be written in them. They've become the lingua-franca of the industry as developers from all over the industry end up learning them to be able to communicate with others and quickly build systems of all shapes and sizes; from websites, to apps, to enterprise monoliths. The fact that Roc aims to compete against them all, prioritising performance and interopability in its design, suggests that it at least has a shot at being as popular. It is not yet clear what Roc's killer app will be; what it's Rails, it's Numpy, it's jQuery will be, the thing that makes it the best tool in a given domain, but at this stage is could reasonably be any (or even all) of them.

Conclusion

Overall, I'm just really excited to see a language put all of the disparate pieces together that are being experimented on in various different communities. In addition, Roc is spending its innovation tokens[13] on polishing many of those ideas, creating something that I'm convinced will push functional programming further than it has gone yet.

~~~

Last Updated: 2023-10-15