4 ms·

ML really is a beautiful and under-appreciated family of languages. Haskell is a bit too supernatural for my taste, but ML and its derivatives hit the sweet spo

ML really is a beautiful and under-appreciated family of languages. Haskell is a bit too supernatural for my taste, but ML and its derivatives hit the sweet spot between powerful type systems and natural syntax. As a Kotlin developer, I find reading OCaml code a breeze and the compiler is refreshingly snappy (much faster than Gradle). I just wish it had better developer tools.

throwaway894345 4y ago
I like Rust for syntax, tooling, and ML ideas but I wish there was a "Rust-lite" that was garbage collected.
- ChadNauseam 4y ago
  It's got its warts, but Ocaml (and ReasonML if you want a more familiar syntax) are right in that sweet spot for me.
  - throwaway894345 4y ago
    I need to give ReasonML another shot. It's been a few years, but at the time it really only seemed to work if you were targeting BuckleScript and even then you had to write a bunch of Makefiles and jump through other weird hoops. Beyond that, it suffered from some other OCaml issues--multiple "standard" libraries, different packages using different async libraries, some gratuitously abstract libraries, etc. I'm really hoping it breaks into the mainstream such that it gets the investment that other mainstream languages get (hopefully said investment will smooth out these rough edges).
- Serow225 4y ago
  that’s pretty much F# :)
  - mumblemumble 4y ago
    As a long-time F# user and current Rust learner, I would say the similarities are mostly cosmetic. First and foremost, F# is functional-first, while Rust isn't really functional. Rust takes some useful features from functional languages, to be sure, but the overall paradigm is more procedural. A lot of key functional idioms and design patterns don't really fly in Rust because it's difficult-to-impossible to make them play nice with its memory management model. Rust has traits, but not OOP. F# has OOP but not traits or typeclasses. F# is immutable by default, and discourages mutability. Rust is immutable by default, but embraces (and tames) mutability.
  - throwaway894345 4y ago
    If F# had static, native compilation by default, a closer Cargo analog, and eschewed the OO stuff (probably mostly just there for C# interop?) and the OCaml syntax.
- maficious 4y ago
  Gleam
  - throwaway894345 4y ago
    Yeah, this is one I’m keeping my eye on.
- gpderetta 4y ago
  with its shared-nothing-by-default thread model, rust would make for an excellent GC'd language as if it gave the ability of opting into GC on a per-thread basis with thread local heap and GC. Some relaxing of the shared-xor-mutable probably would need to be relaxed though. I don't know how practical it would be to implement in practice.
- gcr 4y ago
  how do you feel about nim?
  - throwaway894345 4y ago
    Haven’t looked much at it yet.
bmitc 4y ago
I fully agree. F# is my favorite language, and it almost feels like a statically typed Scheme at times, just with built-in pattern matching and pipes thrown in. It's a really great way to program, and it's easy to go imperative or OOP when needed without friction. The only thing missing from F# is an Elixir/Erlang/OTP-like process system (`MailboxProcessor` is pretty good though), but then again, every language except Elixir/Erlang/OTP is missing that.
- lf-non 4y ago
  I am not further enough in my F# journey to have tried this, but you could technically pair it with orleans for actor oriented systems ? Love the language though I have spent only a week working with it. It seems to have a lot of things I liked in Kotlin.
  - bmitc 4y ago
    F# does have the `MailboxProcessor`. It is quite simple and capable. https://fsharp.github.io/fsharp-core-docs/reference/fsharp-control-fsharpmailboxprocessor-1.html https://fsharp.github.io/fsharp-core-docs/reference/fsharp-c... https://fsharpforfunandprofit.com/posts/concurrency-actor-model/ https://fsharpforfunandprofit.com/posts/concurrency-actor-mo... I haven't looked at Orleans in a while. Last time I did, I came away with the viewpoint that it was very much designed to have a C# interface, which while manageable in F#, doesn't really provide for an idiomatic F# experience. I'm also not too sure, but I think it basically requires a cloud or distributed environment. Can it just be run on a local computer? But even the `MailboxProcessor` doesn't do what Elixir and Erlang do on top of the BEAM VM. An instance of a BEAM VM is a single OS process, but the BEAM can handle millions of Erlang processes, which are not OS processes or even threads. They are their own thing that are extremely lightweight. The BEAM scheduler is very nice as well, such that it switches among all the running processes. Even though I develop in Elixir, I am not yet a BEAM expert. So before I say something incorrect, I recommend taking a look at the talk The Soul of Erlang and Elixir by Sasa Juric. https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE It fully encapsulates and describes what makes processes so special in Elixir and Erlang. There is the Gleam language, which is a statically typed language on the BEAM VM. However, they moved away from the ML-dialect syntax, which is unfortunate.

throwaway894345 4y ago

I like Rust for syntax, tooling, and ML ideas but I wish there was a "Rust-lite" that was garbage collected.

ChadNauseam 4y ago
It's got its warts, but Ocaml (and ReasonML if you want a more familiar syntax) are right in that sweet spot for me.
- throwaway894345 4y ago
  I need to give ReasonML another shot. It's been a few years, but at the time it really only seemed to work if you were targeting BuckleScript and even then you had to write a bunch of Makefiles and jump through other weird hoops. Beyond that, it suffered from some other OCaml issues--multiple "standard" libraries, different packages using different async libraries, some gratuitously abstract libraries, etc. I'm really hoping it breaks into the mainstream such that it gets the investment that other mainstream languages get (hopefully said investment will smooth out these rough edges).
Serow225 4y ago
that’s pretty much F# :)
- mumblemumble 4y ago
  As a long-time F# user and current Rust learner, I would say the similarities are mostly cosmetic. First and foremost, F# is functional-first, while Rust isn't really functional. Rust takes some useful features from functional languages, to be sure, but the overall paradigm is more procedural. A lot of key functional idioms and design patterns don't really fly in Rust because it's difficult-to-impossible to make them play nice with its memory management model. Rust has traits, but not OOP. F# has OOP but not traits or typeclasses. F# is immutable by default, and discourages mutability. Rust is immutable by default, but embraces (and tames) mutability.
- throwaway894345 4y ago
  If F# had static, native compilation by default, a closer Cargo analog, and eschewed the OO stuff (probably mostly just there for C# interop?) and the OCaml syntax.
maficious 4y ago
Gleam
- throwaway894345 4y ago
  Yeah, this is one I’m keeping my eye on.
gpderetta 4y ago
with its shared-nothing-by-default thread model, rust would make for an excellent GC'd language as if it gave the ability of opting into GC on a per-thread basis with thread local heap and GC. Some relaxing of the shared-xor-mutable probably would need to be relaxed though. I don't know how practical it would be to implement in practice.
gcr 4y ago
how do you feel about nim?
- throwaway894345 4y ago
  Haven’t looked much at it yet.

bmitc 4y ago

I fully agree. F# is my favorite language, and it almost feels like a statically typed Scheme at times, just with built-in pattern matching and pipes thrown in. It's a really great way to program, and it's easy to go imperative or OOP when needed without friction. The only thing missing from F# is an Elixir/Erlang/OTP-like process system (`MailboxProcessor` is pretty good though), but then again, every language except Elixir/Erlang/OTP is missing that.

lf-non 4y ago
I am not further enough in my F# journey to have tried this, but you could technically pair it with orleans for actor oriented systems ? Love the language though I have spent only a week working with it. It seems to have a lot of things I liked in Kotlin.
- bmitc 4y ago
  F# does have the `MailboxProcessor`. It is quite simple and capable. https://fsharp.github.io/fsharp-core-docs/reference/fsharp-control-fsharpmailboxprocessor-1.html https://fsharp.github.io/fsharp-core-docs/reference/fsharp-c... https://fsharpforfunandprofit.com/posts/concurrency-actor-model/ https://fsharpforfunandprofit.com/posts/concurrency-actor-mo... I haven't looked at Orleans in a while. Last time I did, I came away with the viewpoint that it was very much designed to have a C# interface, which while manageable in F#, doesn't really provide for an idiomatic F# experience. I'm also not too sure, but I think it basically requires a cloud or distributed environment. Can it just be run on a local computer? But even the `MailboxProcessor` doesn't do what Elixir and Erlang do on top of the BEAM VM. An instance of a BEAM VM is a single OS process, but the BEAM can handle millions of Erlang processes, which are not OS processes or even threads. They are their own thing that are extremely lightweight. The BEAM scheduler is very nice as well, such that it switches among all the running processes. Even though I develop in Elixir, I am not yet a BEAM expert. So before I say something incorrect, I recommend taking a look at the talk The Soul of Erlang and Elixir by Sasa Juric. https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE It fully encapsulates and describes what makes processes so special in Elixir and Erlang. There is the Gleam language, which is a statically typed language on the BEAM VM. However, they moved away from the ML-dialect syntax, which is unfortunate.