4 ms·
The thing with F# is that (idiomatic) models/functions rely on type inference, and eventually is hard to see what is the flow without look at the IDE. Rust maki
by mamcx 6y ago
The thing with F# is that (idiomatic) models/functions rely on type inference, and eventually is hard to see what is the flow without look at the IDE. Rust making type annotations explicit with minimal inference is much clearer.
Also, the fact I can do mutation + imperative code locally yet give a functional feel make some hacks around this on F# unnecessary.
But probably the biggest thing is that Rust make idiomatic things like conversions with From/Into/AsRef/etc instead of rely in your own conventions, making code more readable in the long run.
Other source of simplification is serde. A lot of my stuff is transfer/(re)encoding of data and have a "de facto" idiom for this help a lot.
One thing that F# make far easier and I miss much is the sequences (https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/sequences https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...). Making iterators is boilerplate and wish Rust have generators in stable.
I found a decent library for this in https://lib.rs/crates/genawaiter https://lib.rs/crates/genawaiter but is not the same as have it in-build.
- Smaug123 6y agoAdmittedly I work for a very opinionated team - we even have our own style guidelines (https://github.com/G-Research/fsharp-formatting-conventions https://github.com/G-Research/fsharp-formatting-conventions) which are often in direct contradiction to Microsoft's, and my team strongly skews towards writing explicit type annotations on all function signatures. I can certainly see how there would be a problem if one defaulted to omitting type annotations.