Can't wait for tinkering with OCaml when 5.0 is stable. Pretty sure the community will invent amazing libraries for parallel computation as well.
Maybe finally Rust+tokio projects will have some actual competition!
Maybe finally Rust+tokio projects will have some actual competition!
I think all these "properly typed" languages should aspire to have great interoperability: after all, they have types to help. But I realize there can be big technical difficulties in making it safe, in particular with garbage collection..
the readme of ocaml-interop says it's "inspired by" ocaml-rs
while ocaml-rs says it "uses ocaml-interop behind the scenes" and "also exports an interop module, which is an alias for ocaml_interop and the two interfaces can be combined if desired"
from a cursory look over ocaml-rs seems possibly the one to use, as the more comprehensive project
The syntax is really cool, it looks like python but it's completely whitespace insensitive.
The module system is neat, and I actually like writing module interfaces (which are basically analogous to header files in C/C++). It makes dependency injection trivial, because you can have a module say "I depend on a module with this interface, but the caller can choose which one", which is more useful than it sounds.
It's also a functional language, so you have very little mutability, and it supports """monads""" with its super innovative "monadic let" syntax. (It's basically like overloading the semicolon, which probably doesn't make any sense, but it's really cool.)
Dune is a very pleasant build system and Esy is a very pleasant package manager. The language server is good. I'd say in this dimension it's competitive with Rust.
There's really quite a lot to like about OCaml. My biggest gripe with it is no typeclasses/traits. But I have hope that modular implicits will land within our lifetimes.
You say it is a package manager. Is it supposed to replace opam ? If so what does it offer that opam doesn't ?
I'm squinting really hard but not seeing the resemblance.
That's compensated by the use of double semicolons :O)
[1] https://github.com/ocaml-multicore/domainslib
[2] See the http server performance graphs at https://tarides.com/blog/2022-03-01-segfault-systems-joins-t...
I've scanned several articles (some made by you) and I very much like what I'm seeing.
Let's talk productivity in commercial projects. Or making scripts for your own use (if you're not happy with bash/zsh/fish... which I'm not).
Haskell only exceeds rust+tokio in terms of overall code elegance and succinctness.
When it comes to performance, rust+tokio is going to be much more performant by default as there will be no GC, no hidden traps with laziness, no subtle memory leaks etc.
Sure, a Haskell wizard will be able to reduce the gap further and solve issues but it is going to be difficult to consistently beat rust+tokio. By the time said Haskell wizard makes changes to the code, the famed elegance of Haskell is going suffer as the code will be littered with strange incantations of strictness annotations, possibly some C-ffi and other magic. This will not be the beautiful Haskell that you learn in textbooks. Only very few people know how to make Haskell truly fly. If you're one of them, then you're lucky!
This is nonsense without significant further qualification.
I guarantee the tokio scheduler and async stack model gives you net worse results for many real workloads.
What I meant was in the typical case, you can expect rust+tokio to be faster than Haskell. This is not a surprise as rust is much more low level, does not have a GC and its compiled output maps better to modern processors rather than the pure functional lazy style of Haskell.
Plenty of benchmarks across a variety of workloads and program confirm that Haskell is slower than rust on average. For webserver type use cases (which uses a lot of Async) Rust is faster. Check out tech empower benchmarks for example.
I've heard Haskell praise a good amount of times but at the same time many people also said that doing actual work with it has more friction than it should, so I don't know.
Well, based on your comment, I might reevaluate Haskell. Last time I was severely put off by lack of good tooling (but I did hear cabal was improving) and a fragmented ecosystem. Maybe things have changed.
nix-shell -p 'haskell.packages.ghc{version).ghcWithPackages (pkgs: with pkgs; [any number of packages here])'
But it's not only that. It's a general problem of a high initial learning curve.
Modern tool inventors really have to finally learn that everyone is super busy these days. Make it brain-dead quick to learn or your tool will forever remain a niche curiosity for hobbyists.
The reason I brought up the nix command is that I only use nix, for haskell development, for that specific command: I found it once in a blog post, saved it, then put it under a function into my bashrc, and I use nix quite literally for only that purpose. I've done a lot of development on various functional languages (with a dayjob in F# that lasted 3 years) and being able to quickly experiment with libraries was something that I sorely missed when doing repl experimentation in those languages (I think F# recently got a #nuget directive, but that was after I stopped using it).
Not to be the party pooper: didn't Docker work well for your Haskell use-case?
"Parallel and Concurrent Programming in Haskell" (2013)
https://www.oreilly.com/library/view/parallel-and-concurrent...
Have Haskell's ergonomics improved?
I feel your snark is unjustified. You might be putting people in two extremes: wise elders and hip kids. There's a huge amount of people in-between however.
(Also, the saying actually is: "You're going to where I am coming back from".)
Find me something like Erlang/Elixir with the speed of Rust and I won't learn another programming language ever again.
No? Then the search continues.
So far Haskell hasn't impressed. In all honesty Rust is quite hard to put in that niche as well since its `async` stuff is extremely annoying and hard to get right but I guess the tries are still ongoing. OCaml is progressing but who knows when will they get there.
https://engineering.fb.com/2015/06/26/security/fighting-spam...
As a guy who went through at least 8 languages and 30+ frameworks, it gets tiring. I want something that ticks most boxes from the get go.
You're describing haskell again.
You haven't articulated why you have disliked haskell in the past.
That could be okay for many but as I get older, I tend to take people/organizations that require big upfront investment less seriously.
Example: one of the things Elixir has won me over with were its bite-sized introductions and practices. You can be a 3/10 Elixir dev and you can be a 8/10 one, and that's mostly depending on how many of the official tutorials you've covered. The road is mostly a straight line to an acceptable level of proficiency at the end of which you can start choosing to specialize.
Rust, OCaml, Haskell -- they all failed that test for me.
I picked Rust mostly because of the no-GC situation and because of `cargo`. Many older programmers handwave away the importance of good tooling and this is where they lose a lot of potential mind share that can rejuvenate their languages / ecosystems.
Example on this: OCaml's tooling. A lot of people in this ecosystem always degrade the importance of a good task runner + builder + project manager. I spent half a weekend learning `esy` once and mostly tamed it by making it imitate mix/cargo but it wasn't trivial. The end result is a build script that does 80% of what mix/cargo do. The exercise made me scratch my head wondering why what I did back then isn't upstreamed and made official and why is everyone happy to pretend that building an OCaml project is a solved problem when it (very!) clearly isn't.
Haskell's cabal didn't fare better last I tried it -- admittedly that was more than a year ago.
If Haskell has good bite-sized lessons that lead to an actual real job productivity (less academic exercises, please!) then I'd be happy to give it a fair try and maybe make it a part of my toolbox.
Specifically, I realized how many problems we solved using OTP that would be much more challenging to get right otherwise. We can use processes to get transactional behavior, spawn workers very simply.
We use event sourcing.
Our state snapshots are just a process that receives events. It was easy to evict snapshots by killing processes idle for too long. Beautiful!
Test coverage becomes mostly wishful thinking. And it's extremely easy to do non-exhaustive pattern-matching which is something that just kills me.
It's absolutely true that Elixir is mega-productive though. And for a ton of projects out there it's good enough and more.
Your assessment reflects mine entirely. Elixir has that charm in that it leads you to productivity quickly, just as Go does. Someone could argue that's only because of much larger pool of users that's paved the path before.
Picking up Haskell again for fun, and the Effective Haskell book has been a fun learning experience. Not too beginner-ish, and doesn't take too much time to explain concepts.
I'll have to try esy and dune again sometime when OCaml 5's stable. Their commands are just different enough from go/cargo/npm to be annoying.