OxCaml - a set of extensions to the OCaml programming language.

Does Go have much in the way of GC knobs? It didn't some years ago, but I haven't kept up on latest developments

Java is like C and C++, there isn't the one implementation.

So if you want hard guarantees, you reach out to real time JVM implementations like the commercial ones from PTC and Aicas.

Couldn’t find this after 6 seconds of googling, link?

It is a common strategy.

It's a great name for a competitor :)

Is that really a viable solution for a timeframe of 6+ hours?

Are you aware of how many allocations the average program executes in the span of a couple of minutes? Where do you propose all of that memory lives in a way that doesn’t prevent the application from running?

Labeled tuples are effectively order-independent. Your implementation's order has to match your interface's order, but callers can destruct the labeled tuples in any order and the compiler will do the necessary reordering (just like it does for destructing records, or calling functions with labeled arguments). I don't think this is materially different from what you're describing in F#, except that labeled tuples don't allow labeling a single value (that is, there's no 1-tuple, which is also the case for normal tuples).

One reason why they're not the same is because the memory representation is different (sort of). This will break FFIs if you allow reordering the tuple arbitrarily.

Isn't that just the same as the ordinary OCaml { product = 6; sum = 5 } (with a very slightly different syntax)?

In Dart, we merged tuples and records into a single construct. A record can have positional fields, named fields, or both. A record type can appear anywhere a type annotation is allowed. So in Dart these are both fine:

    (int, int) can() => (1, 2);
    ({int sum, int product}) alsoCan() => (sum: 1, product: 2);
    (int, {int remainder}) evenThis() => (1, remainder: 2);

https://dart.dev/language/records

Hmm. Let me first check that I've understood what you care about

    struct First(this: i8, that: i64)
    struct Second(this: i8, that: i8)
    struct Third(that: i64, this: i8)
    struct Fourth(this: i8, that: i64)
    struct Fifth(some: i8, other: i64)

I see that this is different from Rust's existing product types, in which First and Fourth are always different types.

Second though, can you give me some examples where I'd want this? I can't say I have ever wished I had this, but that might be a different experience.

It's interesting that languages which start with purely nominal structs tend to acquire some form of structurally typed records in the long run. E.g. C# has always had (nominally typed) structs, then .NET added (structurally typed) tuples, and then eventually the language added (still structurally typed) tuples with named items on top of that.

PHP has it all!

I think the main dividing line here is whether you want to lean into strict typing or whether you prefer a more loose typing structure. The extremes of both (where, for instance, the length of an array is part of its type definition or there are not contractual guarantees about data) are both awful. I think the level of type strictness you desire as a product is probably best dictated by team and project size (which you'll note changes over the lifetime of the product) with a lack of typing making it much easier to prototype early code while extremely strict typing can serve as a strong code contract in a large codebase where no one person can still comprehend the entirety of it.

It's a constant push and pull of conflicting motivations.

FWIW, the "Get OxCaml" page actually says that SIMD on ARM isn't supported yet. If it actually works it would be worth removing that from the known issues list https://oxcaml.org/get-oxcaml/

Cool to hear there aren't any technical blockers to add Windows support! You just convinced me into giving OxCaml a try for a hobby project. 128-bit SSE is likely to be enough for my use case and target specs.

If you follow the installation instructions on oxcaml.org, you’ll get a patched Merlin with LSP support etc. It’s not perfect, but does mostly work out of the box with VSCode and the OCaml Platform extension.

This did actually halt my hobby programming language project, whose features overlap a lot and is advancing slowly anyway.

At the very least I'll give OxCaml a try to compare. Best case I drop mine and use this, worst case I learn what works and what doesn't.

OxCaml takes a different approach to encoding locality to Rust. Rust (arguably) overburdens the type-system with this information whilst in OxCaml this is orthogonal to the return types. In that sense it's a bit like algebraic effects. Personally I'm quite bullish on OCaml these days.

> Not seeing much of a point in this

OCaml is a good language and these extensions are very welcome to existing OCaml programmers and programs, as well as many of the other extensions Jane Street has added. I don't understand what you mean here.

what is the sunk cost fallacy in the Jane Street case?

I've never written a line of Rust in my life, but I unfortunately had the great displeasure to write OCaml.

OCaml is a terrible choice for (anyone) a company like this. They NEED to be able to hire the very best of the best, but choosing an exotic language that is less palatable than a plate of shit and more cryptic than alien hieroglyphs restricts your talent pool A LOT.

I'm not saying people cannot learn it, I'm saying people won't want to, for multiple very good reasons (it sucks, it's not at all transferable skill, etc.).

did they talked about it publicly ? i stopped following around the hiphop vm era

The implication here, I think, is that "Jane Street has foolishly invested heavily into Ocaml and, rather than sensibly change course and migrate away, they continue to invest heavily into it in the hopes that one day the investment will pay off."

Which is a ridiculous take: Jane Street has done extraordinarily well for themselves, possibly at least in part because of their investment in Ocaml, and any sort of migration would be a huge undertaking, and an absurd and unnecessary risk.