Hacker News Reader

Comment by wrwills | Hacker News Reader

I suspect the use of Rust rather than C++ might have something to do with the fact that Simon Peyton Jones and Lennart Augustsson (both of Haskell fame) both work at Epic and there would have been a strong internal push to do this in a language with some functional programming features. Rust rather than Verse because that would probably not be the right tool for the job (even if Simon works on it). Rust rather than Haskell probably because of performance -- DARCS never caught on partly for performance reasons.

View on HN

I don't see how Rust is more functional programming oriented than C++

C++'s stdlib collection algorithms were basically all mutate-in-place instead of return-a-new-value until C++20 introduced ranges, and I still don't know anyone who actually uses those. By contrast, people actually use the `container.iter().map(...)` etc. in Rust.

C++ also lacks much of the fancy pattern matching features which are frequently associated with functional programming. Such features may not be fundamental to functional programming, but they would fall under "some functional programming features", in the sense that they're common in the languages of that ecosystem.

Rust has a load of FP-style iter/map/filter stuff that you can technically do in C++ but only if you don't mind bleeding eyes.

It also borrows a lot of features from FP languages like nice tagged unions (enums), Result, everything-is-an-expression, etc.

Guess I never used map+collect in Rust. It's an extra copy. Maybe iter on its own cause that's how you go through non-array collections, same in C++ except C++ is just crappy no matter how you use it.

I think the things that make Rust safer than C++ make it look more like a functional programming language than C++. The main point is that there are some influential people at Epic (SPJ has often spoken favourably about Rust) who would favour it over C++.

Pure by default, type classes (traits), no inheritance, type level lifetime computation. It's not only more functional it's much more type-safe and closer to Haskell in spirit

I like most of those decisions, but they aren't functional programming

Reply on news.ycombinator.com