The road to OCaml 5.0 • Hacker News Board

Re: The road to OCaml 5.0

#81

Post by Zababa » Thu, Oct 07, 2021, 5:08 PM UTC

yawaramin wrote: post #66

bigjimslade wrote: post #52

I really wanted to like OCaml, still do. I gave it a good shot a couple of years ago, wrote a few basic programs and loved it. But it to me seemed packaged like many languages in the days of yore, when a language shipped simply as a compiler, and nothing more. The way of the world today to me seems to be a compiler, together with a complete standard library and consistent packaging system. My experience with OCaml wa…

A couple of years ago, opam was the recommended package manager and dune was the recommended build system–just as today. The opam package index was also searchable for libraries. The OCaml website may have been slightly less clear about these things than it is now, but I think a reasonable user would have been able to find them, especially if they went to the forum and asked. People would have gladly answered questio…

I don't think that's totally fair. The Up and Running page of the OCaml website (https://ocaml.org/learn/tutorials/up_and_running.html) was added during 2020. Before that it lacked a straighforward introduction on what you need and how to install it. Node, Go and Rust all come with the package manager, and Rust even comes with a way of managing the different Rust versions. The essential part are here, and everything works well, but for new users it lacks polishing. You can argue that it would take a lot of time for a community that is a bit short on manpower, and that's true. But in the end the experience isn't as good as with other ecosystems.

Re: The road to OCaml 5.0

#82

Post by hajile » Thu, Oct 07, 2021, 5:09 PM UTC

short_sells_poo wrote: post #71

hajile wrote: post #15

Earlier quoted context omitted.

If your language doesn't worry about lifetimes, they don't go away. It just means you have to worry about them yourself instead. Sometimes that is great. Other times, that will be very hard and error-prone.

When you are trying to solve a complex optimal payoff problem, you really don't want to get bogged down with lifetimes. That's a completely orthogonal concern to what you are trying to establish. You are not writing production code, you are doing research. It's the core reason why languages with easy REPL and immediate feedback (like matlab, R, python, julia, etc...) are used for research, because you get immediate a…

Most of my day-to-day coding is in Typescript and I often find myself wondering if more than a few jobs wouldn't be easier and faster with plain JS and no need to feed the type checker. Many of the same thoughts about you vs the language tracking things applies here too.

In my case, I'd say that yes, I have to track the types myself, but the tradeoff is at least sometimes worth the extra mental overhead in my opinion. I'd say that the same can be true for lifetimes as well.

In your case, you will definitely be tracking lifetimes on some level and to say otherwise is going to be false (even GC'd languages must track lifetimes to ensure garbage is eliminated). The question is about the mental tradeoff vs the time taken. I'd guess that you are correct in your assessment. My only real point is that there is a cost that should be considered.

Re: The road to OCaml 5.0

#83

Post by typon » Thu, Oct 07, 2021, 5:39 PM UTC

hajile wrote: post #76

typon wrote: post #20

Earlier quoted context omitted.

An extremely simple thing like having two objects stored in a struct where one object has a reference to the other is a Herculean task in Rust. This is not a language designed for prototyping...

This is perhaps where I get hate from both sides, but I think such cases are best done in unsafe code blocks. A tool that makes something much harder without any meaningful gain should be avoided. Rust provides the tools to not have to fight the system and they should be used in these situations.

That's what my solution is. I am not going to get into pins and get cargo crates to solve such a simple problem. I just resort to unsafe. But then at that point...C++ is easier for me.

Re: The road to OCaml 5.0

#84

Post by typon » Thu, Oct 07, 2021, 5:39 PM UTC

jjnoakes wrote: post #50

typon wrote: post #23

Earlier quoted context omitted.

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.

You can read through this SO question and the top response does a good job explaining the possible solutions: https://stackoverflow.com/questions/32300132/why-cant-i-stor...

Re: The road to OCaml 5.0

#85

Post by octachron » Thu, Oct 07, 2021, 6:19 PM UTC

Zababa wrote: post #62

AzzieElbab wrote: post #51

I write a lot of Scala for living, Ocaml looks a bit outdated to me. Having said that, Ocaml compiler is one of the greatest miracles in PL when it comes to speed vs complexity of the language. Scala/Haskell/TS are not even close. I hear Ocaml's runtime performance is not too shabby either

What do you find outdated about it? > Having said that, Ocaml compiler is one of the greatest miracles in PL when it comes to speed vs complexity of the language. Scala/Haskell/TS are not even close. Someone will probably come correct me but what I've heard is that the compilation speed partially comes from the Pascal/Modula-3 influence, since Niklaus Wirth took compilation time into account when designing programmin…

The OCaml module system and its separation between interface and implementation is inspired from Modula-3 indeed. And the OCaml compiler is built to be able to compile compilation units while only knowing the types of its direct dependencies. This helps with both separate compilation (you don't need to recognize cycles, nor do you need to know anything about the implementation of your dependencies) and incremental compilation (you can minimize the number of components to rebuild if only an implementation changed and not an interface). It is surprisingly easy to break this property, for instance by requiring to have some global knowledge of all types involved in a program during compilation, or only compiling monomorphic functions.

Re: The road to OCaml 5.0

#86

Post by mirekrusin » Thu, Oct 07, 2021, 6:35 PM UTC

sidkshatriya wrote: post #49

mirekrusin wrote: post #47

Earlier quoted context omitted.

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

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?

Re: The road to OCaml 5.0

#87

Post by Zababa » Thu, Oct 07, 2021, 6:55 PM UTC

octachron wrote: post #85

Zababa wrote: post #62

Earlier quoted context omitted.

What do you find outdated about it? > Having said that, Ocaml compiler is one of the greatest miracles in PL when it comes to speed vs complexity of the language. Scala/Haskell/TS are not even close. Someone will probably come correct me but what I've heard is that the compilation speed partially comes from the Pascal/Modula-3 influence, since Niklaus Wirth took compilation time into account when designing programmin…

The OCaml module system and its separation between interface and implementation is inspired from Modula-3 indeed. And the OCaml compiler is built to be able to compile compilation units while only knowing the types of its direct dependencies. This helps with both separate compilation (you don't need to recognize cycles, nor do you need to know anything about the implementation of your dependencies) and incremental co…

Thank you for the explanation.

Re: The road to OCaml 5.0

#88

Post by Zababa » Thu, Oct 07, 2021, 6:59 PM UTC

pjmlp wrote: post #74

AzzieElbab wrote: post #54

Earlier quoted context omitted.

speed. Ocaml compiler is probably as fast as Go one

GHC has many backends and there is GHCi as well. No need to always go through the slowest path.

The regular backend is the fastest according to their docs: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu.... Having an interactive toplevel isn't a substitute for fast compilation (and OCaml has both).

Re: The road to OCaml 5.0

#89

Post by AzzieElbab » Thu, Oct 07, 2021, 7:31 PM UTC

sidkshatriya wrote: post #65

AzzieElbab wrote: post #51

I write a lot of Scala for living, Ocaml looks a bit outdated to me. Having said that, Ocaml compiler is one of the greatest miracles in PL when it comes to speed vs complexity of the language. Scala/Haskell/TS are not even close. I hear Ocaml's runtime performance is not too shabby either

Agree - there are some aspects to OCaml that feel a bit outdated but the language has been trying to refresh itself over the last few years. With multicore (and a minimal version of effects) in OCaml 5.0, certain aspects of the OCaml will become state of the art again. This is just the start though -- lots of interesting features (around effects especially) should land in the future. You mention that you write a lot…

I disagree on everything you said about scala, except your point about JVM :) but obviously I am biased. WRT to JVM, pure FP recursion (beyond simple tail call elimination) relies on trampolining which is a whole other can of worms. Stacksafe but with heavy performance penalties.

Re: The road to OCaml 5.0

#90

Post by thingification » Thu, Oct 07, 2021, 8:37 PM UTC

SquishyPanda23 wrote: post #31

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…

Some of the Python FFI tools are listed here: https://ocamlverse.github.io/content/ffi.html . But clicking through to GitHub, the repos haven't been updated in a while.

https://github.com/thierry-martinez/pyml -- 2 days ago