A Path Not Taken for OxCaml
23 points by henrytill
23 points by henrytill
I'm only lightly familiar with OxCaml but the situation looks pretty good to me actually.
There's no strong split, the features are still under development and it looks like they could be added to the upstream compiler. It's certainly going to take time but it's more promising than having something that is never adopted or merged.
It also seems quite consistent with OCaml where you are usually high-level with pretty good performance but can also suite easily start optimising part of your code and get nice speedups where it matters. In that context, OxCaml is an additional space of optimizations for limited parts of your code, not something you use everywhere.
Some very limited parts of your code are more cumbersome to write than they could be but the benefit is that 99.9% of your code is much simpler. That's a tradeoff that sounds pretty good to me, and that is typical of OCaml.
Kind of disappointing that the pay as you go complexity promise fails. My five minutes of thinking about this would have naively expected portable to be the default but in some kind of expensive way that could be fixed with either overrides or by declaring nonportability.
Swift is going through the same type of evolution and the complexity is so high I’ve just given up on learning it right now. They do have a very strong focus on letting the programmer ignore more advanced stuff until it’s needed, but the implementation often fails to keep that promise.
Imo some friction comes from OCaml being a language where values are happily shared without defined ownership and now modes apply at the value level, which means a value can only be portable if it was born portable? Is there a copy-like function to create / launder portable values from non-portable ones?
The language I'm currently prototyping tries to use separation of mutable regions to prevent data races. The function types look like they do in OxCaml (but values are polyporphic over regions, not their portability mode), but since regions are not as fine-grained as single values, this hopefully doesn't bite as much in practice