Episode 157: The Roc Programming Language with Richard Feldman #49
Replies: 2 comments
-
so "functional programming" is not so obvious:
they aren't all necessarily FP features |
Beta Was this translation helpful? Give feedback.
-
The thing about "functional languages" is I think that people simple value different parts of that paradigm differently. Avoiding mutation and side effects aren't that high on a list for me for any language that has some kind of global state. For me, the most valuable part is the compositional one. In languages like Scheme, you tend to build from the ground up. You build a higher-level system based on smaller components that compose cleanly. I think Rust feels "functional" to me because of those compositional qualities. Rust needs strict encapsulation, state and mutation control, and value linearity just to uphold it's memory safety baseline, so it's foundational to the language. The functional part comes in when we compose those individual parts together. For example, once you have a mutably exclusive reference, you know where side effects are bound to happen. My brain doesn't really have to switch between the high level differences of passing two mutable references, or passing two values and getting a tuple back. If we look at the Rust language, it's got a complex type system, APIs need to care about ownership, aliasing, thread safety. They have all these axis of decisions, but Rust still has a prolific, growing, healthy ecosystem that moves rather quick for the low level Rust operates on. I would argue this is because of the functional system composition aspect. Rust-the-language needs those as said above, so everyone upholds these. And because the language lends itself to small components that compose it all ends up having a Lispy-system feel to me. Really, the big difference to me as to what feels functional and what doesn't is the general language reliance on things like inherently having widely shared mutable state. If every object you have access to is a handle to shared mutable state that everyone can keep as long as they want, you have to take all this into account. Rust gets extra functional points for making you spell that out in my book. I go on Github and see an As a result, in imperative languages I usually start out modelling the state of the system. In more functional languages like Scheme (or, to me, Rust), I build from the ground up and compose. (Sidenote: I also think overengineered APIs are often a result of unclear compositional goals). And all those "functional APIs" for iteration, and error handling or so on aren't really something to make things more functional API wise. It's because those work really well for cleanly linking individual components. Rayon (a parallelism library) is great not just because of what it does, but because of how much Rust code is by default ready to be parallelized by it, because they compose easily due to it just plugging into iteration. So in summary: Maybe Rust is not really functional to everyone, but to me it had to steal enough from the functional paradigm to make this old Schemer smile :) And as a result I design my software like I would with a functional language, and less an imperative one. PS: I just woke up and am still on my first coffee, so I apologize if this is less than coherent. I do find this is an often overlooked part of software design. |
Beta Was this translation helpful? Give feedback.
-
Episode Link: https://adspthepodcast.com/2023/11/24/Episode-157.html
Feel free to write comments or ask questions 🙂
Beta Was this translation helpful? Give feedback.
All reactions