Oxidizing OCaml: Locality
blog.janestreet.com
Oxidizing OCaml: Locality
1–10 of 72 posts
Re: Oxidizing OCaml: Locality
#2Re: Oxidizing OCaml: Locality
#3https://github.com/ocaml-flambda/ocaml-jst/blob/main/jane/do...
Re: Oxidizing OCaml: Locality
#4Seems like nim could be a good replacement? GC when you need it and explicit control when you need that.
> Ideally, a language could provide a spectrum of allocation strategies freely interoperable within a single application. With modes, users can write OCaml with all the usual GC guarantees—but when performance is paramount, opt into the consideration of lifetimes, ownership, and concurrency.
Re: Oxidizing OCaml: Locality
#5Seems like nim could be a good replacement? GC when you need it and explicit control when you need that.
Re: Oxidizing OCaml: Locality
#6Seems like nim could be a good replacement? GC when you need it and explicit control when you need that.
Re: Oxidizing OCaml: Locality
#7* 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?
Re: Oxidizing OCaml: Locality
#8Seems like nim could be a good replacement? GC when you need it and explicit control when you need that.
Nim is such a nice language, I would really love to see some high-visibility corporate adoption for it.
Re: Oxidizing OCaml: Locality
#9Seems like nim could be a good replacement? GC when you need it and explicit control when you need that.
Nim is such a nice language, I would really love to see some high-visibility corporate adoption for it.
where nim fits? how it can compete with other new fits and other old?
Re: Oxidizing OCaml: Locality
#10I believe this is an explanation (part of) of this proposal: https://github.com/ocaml-flambda/ocaml-jst/blob/main/jane/do...