Hacker News Reader

> Only thing that is holding it back more than that and the reason I have not done many projects with it, is it weirdly fragmented ecosystem.

I wonder if that's precisely why people use it. I've been thinking about it, and I think people using OCaml value independence a lot. That's something that doesn't help building a community, since communities often thrive on consensus. As an example of that in the linked thread: Yaron Minsky's second comment about Flambda 2, which I'll copy here:

> And, I should add: Jane Street’s intent to upstream our work is not the same as upstream’s intent to accept it. None of what I’ve said is an announcement on behalf of the core OCaml team, nor am I in any position to make such an announcement!

This comment, to me, speaks volumes in terms of respect for the independence of the OCaml team. And independence seems to be something Jane Street values a lot too. They have lots of libraries that they freely share with other people. If you want to use, in a way, their "flavor of OCaml", you're free to do so. And if you don't want to, you're free to do something else.

You can see the same thing with JSOO, ReasonML/Reason/ReScript and now Melange. You're free to pick what you want. Same thing with the multicore. You want to use it? Great! You don't want to? They are working hard to make sure your code will still work and won't suffer too much performance regressions.

It may be a bit weird if you're used to other communities, I know I took a long time to understand why things are this way, and I may still be completely wrong. But I think the angle of valuing independence explains a lot, and is also a good way to know if it's a language and ecosystem for you or not.

Another thing that may not help: the book "Le langage Caml" is a great introduction to the language and programming, but sadly it's not translated.

> Only thing that is holding it back more than that and the reason I have not done many projects with it, is it weirdly fragmented ecosystem.

Maybe you are referring to the Async/Lwt dichotomy? Hopefully with multicore (and basic support for "effects" that are going to be merged in OCaml 5.0) this will become less of an issue going forward. Since the runtime is becoming considerably more capable, I expect there to be less "real" fragmentation going forward as the libraries begin to use more of the primitives provided by the runtime rather than building their own from scratch.

But then again, fragmentation is a way of life in other ecosystems too. Haskell has an ever increasing number of effect systems and preludes, Rust has many async runtimes also (async-std, tokio etc.). Fragmentation can often mean a time of competition and vitality as different approaches duke it out.

Regarding syntax -- I feel too much time has been spent in the OCaml ecosystem on surface syntax. OCaml syntax has its flaws but syntax is really a small aspect of the overall art of programming. The OCaml format is here to stay -- even if it is a bit wonky. Once you commit to it you can begin to worry about more substantial things. The ReasonML community brought in the new syntax, but with the departure of Rescript (Bucklescript) from the OCaml community I expect the usage of the new javascript-y syntax to decrease.

(If I may be heretical, I actually prefer the traditional OCaml syntax! ReasonML tries to be like JavaScript with the braces and so forth. I prefer the Haskell/OCaml syntax to the JavaScript/Rust/C/Scala brace syntax. Interestingly, Scala 3 allows a braceless style in an effort to match Python perhaps. Fashion changes. Algorithms and programming patterns endure. We shouldn't worry about the syntax so much -- as long as it is not APL ;-) ! )

> (...) with the departure of Rescript (Bucklescript) from the OCaml community (...)

I wasn't aware anything like that is happening, is it? Rescript departed from Reason, that's all, right? They want to focus solely on js target, because... that's what rescript is. New stuff they're doing looks really good.

What I meant is that Rescript is not really tied to OCaml as strongly as it was before. The connection before was: ReasonML frontend + Bucklescript compiler backend. Now you just have Rescript which is a rebranding of Bucklescript with a more focussed front-end language (which is a subset of ReasonML).

ReasonML aims to supports all of the OCaml syntax while Rescript's aim is to preserve only that syntax that is beneficial for a JS target.

ReasonML syntax can be used to do backend OCaml programming as well as front end programming. Rescript is focussed only on the (browser) frontend and drops some features from ReasonML. Its all quite complex and confusing but the TL;DR according to me is that ReasonML syntax is not going to be as important in the OCaml community as before...

I don't think ReScript is a subset of ReasonML. It's forked language that already has some substantial differences and will keep diverging.

ReScript is very active. ReasonML is dead for quite a while now. I'm pretty sure ReScript will drop ReasonML syntax soon?

> It's forked language that already has some substantial differences and will keep diverging.

This is really about opinion and individual assessment. It depends on how much emphasis one assigns to surface syntax vs deep language features.

Yes, the surface syntax of Rescript has been cleaned up a bit. There are some new language features but the language is still "close" to OCaml/ReasonML as of end 2021 according to me. If you're able to understand OCaml/ReasonML today you won't have much problem reading Rescript.

But, yes, it is diverging and it could look very different in the coming years.

The best source of information is probably this thread: https://discuss.ocaml.org/t/a-short-history-of-rescript-buck...

Yes, thank you, I don't see any OCalm depart there, just depart from ReasonML is mentioned.

I think the "depart" is not supporting newer OCaml feature. While Rescript/ReasonML at first was just an alternative syntax, it has now become a standalone programming language.

I'm sure they'll support new features that apply to rescript runtime context.

Things that don't make sense in javascript runtime context should not be supported.

Backward compatiblity on OCaml side is also something they don't need to care about as its ephemeral - it must typecheck and spit out valid javascript code, that's all.

I find it really interesting how I had never heard of OCaml before frequenting HN, but how incredibly passionate so many people here are about the language.

It honestly seems like a great lang, and I hope I get to try it out for a project sometime soon.

"I find it really interesting how I had never heard of <THING> before frequenting HN, but how incredibly passionate so many people here are about <THING>" is one of the thing I love about this place. There are always people ready to share their knowledge and passion about something I didn't know before.

> Frontend there is that ReasonML/Reason/ReScript thing that Facebook it trying to do. It offers an alternative syntax but nearly nobody uses it because they changed the name and I think also the syntax three times already. So it is all a mess.

"Nobody" uses ReasonML / Reason.

Plenty of people use ReScript.

I wasn't a big fan of the ReScript split, but I think by now it's unfair to speak of these as if they're one community with a confusing story. I think it's very fair to say it's now two separate communities: ReScript and OCaml. It was very confusing for a while, but by now it actually is much easier to understand than before the ReScript split:

ReScript is really its own language now. The compiler for that language just happens to still understand OCaml syntax, for now. The ReScript language and community is focused on the JS ecosystem, with readable JS output.

OCaml has js_of_ocaml. JSOO compiles OCaml to JS, so it's focused on the OCaml ecosystem. The JS output is not readable but you can build "any" OCaml program.

Really that's the main story -- not so hard to grasp?

There is also melange, but that's a relatively new effort in the OCaml community (attracting OCaml-y refugees from ReScript) whose status I haven't formed a view on yet. The idea is to compile OCaml programs to readable JS. Reason used to do that, but Reason now only has a tiny community (and I believe it now uses JSOO?). ReScript still does that, but using it for that purpose is no longer supported.

> The compiler for that language just happens to still understand OCaml syntax, for now.

I think another important point is that the compiler is a fork of the OCaml compiler. That means that to contribute/maintain the compiler, you need to know OCaml. This is probably going to stay this way for a very long time, since the speed of the compiler is important.

> Really that's the main story -- not so hard to grasp?

What's not helping is that the people around Reason never really said "it's dead, move on to OCaml or Rescript". The pages for things like Reason Native, Esy, ReasonML are still up.

> I think another important point is that the compiler is a fork of the OCaml compiler. That means that to contribute/maintain the compiler, you need to know OCaml. This is probably going to stay this way for a very long time, since the speed of the compiler is important.

Important to the maintainers, absolutely -- but not directly important to users of course: it's firmly the goal that you don't need to know any OCaml to use ReScript (and I think it's mostly true by now).

> What's not helping is that the people around Reason never really said "it's dead, move on to OCaml or Rescript". The pages for things like Reason Native, Esy, ReasonML are still up.

I assume they'd say they're not dead. I think Jord Walke, for example, didn't want to break his commitment to existing users using it for native projects, so put in effort to help people switch to a JSOO-based Reason (I haven't followed that story, so not sure how that turned out). I think that's good behaviour.

They certainly have a far smaller community than before though, because most people went to either ReScript or OCaml, or kept a foot in both communities for different uses (and no doubt some left entirely).

> Important to the maintainers, absolutely -- but not directly important to users of course: it's firmly the goal that you don't need to know any OCaml to use ReScript (and I think it's mostly true by now).

That's true, and according to the maintainers, with the recent improvements it should be easy to maintain. And using tools written in other languages is not a first for JavaScript users (ESBuild comes to mind).

That's the main story for targeting JS, but reason native is not dead (unless something has changed recently, I haven't been actively working with it for a while).

Just my experience when I was trying out OCaml (I was mostly trying it out for frontend using the bucklescript-tea package) was that most people in that space used the ReasonML syntax. I don't remember my exact issues, but I was trying to avoid using the reason syntax because I preferred OCaml's. There were a couple of hurdles I needed to get over before being able to even really begin. This was probably 3-4 years ago, so things may have changed.

If they can also ship algebraic effects (and even better, typed algebraic effects), then I think it will push the language back firmly into "state of the art". This will mean it continues to get the attention it deserves. I'm excited about algebraic effects, I think they are much more intuitive than monads (and don't require code to be rewritten).

The current plan is to have runtime support for effects in 5.0, but without a syntax nor an effect type system. Those two will come later in the 5.x branch. The aim is to decouple the switch to the multicore runtime from the design of the typed effect system. In the interim period, effect handlers would be exposed through an experimental module (exposed through an experimental module (see https://discuss.ocaml.org/t/multicore-ocaml-september-2021-e...) to allow early experimentation.

Exciting stuff! Keep up the good work!

OCaml Workshop 2021 - Experiences with Effects - https://www.youtube.com/watch?v=k3oQwpyXmpo

multicore ocaml won't change adoption of the language in any significant way

I completely agree, only libraries in popular domains might

In some strange way, that is what I like about the language. OCaml is not about amassing the largest possible user base but making a great programming language. Of course, these two objectives are not contradictory but the point here is that OCaml aspires to be a language on which you can write ground breaking and innovative software, not necessarily _popular_ software.

OCaml has an academic flavor -- maybe it's not as academic as Haskell but it moves in similar ways. There is a desire to be correct and have a theoretical framework instead of amassing a ton of language features. OCaml is the foundation for Coq and other interesting compilers, type checkers and theorem provers. Over the years, the language has grown more mainstream and you can build a decent web backend on it today, for instance.

So fine, maybe multicore won't change adoption of the language in significant ways. But I foresee that the introduction of multicore will allow some amazing software to be written in OCaml in the future. Software that is truly groundbreaking and innovative. Take the example of Coq itself -- it is an important foundational software today in Computer Science. Multicore will allow Coq to potentially speed itself up and that will bring more real world applications in the ambit of Coq.

Is there a curated list of libs to review ?

https://github.com/ocaml-community/awesome-ocaml