esy VS eioio

As someone who wrote a fair amount of Rust and OCaml code, I have to agree with the author.

While working at Routine (YC W21), I was tasked with porting our core library to iOS to minimize code duplication. This was a lucky opportunity to write something resembling a compiler: it took in schemas described with our in-house data exchange library and generated C (for FFI) and Swift code (for the end-users, i.e., iOS developers).

Since Routine uses OCaml for everything (which was a big motivator for joining the company—I wanted to see how that would work out), I wrote it in OCaml. The end result is a 3-5k LOC project. It's by no means a full compiler, but it was lots of fun to write. The language got in the way incredibly rarely. On average, it made my life a lot easier.

We did encounter our fair share of issues, mostly due to the cross-compilation tooling (we initially used esy [1], flirted with Nix, and eventually switched to opam-cross-ios [2]), third-party libraries, and intricacies of FFI. Those do take their toll on sanity.

[1]: https://github.com/esy/esy/

What's the current status of Esy? https://github.com/esy/esy

Any plans to backport its design back to Opam?

It's great to hear that Opam is making progress! I just wished that it would be more deeply integrated with Dune. A package manager that doesn't build is not very useful to be honest. Currently the only way to not have to care about switches and be able to clearly specify dependencies is to use the esy package manager[1] (which had lock files a while ago).

[1]: https://github.com/esy/esy/

If you start a project today I would really try to use esy (https://esy.sh/)

I actually don’t use it myself but it seems to bring the modern programming language experience to OCaml

Another alternative is to use esy but I'm clearly biased here....

Here is link number 1 - Previous text "esy"

Alternatively, you can use esy.sh for a simpler setup/build process (it does not require running in a Cygwin shell).

Running esy does not work. Apparently, my environment does not know that it is there. Anyone know what is going on here? I have posted this in the discussion for esy@next here. I will get back to you all when I figure this out.

For 5.0+ you might want to look at https://github.com/ocaml-multicore/eio for how effects can make async much more pleasant

Great post! I would love to see this extended to OCaml 5 (with eio) and Haskell

Second, effects enable a new style of concurrency libraries like eio that forgoes the need to wrap every asynchronous computation in a monad.

> This is realllly unidiomatic in real world Haskell.

Whether idiomatic or not does not matter. It proves my point:

IO won't save you, and even very mundane effects are not part of the game…

Idris is the "better Haskell" sure, but the effect tracking is still part of the uncanny valley (still IO monad based).

Koka is a toy, and Frank mostly "only a paper" (even there is some code out there).

The "Frank concept" is to some degree implemented in the Unison language, though:

https://www.unison-lang.org/learn/fundamentals/abilities/

Having a notion of co-effects (or however you please to call them) is imho actually much more important than talking about effects (as effects are in fact neither values nor types—something that all the IO kludges get wrong).

I think the first practicable approach in the mainstream about this topic will be what gets researched and developed for Scala. The main take away is that you need to look at things form the co-effects side first and foremost!

In case anybody is interested in what happens in Scala land in this regard:

https://www.slideshare.net/slideshow/embed_code/key/aLE9M37d...

https://docs.scala-lang.org/scala3/reference/experimental/cc...

But also the development in OCaml seems interesting:

https://github.com/ocaml-multicore/eio#design-note-capabilit...

Look mom, "effects", but without the monad headache!

To enable access to all these features, an exciting new library called Eio is being developed. It uses a new paradigm of direct-style concurrent I/O programming, without the need for monads or async/await, thus avoiding the function colour problem.

Here's an example using OCaml 5 to run multiple fibers concurrently (look - no monads!):

https://github.com/ocaml-multicore/eio#fibers

Effects are included in OCaml 5, but considered experimental. This doesn't stop us from building libraries that take advantage of them internally, in order to provide really nice external interfaces.

The best developed one is "eio", which uses effects (and io_uring on Linux) internally in order to provide a really high performance, direct-style IO library for OCaml. You can walk through some of the code here: https://github.com/ocaml-multicore/eio#getting-started

Also a video talk about our experiences with using effects for writing parsers, from the OCaml Workshop last year. https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5...

Its a good time to try it. The tooling has come a long way and OCaml has an excellent build system [1] (dune is probably the best build tool I've used and I miss it whenever I use other programming languages), excellent editor tooling for vscode [2], emacs and neovim. OCaml 5.0 will bring multicore support [3] and an effect system that will cover a lot of interesting use-cases. As an example with OCaml 5 it'll be feasible to have concurrency libraries that still let you write in direct-style [4] [5]. I don't intend to say that OCaml will fit every use-case, but there is a lot going for it even in its current form before multicore support lands. If you want a language that compiles fast (it does compile really fast, at-part with Go if not better), has excellent performance characteristics, and has a good story for concurrency, you should give OCaml a chance!

[1] https://dune.build/

[2] https://marketplace.visualstudio.com/items?itemName=ocamllab...

[3] https://discuss.ocaml.org/t/the-road-to-ocaml-5-0/8584

[4] https://github.com/ocaml-multicore/eio

[5] https://github.com/anuragsoni/sandbox/tree/main/ocaml/effect...