Skip to content
0:00 / 0:00

#roc#elm#in-placemutation

"Outperforming Imperative with Pure Functional Languages" by Richard Feldman

Strange Loop Conference

88K subscribers • 114 videos on Hallway • Conference channel

YouTube
  • Recommended by 10 people: 6 on Hacker News, 1 on Lobsters and 3 in engineering communities.
  • A classic. People kept recommending it from 2021 to 2025.
  • Presented by Richard Feldman, creator of Roc
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

98K views5 years ago10 recommendations

Programming languagesSystems programmingFunctional programmingPerformance and optimizationCompilers and interpreters

Richard Feldman explains how pure functional languages like Roc use compiler optimizations like opportunistic in-place mutation to match or exceed imperative performance.

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 thestrangeloop.com

Why it's here

10 people recommend this

What people say. Highly recommended for explaining how compilers can optimize immutable functional code into high-performance in-place mutations.

Moments people linked to

u/hkailahiin r/haskell • Recommends

"Outperforming Imperative with Pure Functional Languages" - Richard Feldman @ Strange Loop 2021

u/hou32houin r/ProgrammingLanguages • Recommends

"Outperforming Imperative with Pure Functional Languages" by Richard Feldman

u/fredoverflowin r/ProgrammingLanguages • Recommends

"Outperforming Imperative with Pure Functional Languages" by Richard Feldman (Elm, Roc)

agent281on Lobsters • Recommends

Outperforming Imperative with Pure Functional Languages

agent281on Lobsters • Recommends

Outperforming Imperative with Pure Functional Languages (2021; Roc) Since the Roc repo is now public and people are unclear why they should care I thought it might be worth posting this again even though it's been less than a year. Hope that's okay with everyone.

memcoon Hacker News • Recommends

On “4x Smaller, 50x Faster”

> How would one optimize for immutability in this case, other than turning it back into mutability behind the scenes? Roc-lang, which is a functional, systems language in development uses something called opportunistic in-place mutation to do just that. Here's a video where the creator talks about it: link to this video

niels_bomon Hacker News • Recommends

On “4x Smaller, 50x Faster”

This talk by Richard Feldman about Roc (a new language) goed into why immutable does not necessarily mean slow and given enough attention can mean higher performance in certain cases: link to this video

aquadropon Hacker News • Recommends

On “Haskell2020 Is Dead, but All Hope Is Not Lost (2019)”

Maybe link ? It's not production ready, I just saw nice talk by Richard Feldman 1 about it and it's inspired by Elm. 1 link to this video

Akronymuson Hacker News • Recommends

On “Ask HN: Functional vs. Imperative Implementation of Algorithms”

> Functional programming experts say that their code is efficient because the compiler translates it to an efficient representation on the CPU. They have TCO and other things. But they don't mutate data and hence every function call creates a new data in memory taking up space. How do they overcome that? By letting the compiler make assumptions. For example, consecutive map calls can be converted into a single one. If the data isn't shared with something else, the compiler can mutate it. MUCH easier to paralellize maps. As a starting point for those nitty grittys, this talk is probably as good as any link to this video

yashrkon Hacker News • Recommends

On “Roc – A fast, friendly, functional language”

If you are interested, «why yet another programming language?». The unique selling point of Roc is clever optimization to convert purely functional source code to deep-imperative fast machine code, while keeping all the correctness of functional algorithms. See this video of Richard Feldman for details — «Outperforming Imperative with Pure Functional Languages»: link to this video Among those clever optimizations: - static reference counting (no GC, like in Rust, but with no borrowing and borrow problems); - stack allocation of the data with no external links; - hidden («opportunistic») mutability even in the cases, where Haskell or Lisp will copy the value.

greener_grasson Hacker News • Recommends

On “Serialization Is the Secret”

1. Structural sharing - most data doesn't change so you create a copy that reuses much of the original structure 2. Garbage collection and lexical scopes - you clean up memory quickly and in batch 3. Compiler optimizations - you turn functional constructs into imperative ones that reuse and mutate memory at compile-time, where it is provably safe to do so Roc Lang might interest you: link to this video

greener_grasson Hacker News • Recommends

On “Roc rewrites the compiler in Zig”

We already have many great GC'd functional languages at that performance level. I first learned about Roc from this talk: link to this video That's a niche that is not currently filled (well, maybe MLTon) and that has me very excited! I'm sure I'm not alone here.

u/Arcsechin r/ProgrammingLanguages • Mentions

On “Why are imperative programs considered faster than their functional counterparts?”

Largely it comes down to “having immutable objects means making a copy every time you want to change something, and copying is kinda expensive”. You can ameliorate this cost by using things like copy-on-write data structures, which avoid copying unless it’s really necessary, or data structures which can share parts of the structure (like Clojure’s trie-based maps). There’s also research into allowing compilers to recognize when code can logically be transformed into mutating code (instead of copying code) by doing a form of escape analysis (see this video for details), but I’m not aware of any production-ready compilers that actually implement that kind of technique.

u/witoldszin r/functionalprogramming • Mentions

On “Is it possible to make a functional programming language that is equivalent of Rust in terms of performance and resource efficiency?”

Richard Feldman is trying to achieve this with Roc, see: Outperforming Imperative with Pure Functional Languages link to this video

u/hammerheadquarkin r/ProgrammingLanguages • Mentions

On “Ante – a low-level functional language”

Not about Ante, but the author of Roc has a good talk about how they did it: link to this video More info here: https://www.roc-lang.org/

u/msqrtin r/ProgrammingLanguages • Mentions

On “Fixing the Next 10,000 Aliasing Bugs”

This comes to mind. His stuff is basically just that: do in-place mutations when you know nobody else is observing the data. Not sure how well it extends to real use cases, but his quicksort performance does seem impressive. Then there is Val which allows for any mutations but no aliasing. At any point in time, any value can only be accessed with one name. Their argument is that independence is key, and while immutability offers independence, it's more strict than is necessary. I kinda buy this, but how to nicely model actual resources like files or sockets in a system like this is a bit of a mystery to me.