There’s plenty of real world code written in functional languages. Also, this idea that FP is somehow more complex is complete nonsense. Lisp family are some of the easiest languages to learn.
TBH Rust is pretty nice, it borrows (pun intended) a lot of ideas from the functional world (algebraic data types, traits, closures, affine types to an extent, composition over inheritance, and the general vibe of type-driven development), but it’s much easier to write fast, efficient code, integrate with decades of libraries in imperative languages, and the ecosystem somehow feels mature already.
Rust solves a specific problem, and it’s good at letting you write correct programs with low resource usage. It’s definitely a huge improvement on C and C++.
That said, I find a language like Clojure is far more productive because it’s more expressive, and development is done interactively. With Clojure, you start up your program, connect the editor to it, and evaluate code as you go seeing changes live. Once you’ve worked this way, it’s really hard to go back to having to compile your whole program each time you want to see what it’s doing. It’s like having a conversation with the compiler. It makes it very easy to experiment with different ways to solve a problem, and it gives a lot of confidence because you always see exactly what the code is doing. Clojure also interops with JVM and Js runtimes, so those entire ecosystems are available for use.
I agree that they fit different niches! My point was that with modern CPU architectures, imperative languages make it much easier to write fast&efficient code just because the hardware was pretty much engineered with C in mind. IMHO Rust offers the best of both worlds when it comes to systems/low-level dev.
Modern C compilers are a fascinating blend of functional and imperative, that’s true; and I didn’t say that C is “close to how the modern architectures work”. However, mainstream modern architectures are almost always engineered with C in mind primarily, and this is also acknowledged in the article you’ve linked. Rust, having a lot of similarities to C in terms of its underlying memory model, calling conventions, and control flow primitives, can often benefit from those hardware patterns and optimizations in a way that’s more difficult to replicate with a functional language (especially so given most of them are GC-d due to their memory model). The closest I’ve seen in terms of easy-to-write-quick-code is OCaml, but even there the fast paths are often written in a very much imperative style. Idris2 also seems promising if they manage to get a GC-less mode working. Maybe also Roc, but I’ve not taken a look at it yet.
Note that I write all of this as someone spending a lot of their work time programming in a functional language (Haskell), with Rust being mostly for hobby stuff. It just always surprises me how much easier it is to write fast code in Rust, and yet also how much of my Haskell intuition was applicable when I was learning it.
Typically this is true, but it’s certainly possible to get comparable performance with functional style. Carp, which I linked above, basically uses the same approach to memory management as Rust. It doesn’t rely on GC.
I also find that for most cases it really doesn’t matter all that much unless you’re in a specific domain like writing drivers, making a game engine, etc. Computers are plenty fast nowadays, and ergonomics tend to be more important than raw performance.
Sure yeah, I’ve done lots of UI programming with Clojure. It works great. I’ve also made small games. Why do you think it would be more difficult than with imperative style?
functional programming ftw
You can’t spell “functional programming” without “fun”.
Functional Programming Theory: 500 pages of lambda calculus and endofunctors
Functional Programming Practice: Quicksort
There’s plenty of real world code written in functional languages. Also, this idea that FP is somehow more complex is complete nonsense. Lisp family are some of the easiest languages to learn.
Functional programming is perfect for all my projects that I don’t start!
Been working in Clojure for over a decade now, and would never never go back to using imperative/OOP at this point.
TBH Rust is pretty nice, it borrows (pun intended) a lot of ideas from the functional world (algebraic data types, traits, closures, affine types to an extent, composition over inheritance, and the general vibe of type-driven development), but it’s much easier to write fast, efficient code, integrate with decades of libraries in imperative languages, and the ecosystem somehow feels mature already.
Rust solves a specific problem, and it’s good at letting you write correct programs with low resource usage. It’s definitely a huge improvement on C and C++.
That said, I find a language like Clojure is far more productive because it’s more expressive, and development is done interactively. With Clojure, you start up your program, connect the editor to it, and evaluate code as you go seeing changes live. Once you’ve worked this way, it’s really hard to go back to having to compile your whole program each time you want to see what it’s doing. It’s like having a conversation with the compiler. It makes it very easy to experiment with different ways to solve a problem, and it gives a lot of confidence because you always see exactly what the code is doing. Clojure also interops with JVM and Js runtimes, so those entire ecosystems are available for use.
Incidentally, there’s a Lisp style language that embraces a lot of Rust principles. https://github.com/carp-lang/Carp
I agree that they fit different niches! My point was that with modern CPU architectures, imperative languages make it much easier to write fast&efficient code just because the hardware was pretty much engineered with C in mind. IMHO Rust offers the best of both worlds when it comes to systems/low-level dev.
That’s not actually true, modern architecture works much closer to the way functional languages work https://queue.acm.org/detail.cfm?id=3212479
Modern C compilers are a fascinating blend of functional and imperative, that’s true; and I didn’t say that C is “close to how the modern architectures work”. However, mainstream modern architectures are almost always engineered with C in mind primarily, and this is also acknowledged in the article you’ve linked. Rust, having a lot of similarities to C in terms of its underlying memory model, calling conventions, and control flow primitives, can often benefit from those hardware patterns and optimizations in a way that’s more difficult to replicate with a functional language (especially so given most of them are GC-d due to their memory model). The closest I’ve seen in terms of easy-to-write-quick-code is OCaml, but even there the fast paths are often written in a very much imperative style. Idris2 also seems promising if they manage to get a GC-less mode working. Maybe also Roc, but I’ve not taken a look at it yet.
Note that I write all of this as someone spending a lot of their work time programming in a functional language (Haskell), with Rust being mostly for hobby stuff. It just always surprises me how much easier it is to write fast code in Rust, and yet also how much of my Haskell intuition was applicable when I was learning it.
Typically this is true, but it’s certainly possible to get comparable performance with functional style. Carp, which I linked above, basically uses the same approach to memory management as Rust. It doesn’t rely on GC.
I also find that for most cases it really doesn’t matter all that much unless you’re in a specific domain like writing drivers, making a game engine, etc. Computers are plenty fast nowadays, and ergonomics tend to be more important than raw performance.
Would you make a game with functional programming? Or anything with a GUI?
Sure yeah, I’ve done lots of UI programming with Clojure. It works great. I’ve also made small games. Why do you think it would be more difficult than with imperative style?
Lots of things with a GUI, but games are better left for ECS.
Ok. I just read the wiki and it’s interesting. What’s a good resource for learning deeper about ECS?