They don't have a borrow checker, but neither a borrow checker is required for memory safety or benefits of structural sharing. ML and Haskell make everything immutable by default and offer mutable cells as a special case.
The only thing you absolutely need some form of linear types (borrow checker) for is memory safety without a GC. But many applications can live just fine with a GC. Even in Rust, a fallback to runtime-checked ref cells is required in at least some cases.
My point is that what we really should be saying is "learn about typed functional languages". Some people will not like OCaml or Haskell or find it suitable for their use case, but that's equally true for Rust.
Software Engineer and full-time Rustacean. While Rust is my primary language, I am also fluent in Python and Typescript. I'm also currently making a game with Godot using C#.
I tend to take the opposite approach and say that rust provides safety without needing to go for a full functional language. I think both functional languages and rust have similar concerns. I just much prefer the way Rust approaches it because I'm not forced into one paradigm (functional vs imperative).
I use functional programming techniques a lot but I never want to be limited to them. It's one paradigm. It's not the only one.
Memory safety is only a tiny part of why I like Rust. Mostly I like the correctness and safety aspects. I think it has a good balance of features from many mainstream sources.
If Rust works for you, then it works for you. The problem is, you don't know what else is in the store. And you wouldn't be worse off if you knew. ;)
OCaml definitely doesn't force you into the functional paradigm. It even has an OO system with type inference for objects.
Among ML descendants, there's also Swift that tries it best to pretend it's not a functional language to avoid scaring Objective-C users off.
I never regret learning Rust. I also don't use it in my current projects, though I may use if it in the future.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
They don't have a borrow checker, but neither a borrow checker is required for memory safety or benefits of structural sharing. ML and Haskell make everything immutable by default and offer mutable cells as a special case.
The only thing you absolutely need some form of linear types (borrow checker) for is memory safety without a GC. But many applications can live just fine with a GC. Even in Rust, a fallback to runtime-checked ref cells is required in at least some cases.
My point is that what we really should be saying is "learn about typed functional languages". Some people will not like OCaml or Haskell or find it suitable for their use case, but that's equally true for Rust.
I tend to take the opposite approach and say that rust provides safety without needing to go for a full functional language. I think both functional languages and rust have similar concerns. I just much prefer the way Rust approaches it because I'm not forced into one paradigm (functional vs imperative).
I use functional programming techniques a lot but I never want to be limited to them. It's one paradigm. It's not the only one.
Memory safety is only a tiny part of why I like Rust. Mostly I like the correctness and safety aspects. I think it has a good balance of features from many mainstream sources.
If Rust works for you, then it works for you. The problem is, you don't know what else is in the store. And you wouldn't be worse off if you knew. ;)
OCaml definitely doesn't force you into the functional paradigm. It even has an OO system with type inference for objects.
Among ML descendants, there's also Swift that tries it best to pretend it's not a functional language to avoid scaring Objective-C users off.
I never regret learning Rust. I also don't use it in my current projects, though I may use if it in the future.