Rust doesn't apply. You need a functional language for the kind of robustness we are talking about. Rust got some influences from there but it's not one.
- Discriminated unions with exhaustive check. Check
- No nulls by default. Check
- No exceptions in the business logic. Check
- Strict dependency order. Rust doesn't have this
- Warnings on unused expression results. Check
- Typed primitives. The level of ergonomics this is implemented with in F# I'll say Rust doesn't have this
- Explicit conversions. Check
- Functional approach to concurrency. I think Rust's compile time safety against data races gives this a check. I've used channels for concurrent server processes, it's nice. Check
- Explicit dependency injection. I've never understood what this means
Most of these points are related to strict type system. If that was the case, then Lisp wouldn't be functional programming language.
IMO the first and foremost principle of Functional Programming languages is that they are optimised around building programs in terms of function composition. And anyone who had to work with borrow checker and closures for 5sec knows, that this is not the case for Rust.
I think you've taken it backwards. The comment you were replying to is listing features that lead to robustness (many of which appear in strongly-typed functional languages in the ML family), not essential aspects of functional programming languages.
> - Explicit dependency injection. I've never understood what this means
The article seems to mean what's described in this other article as "dependency parameterization" where the dependency is explicitly passed to the function (and every function it calls that also needs that same dependency). This is as opposed to, in OO languages, setting the dependency (typically) during construction (however the object is constructed). Or it's otherwise set in some larger scope than the functions which make use of it (global, module, object instance, whatever is appropriate to the language and task).
Also because Microsoft spends relatively little on it and so it’s not changing at a fast pace.
The short answer - F# and similar languages provide confidence in correctness due to being strongly typed.
The long answer - https://bartoszmilewski.com/2014/10/28/category-theory-for-p...
Immutability by default contributes just as much if not more
I feel that shortened it too much.
Haskell, Ocaml, scala
anything else?
Rust, ReasonML
Rust doesn't apply. You need a functional language for the kind of robustness we are talking about. Rust got some influences from there but it's not one.
What are "we" talking about?
- Immutability by default. Check
- Discriminated unions with exhaustive check. Check
- No nulls by default. Check
- No exceptions in the business logic. Check
- Strict dependency order. Rust doesn't have this
- Warnings on unused expression results. Check
- Typed primitives. The level of ergonomics this is implemented with in F# I'll say Rust doesn't have this
- Explicit conversions. Check
- Functional approach to concurrency. I think Rust's compile time safety against data races gives this a check. I've used channels for concurrent server processes, it's nice. Check
- Explicit dependency injection. I've never understood what this means
7/10
Most of these points are related to strict type system. If that was the case, then Lisp wouldn't be functional programming language.
IMO the first and foremost principle of Functional Programming languages is that they are optimised around building programs in terms of function composition. And anyone who had to work with borrow checker and closures for 5sec knows, that this is not the case for Rust.
I think you've taken it backwards. The comment you were replying to is listing features that lead to robustness (many of which appear in strongly-typed functional languages in the ML family), not essential aspects of functional programming languages.
> - Explicit dependency injection. I've never understood what this means
The article seems to mean what's described in this other article as "dependency parameterization" where the dependency is explicitly passed to the function (and every function it calls that also needs that same dependency). This is as opposed to, in OO languages, setting the dependency (typically) during construction (however the object is constructed). Or it's otherwise set in some larger scope than the functions which make use of it (global, module, object instance, whatever is appropriate to the language and task).
https://fsharpforfunandprofit.com/posts/dependencies/
https://fsharpforfunandprofit.com/posts/dependencies-2/
Erlang, Elixir.