Seems like nim could be a good replacement? GC when you need it and explicit control when you need that.
Not for Jane Street. They likely have millions of lines written in OCaml and rely heavily on its type system safety guarantees.
[deleted]
Oxidizing OCaml: Locality
31–40 of 72 posts
Re: Oxidizing OCaml: Locality
#32Earlier quoted context omitted.
Nim is such a nice language, I would really love to see some high-visibility corporate adoption for it.
I think it is not getting enough usage because a lot of people love that others should adopt it first.
I can sneak it into a few scripts here and there at work, and I can write my side projects in it, but there's only so much I can do.
Re: Oxidizing OCaml: Locality
#33Earlier quoted context omitted.
I think it was Steve Klabnik who said that it's basically the version of Rust with a garbage collector that people ask for. Might have been this episode of Oxide and Friends: https://oxide.computer/podcasts/oxide-and-friends/1208089
Rust was originally described to me as “Rust and C have a baby,” so yeah I’ve been a fan of this kind of thinking for a long time.
Rust is its own father? I think the borrow checker will make this difficult.
Re: Oxidizing OCaml: Locality
#34My understanding is that Go does a similar kind of optimization (where locals that don't escape don't go on the heap) but it does it automatically. This has the positive that you don't need annotations but the negative that you can assume some code is benefitting from the optimization when it isn't and there's no warning about it.
I'm curious whether the authors here considered this. I didn't see any discussion of related work in the post.
Re: Oxidizing OCaml: Locality
#35Re: Oxidizing OCaml: Locality
#36This is a great idea, but I have questions * Is there a process for upstreaming this into the mainline language, or is this essentially JaneStML now? * Why choose such an obscure word as `exclave` to indicate return-value optimization? How about `return local` or something similarly approachable?
Our long term aim is to upstream all of our work from our branch of the OCaml compiler. Of course, that is contingent on the ideas we’re developing there being accepted by the community. There are two main reasons we work on our own branch: 1. Language design is hard. At Jane Street we have a great opportunity to design new features, test them extensively in a realistic environment, and then change them. Because we h…
As someone from the community, I absolutely love this design (and blog post). It would be especially great for returning options, tuples, results, etc. with no overhead at all.
I suppose it could also be useful to allocate int64, floats, and maybe even bigints on the data stack? I suppose it's more difficult to put C blocks like bigints or bigarrays in a region.
Re: Oxidizing OCaml: Locality
#37Earlier quoted context omitted.
Rust was originally described to me as “Rust and C have a baby,” so yeah I’ve been a fan of this kind of thinking for a long time.
Rust is its own father? I think the borrow checker will make this difficult.
Lol, oops: I meant OCaml, if that wasn’t obvious.
Re: Oxidizing OCaml: Locality
#38Earlier quoted context omitted.
Rust is its own father? I think the borrow checker will make this difficult.
Lol, oops: I meant OCaml, if that wasn’t obvious.
OCaml is quite literally a parent of Rust since the original Rust compiler was written in OCaml. (I know you know that; I'm just highlighting how apt the analogy was. :)
https://github.com/rust-lang/rust/tree/ef75860a0a72f79f97216...
Re: Oxidizing OCaml: Locality
#39My understanding is that Go does a similar kind of optimization (where locals that don't escape don't go on the heap) but it does it automatically. This has the positive that you don't need annotations but the negative that you can assume some code is benefitting from the optimization when it isn't and there's no warning about it. I'm curious whether the authors here considered this. I didn't see any discussion of re…
My reading seems to be that the compiler can and will do it automatically.
The annotations make enforcement. It's easy to make the compiler put something on the heap by accident.
Re: Oxidizing OCaml: Locality
#40My understanding is that Go does a similar kind of optimization (where locals that don't escape don't go on the heap) but it does it automatically. This has the positive that you don't need annotations but the negative that you can assume some code is benefitting from the optimization when it isn't and there's no warning about it. I'm curious whether the authors here considered this. I didn't see any discussion of re…
From the post:
> Even without explicit mode annotations, the compiler can statically determine which variables may escape their enclosing region. Such variables are assigned the global mode; all others are automatically inferred to be local.
There's a little more info about mode inference in the proposal:
https://github.com/ocaml-flambda/ocaml-jst/blob/main/jane/do...
So arguments to "public functions" do require explicit annotations in order to be local, but otherwise the compiler is able to infer locality and this acts as a transparent optimization.