Hacker News Reader

Comment by bmc7505 | Hacker News Reader

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.

View on HN

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.

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.

F# does have the `MailboxProcessor`. It is quite simple and capable.

https://fsharp.github.io/fsharp-core-docs/reference/fsharp-c...

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

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.

... and also Caramel which is a Ocaml/Reason dialect so you get to keep the Ocaml syntax

I have never tried it though

https://caramel.run/manual/introduction.html

Maybe one day Fable will add an Erlang backend.

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

It's got its warts, but Ocaml (and ReasonML if you want a more familiar syntax) are right in that sweet spot for me.

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).

that’s pretty much F# :)

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.

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.

Gleam

Yeah, this is one I’m keeping my eye on.

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.

how do you feel about nim?

Haven’t looked much at it yet.

Reply on news.ycombinator.com