Nice overview - you could have mentioned how heavily FP (functional programming) influenced Rust is, that's one of the first things I noticed when studying it.
Rust, in my opinion, is one of the most elegant programming languages - personally I think it's better designed than Go (what I really dislike about Go is the total absence of abstract types or generics, which makes functional style programming virtually impossible, forcing the programmer to do everything procedurally).
Even though it's not a pure FP (Functional Programming) language, it reminded me a LOT of Haskell. Amazing how well Rust's type checking works to ensure safe and "correct" programming.
By the way, what I also noticed is how fantastic Rust's official documentation (the Rust Programming Language tutorial) is - that's really a rare example of official docs that you can read from cover to cover and that makes 3rd party tutorials redundant.
Nice, I came across Nim sometime ago ... how would you say it compares to Rust? It sort of looks like a cross between Rust, Go and Python - it uses indentation instead of semicolons, it does have a runtime and garbage collector, and so on. Something like combining "best of" features from Go and Rust with Python syntax thrown in :-)
I'm not sure that there's too much of FP in Rust. With all nice abstractions and lambdas, Rust discourages programmers from using by-value arguments, since in move semantic it can only happen once and when borrowing (especially mutably) we're dealing with references and mutate state in place which is be definition procedural.
Not sure if I understand your argument - when you say "when borrowing (especially mutably)" then you already assume that you're using mutable variables, implying that you're using a procedural rather than an FP approach ... that's an option, but not the only way to do things.
When going through Rust's official docs (the programming language tutorial) they seem to emphasize abstract data types and interfaces before they do "OO" constructs - and variables being immutable by default promotes an FP approach as well. Could be me, but many concepts in Rust reminded me a LOT of Haskell.
Of course Rust is not a pure FP language, so you can program procedurally if you want, but then in my opinion you're not using Rust's full power.
Let's figure out what is functional first. You mentioned Haskell, and even though it's been many years since I played with it, but if I'm not mistaken it doesn't allow mutation of a function arguments. So functions are pure: they take values and return a fresh value. Even though you can formally do the same with Rust, it won't work in practice, here's the example.
Suppose you have a Vector and a function length(list: Vector<T>) -> i32 that returns length. If you call it on a vector, it'll be moved. And none of the subsequent calls on a variable holding that vector will work. Instead Rust encourages using borrowing: length(list: &Vector<T>) -> i32 and passing refs in this case. And in this case it's perfectly fine to call functions (procedures?) with refs multiple times.
Now why I call these procedures: do_something(&mut self) would not return anything, and rather mutate the state of the struct it's attached to. So technically it's not a function, but a procedure that mimicks methods from OOP.
And I guess it's perfectly fine, especially given that it's dictated by the reasons of performance and explicit resources control, but for someone with functional mindset (such as myself) it might be quite painful to adjust.
I won't argue with you on this particular example, but maybe the result (whether or not you run into these limitations) depends on how you approach the problem - point is I've seen (real world) Rust code on a project which looked and felt way more "FP" than procedural to me. But, it's more like I "dabbled" in Rust than that I could consider myself truly knowledgeable (let alone an expert) in it, I'm definitely not in a position to prove anything.
Nice overview - you could have mentioned how heavily FP (functional programming) influenced Rust is, that's one of the first things I noticed when studying it.
Rust, in my opinion, is one of the most elegant programming languages - personally I think it's better designed than Go (what I really dislike about Go is the total absence of abstract types or generics, which makes functional style programming virtually impossible, forcing the programmer to do everything procedurally).
Even though it's not a pure FP (Functional Programming) language, it reminded me a LOT of Haskell. Amazing how well Rust's type checking works to ensure safe and "correct" programming.
By the way, what I also noticed is how fantastic Rust's official documentation (the Rust Programming Language tutorial) is - that's really a rare example of official docs that you can read from cover to cover and that makes 3rd party tutorials redundant.
This is a fantastic comment. Really. Btw, I agree with you. I never saw this kind of official documentation.
I also like Nim's documentation.
nim-lang.github.io/Nim/tut1.html
nim-lang.github.io/Nim/tut2.html
nim-lang.github.io/Nim/tut3.html
Nice, I came across Nim sometime ago ... how would you say it compares to Rust? It sort of looks like a cross between Rust, Go and Python - it uses indentation instead of semicolons, it does have a runtime and garbage collector, and so on. Something like combining "best of" features from Go and Rust with Python syntax thrown in :-)
I'm not sure that there's too much of FP in Rust. With all nice abstractions and lambdas, Rust discourages programmers from using by-value arguments, since in move semantic it can only happen once and when borrowing (especially mutably) we're dealing with references and mutate state in place which is be definition procedural.
Not sure if I understand your argument - when you say "when borrowing (especially mutably)" then you already assume that you're using mutable variables, implying that you're using a procedural rather than an FP approach ... that's an option, but not the only way to do things.
When going through Rust's official docs (the programming language tutorial) they seem to emphasize abstract data types and interfaces before they do "OO" constructs - and variables being immutable by default promotes an FP approach as well. Could be me, but many concepts in Rust reminded me a LOT of Haskell.
Of course Rust is not a pure FP language, so you can program procedurally if you want, but then in my opinion you're not using Rust's full power.
Let's figure out what is functional first. You mentioned Haskell, and even though it's been many years since I played with it, but if I'm not mistaken it doesn't allow mutation of a function arguments. So functions are pure: they take values and return a fresh value. Even though you can formally do the same with Rust, it won't work in practice, here's the example.
Suppose you have a Vector and a function
length(list: Vector<T>) -> i32that returns length. If you call it on a vector, it'll be moved. And none of the subsequent calls on a variable holding that vector will work. Instead Rust encourages using borrowing:length(list: &Vector<T>) -> i32and passing refs in this case. And in this case it's perfectly fine to call functions (procedures?) with refs multiple times.Now why I call these procedures:
do_something(&mut self)would not return anything, and rather mutate the state of the struct it's attached to. So technically it's not a function, but a procedure that mimicks methods from OOP.And I guess it's perfectly fine, especially given that it's dictated by the reasons of performance and explicit resources control, but for someone with functional mindset (such as myself) it might be quite painful to adjust.
I won't argue with you on this particular example, but maybe the result (whether or not you run into these limitations) depends on how you approach the problem - point is I've seen (real world) Rust code on a project which looked and felt way more "FP" than procedural to me. But, it's more like I "dabbled" in Rust than that I could consider myself truly knowledgeable (let alone an expert) in it, I'm definitely not in a position to prove anything.
Some interesting points regarding whether or not Rust can be considered "functional":
fpcomplete.com/blog/2018/10/is-rus...