'Outperforming Imperative with Pure Functional Languages' by Richard Feldman

Like many, I once thought that functional programming makes programs easier to maintain, but slower to run. After all, that had been my experience; when I wrote JavaScript in a functional style, my code got easier to maintain - but it no longer ran as fast.

Once I got deeper into functional languages, including pure functional ones, I was surprised to discover that they could actually outperform imperative languages - not just in tasks generally considered "well-suited" to functional programming, but sometimes even in cases considered well-suited for imperative programming!

This talk examines performance from the network level all the way down to individual CPU instructions to show how and when pure functional programming languages can outperform their imperative counterparts. Come see just how fast functional programming can be!

Richard Feldman
NoRedInk
@rtfeldman

Richard Feldman is a software engineer at NoRedInk and a well-known member of the Elm community.

Recorded at Strange Loop 2021

[gljames]

I just realized that Roc's logo is a bird made from the tangram from Elm's logo. That's really cool.

[ecosta]

When he started with "I created a new language", I was expecting a boring egocentric talk about a language created because someone hates a specific problem of a specific language. For my surprise, his thoughts on how different languages work was outstanding! ROC looks promising.

[gdargdar]

This guy is a legend! I have always wanted to make a functional language with all those optimizations to beat imperative ones and he is doing just that!

[tryptamigo]

rfeldman is one of the most thoughtful people i've seen in the software talk/blog space that i've come across. he does a lot of rhickey-style hammock time, you can tell. can't wait to see where this project goes.

[alexreinking]

6:24 -- hey, that's my paper! :D

[ycombine]

I always enjoy Richards talks. Very smart and a very good communicator. A rare combination.

[overlisted]

this is insane! i can't wait to try out this language

[codewithkv]

Appreciate this talk so much. I am ready to Roc.

[Raspredval]

Just 4 words:
Give
Us
The
Compiler
Seriously, as a c++ fanboy, I very much like this endeavor. I hope, you will succeed in competing with heavy-duty langs

[GonziHere]

That was an impressive talk. Will watch out for more about the roc-lang

[redskater]

This is going to change the perspective of functional programming languages. I’m so excited for the future of FP

[ysink]

Roc beating Go at quick sort has sold me on this language. Like what???

[computationaltrinitarianism]

Another language that implements this FBIP (functional but in place) technique is Lean. It is mostly a research language with a very advanced type system for doing mathematics in.

[AngusHollands]

Small note — CPython technically executes bytecode on the CPython VM. Sure, the compilation step happens at execution time, but it's not executing the AST.

[Dogo.R]

You can get benefits of LLVM compilation AND utilize all the runtime hotspot information that languages that arent a static binary can.
This exists in Java and the JVM languages like clojure and kotlin under the VM "Azule plateform prime".

This utilizes all the information you get from seeing how the program is being used in production. And is able to combine that information with the ability to convert hot live code into optimized llvm compiled code.

You mention garbage collection pauses.
That same VM doesnt have pauses when garbage collecting.

[Dogo.R]

I think making an interface between Elm and graalVM would probly be an easier way to get a binary compilation method.

Rather than remaking the whole language with a different compile target.

[Dogo.R]

Languages like clojure have tools that allow for near full mutability performance, without the risks and problems that come with mutability.

[bram]

It should be noted that Haskell does have safe mutable arrays with Control.Monad.ST.

[fraser]

I might be a bit biased, but the situation he's describing at 23:30 really sounds like the exact place a rust-style borrow-checker could fix things. If you're already running all this static compile time reference counting stuff, why not communicate that back to the user in the language design itself by enforcing they choose between array2 = array.clone().map(... or array2 = array.into_map(... (with whatever syntax makes more sense given context).

[monad_tcp]

I didn't knew about this. I loved it, specially because I am a F# programmer, and Elm is so close that I can write a source-to-source compiler.