I wrote something loosely resembling the genserver pattern in OCaml once and don't remember having any significant problems with typing it. I simply made the genserver a functor over a module defining types of the state, request and response messages. The argument module provided a message handlers for messages, while the functor implemented the main loop of the thread, taking messages from mailbox and passing them to the handfler one at a time. The mailbox itself, I think, was provided by lwt already. So the argument module type was pretty slim: three types and two or three functions. Of course OCaml was still single-threaded back then, so I was using lwt library for concurrency. It worked pretty well, even in the browser, compiled to JS. No extensible type ugliness, no message filtering and complete type safety guaranteed by the compiler. No developer headaches about that. :)
Great episode. I learned about some really interesting sounding projects that I hadn't heard of before (ReasonML and ReScript). I really like the idea of bringing Erlang and OCaml together. Really interested to see where this project goes!
I might like the idea of limiting message size to have persistent messages. Force the user to persist the data and send a reference/id to it in the message...
Great interview, really loving your content! In a similar vein to the topic at the end of this interview about the work stealing, I think it would be really interesting to do some interviews/questions about the new Java Virtual Threads and the Golang Scheduler, and how they compare to BEAM.
I think Melange is the compiler that compiles Ocaml/Reason to Javascript and Rescript (which has diverged from Ocaml/Reason syntax/semantics) has its own compiler.
I don't think "effect handlers" is only used at runtime, i thought it can also be used in AOT compile-time, to assist a semantics-transistent transpile from one language to another (call it `cross-language monolithic DSL fusion`...)
I don't think what you said in the intro is correct. The letting it crash thing is not about just shipping code and hoping it works but about the mechanism it gives you to handle runtime errors.
Yeah, I was perhaps a bit cavalier there. 🤦♂️ Of course OCaml programmers want to monitor and handle runtime problems, just as Erlang programmers want to get their code right before they ship. I was just trying to find a way to highlight the main point - Erlang's got a very unique and interesting approach to runtime problems. 🙂
dynamic runtimes like Erlang's don't work like static stuff like OCaml's, you are comparing apples and oranges, a dynamic system is meant to run forever and from it you command it to do something, just like with emacs, or you send a message to it to do the cli stuff that you want.
Hi Comment section 👋 and thanks a million for hosting me Kris, I had a *ton* of fun! 🤩✨🐫 - happy to answer anything folks, just @ me :)
OcaML is my camel
Which big erlang book are you talking about ?
Nice talk btw
@@__samuel-cavalcanti__i was talking about Learn You Some Erlang For Great Good
¹❤❤❤❤❤❤q❤❤1❤1❤
I'm so happy I found this channel. It's easily the best software development content I've found on UA-cam.
I feel the same, is really good content
Leandro ostera is a 1000x developer. Truly inspiring contributions to the ocaml eco system
You always know how to choose my favorite topics. This channel is such a UA-cam gem.
new favorite episode of the podcast :)
Thanks for removing the looping music in your intro speech. It is easier to listen to what you are saying.
Great podcast as always :D
I wrote something loosely resembling the genserver pattern in OCaml once and don't remember having any significant problems with typing it. I simply made the genserver a functor over a module defining types of the state, request and response messages. The argument module provided a message handlers for messages, while the functor implemented the main loop of the thread, taking messages from mailbox and passing them to the handfler one at a time. The mailbox itself, I think, was provided by lwt already. So the argument module type was pretty slim: three types and two or three functions. Of course OCaml was still single-threaded back then, so I was using lwt library for concurrency. It worked pretty well, even in the browser, compiled to JS.
No extensible type ugliness, no message filtering and complete type safety guaranteed by the compiler. No developer headaches about that. :)
Quality! This content is what we love!
Woohoo, more ML Lang talks. Love it.
Great episode. I learned about some really interesting sounding projects that I hadn't heard of before (ReasonML and ReScript).
I really like the idea of bringing Erlang and OCaml together. Really interested to see where this project goes!
First things first: 🧡 OCaml 🧡 My intro to functional programming. This looks like a fascinating project!
Also, please do Rust!
11:35 Rescript mentioned 🙌 I'd love to use it in some Typescript projects but was never quite able to get the hang of its TS integration though
I might like the idea of limiting message size to have persistent messages. Force the user to persist the data and send a reference/id to it in the message...
Great interview, really loving your content! In a similar vein to the topic at the end of this interview about the work stealing, I think it would be really interesting to do some interviews/questions about the new Java Virtual Threads and the Golang Scheduler, and how they compare to BEAM.
41:17 "And that means you don't need Redis". Topical!
So effing cool!
I think Melange is the compiler that compiles Ocaml/Reason to Javascript and Rescript (which has diverged from Ocaml/Reason syntax/semantics) has its own compiler.
very interesting, I've discover so much.
You should cover rescript, it's pretty cool
You should get Mitchell Hashimoto on and talk about the new terminal emulator "Ghosty" he's building :)
I don't think "effect handlers" is only used at runtime, i thought it can also be used in AOT compile-time, to assist a semantics-transistent transpile from one language to another (call it `cross-language monolithic DSL fusion`...)
A program on a runtime system can be viewed as a sequence of "effects", this can be monolithic, while different language impls can be polymorphic
Wooo!!!
I don't think what you said in the intro is correct. The letting it crash thing is not about just shipping code and hoping it works but about the mechanism it gives you to handle runtime errors.
Yeah, I was perhaps a bit cavalier there. 🤦♂️
Of course OCaml programmers want to monitor and handle runtime problems, just as Erlang programmers want to get their code right before they ship. I was just trying to find a way to highlight the main point - Erlang's got a very unique and interesting approach to runtime problems. 🙂
very cool
dynamic runtimes like Erlang's don't work like static stuff like OCaml's, you are comparing apples and oranges, a dynamic system is meant to run forever and from it you command it to do something, just like with emacs, or you send a message to it to do the cli stuff that you want.
to be fair, 'failing gracefully" is hardly an acceptable premise in industry proper