The feature in OxCaml that more languages should steal
tosh
20 points
9 comments
July 04, 2026
Related Discussions
Found 5 related stories in 864.9ms across 14,015 title embeddings via pgvector HNSW
- A new C++ back end for ocamlc glittershark · 146 pts · April 01, 2026 · 55% similar
- Methods in Languages for Systems Programming (2023) surprisetalk · 17 pts · March 16, 2026 · 52% similar
- O(x)Caml in Space yminsky · 233 pts · May 15, 2026 · 51% similar
- Comparing Objective Caml and Standard ML lambertsimnel · 14 pts · May 21, 2026 · 51% similar
- Coalton is an efficient, statically typed Lisp with ideas from Haskell and OCaml b-man · 33 pts · May 26, 2026 · 50% similar
Discussion Highlights (4 comments)
Georgelemental
> In most languages (Java, Go, C#, Rust, Zig, OCaml, etc.) the process is reversed: you take a profiler to try and find allocations (usually in loops that happen millions of times). Then you go and eliminate or minimize the allocations. This isn't fully correct. In Zig, the common pattern is that any function which allocates accepts an explicit allocator parameter; if you don't pass one explicitly, you don't get any heap allocations. Rust doesn't make things quite that visible. But, if you restrict yourself to the standard library and crates designed with this in mind, allocations are usually not too hard to find. And you can always use `#![no_std]` without `alloc` if you want to be sure. Neither language is ever going to insert a heap allocation if it's not somewhere in the source.
xg15
Can we extend this to more properties, such as: Does IO, makes system calls, launches or interacts with threads, may block or has an unexpected space/time complexity?
pjmlp
Managed languages already had explicit stack allocation during the last century. Unfortunately we went crazy with heap only types, on the other hand thankfully the pendulum is turning around and most compiled languages are having them back. However nothing of this matters if you end up shipping the app inside Electron.
lioeters
This is one of those language features that you can't unsee after you learn about it. In hindsight it feels like it should have been common sense, like avoiding or preventing global variables, GOTO statements, mutable state, etc. And usually you start noticing that good software developers have already been practicing it by instinct.