The road to OCaml 5.0 • Hacker News Board

Re: The road to OCaml 5.0

#42

Post by octachron » Thu, Oct 07, 2021, 2:54 PM UTC

grumpyprole wrote: post #40

cardanome wrote: post #29

I really hope to see more interest in OCaml in the future. It is probably one of the most underrated programming languages. The perfect marriage between state of the art functional programming and pragmatism. A great static and strong type system. Solid performance and an insanely fast compiler. Also compiles to JS if you need that. Multicore support will make it quite perfect. Only thing that is holding it back more…

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.

Re: The road to OCaml 5.0

#43

Post by CactusOnFire » Thu, Oct 07, 2021, 3:00 PM UTC

cardanome wrote: post #29

I really hope to see more interest in OCaml in the future. It is probably one of the most underrated programming languages. The perfect marriage between state of the art functional programming and pragmatism. A great static and strong type system. Solid performance and an insanely fast compiler. Also compiles to JS if you need that. Multicore support will make it quite perfect. Only thing that is holding it back more…

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.

Re: The road to OCaml 5.0

#44

Post by Ankhers » Thu, Oct 07, 2021, 3:01 PM UTC

cardanome wrote: post #29

I really hope to see more interest in OCaml in the future. It is probably one of the most underrated programming languages. The perfect marriage between state of the art functional programming and pragmatism. A great static and strong type system. Solid performance and an insanely fast compiler. Also compiles to JS if you need that. Multicore support will make it quite perfect. Only thing that is holding it back more…

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.

Re: The road to OCaml 5.0

#45

Post by sidkshatriya » Thu, Oct 07, 2021, 3:02 PM UTC

cardanome wrote: post #29

I really hope to see more interest in OCaml in the future. It is probably one of the most underrated programming languages. The perfect marriage between state of the art functional programming and pragmatism. A great static and strong type system. Solid performance and an insanely fast compiler. Also compiles to JS if you need that. Multicore support will make it quite perfect. Only thing that is holding it back more…

> 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 ;-) ! )

Re: The road to OCaml 5.0

#46

Post by pharmakom » Thu, Oct 07, 2021, 3:07 PM UTC

mtoner23 wrote: post #21

short_sells_poo wrote: post #2

I run a hedge fund. On any given day I hear a large number of complaints from the technologists that complex python systems are difficult to look after and we should use something else instead. There's some Rust being used, but there's little chance to get a quant to use Rust to do research because research is an exploratory process and the last thing one wants is a language that requires a lot of thought about lifet…

Its not the language its the people, instagram is almost entirely run on python, if they can so can you. https://instagram-engineering.com/tagged/python

So Instagram runs on Python? That only proves that the Instagram team can build Instagram in Python. How does that help me with my technology choices?

Re: The road to OCaml 5.0

#47

Post by mirekrusin » Thu, Oct 07, 2021, 3:08 PM UTC

sidkshatriya wrote: post #45

cardanome wrote: post #29

I really hope to see more interest in OCaml in the future. It is probably one of the most underrated programming languages. The perfect marriage between state of the art functional programming and pragmatism. A great static and strong type system. Solid performance and an insanely fast compiler. Also compiles to JS if you need that. Multicore support will make it quite perfect. Only thing that is holding it back more…

> 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…

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

Re: The road to OCaml 5.0

#48

Post by rawoke083600 » Thu, Oct 07, 2021, 3:17 PM UTC

My favourite quote about OCaml:

"Never have I took so long, to write so little code, that does so much"

OCaml can be a big learning curve, but I urge you to push through. The syntax might not be everyone's cup of team, but you get used to it quickly.

Re: The road to OCaml 5.0

#49

Post by sidkshatriya » Thu, Oct 07, 2021, 3:18 PM UTC

mirekrusin wrote: post #47

sidkshatriya wrote: post #45

Earlier quoted context omitted.

> 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…

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

Re: The road to OCaml 5.0

#50

Post by jjnoakes » Thu, Oct 07, 2021, 3:20 PM UTC

typon wrote: post #23

carlmr wrote: post #22

Earlier quoted context omitted.

You can easily avoid such constructs in most cases though.

I've allocated both these things on the heap and Rust simply won't let me store them both together. I don't know about you but this is an extremely common pattern in almost all languages, you just don't think about it in the gc languages and in C++ storing pointers is no issue. The popularity of crates like rental also shows that it's not as easily avoidable as you suggest.

Can you post a simple code example? It is hard to imagine what the difficulty is.