Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

oxcaml.org

Post reply on HN
Print view View original

91–100 of 128 posts

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

#91

Post by debugnik »

jasperry wrote: post #76
croes wrote: post #12

So OxCaml is the extension of the extension of a dialect of ML. Can’t wait for the next level

I had a similar thought to this, but then I thought, who is worse: programmers who keep bloating up existing languages with new features, or programmers who create yet another new language to add to the already crowded field? (I'm in that latter category.) I guess programmers are just genetically incapable of leaving their tools the way they are.

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.

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

#92

Post by debugnik »

wk_end wrote: post #74
abathologist wrote: post #59

Earlier quoted context omitted.

What are you talking about?

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 migrat…

I do think Jane Street fell into a sunk cost fallacy when they first stuck to OCaml. But after having invested further into an OCaml/OxCaml codebase, teams and tooling, switching tech stacks has lost most of its value.

Also, their efforts benefit me greatly as an OCaml (now maybe OxCaml) user, so I'm glad they took that path.

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

#93

Post by pjmlp »

Lyngbakr wrote: post #7

The Janet Street folks, who created this, also did an interesting episode[0] of their podcast where they discuss performance considerations when working with OCaml. What I was curious about was applying a GC language to a use case that must have extremely low latency. It seems like an important consideration, as a GC pause in the middle of high-frequency trading could be problematic. [0] https://signalsandthreads.com…

The problem is not a GC language per se, people keep putting all GC languages in the same basket.

The real issue is being a GC language, without support for explicit manipulation of stack and value types.

Want a GC language, with productivity of GC languages, with the knobs to do low level systems coding?

Cedar, Oberon language family, Modula-3, D, Nim, Eiffel, C#, F#, Swift, Go.

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

#94

Post by pjmlp »

AdieuToLogic wrote: post #85
Lyngbakr wrote: post #7

The Janet Street folks, who created this, also did an interesting episode[0] of their podcast where they discuss performance considerations when working with OCaml. What I was curious about was applying a GC language to a use case that must have extremely low latency. It seems like an important consideration, as a GC pause in the middle of high-frequency trading could be problematic. [0] https://signalsandthreads.com…

> What I was curious about was applying a GC language to a use case that must have extremely low latency. It seems like an important consideration, as a GC pause in the middle of high-frequency trading could be problematic. Regarding a run-time environment using garbage collection in general, not OCaml specifically, GC pauses can be minimized with parallel collection algorithms such as found in the JVM[0]. They do no…

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.

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

#95

Post by dmkolobov »

jitl wrote: post #81
ackfoobar wrote: post #50

Earlier quoted context omitted.

This will decrease performance because of reduced locality. Maybe increased jitter because of TLB misses.

Compared to what, running a garbage collector?

Probably? Locality becomes fairly important at scale. That’s why there’s a strong preference for array-based data structures in high-performance code.

If I was them I’d be using OCaml to build up functional “kernels” which could be run in a way that requires zero allocation. Then you dispatch requests to these kernels and let the fast modern generational GC clean up the minor cost of dispatching: most of the work happens in the zero-allocation kernels.

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

#96

Post by reverseblade2 »

debugnik wrote: post #90
reverseblade2 wrote: post #87

Just use F# for sake

I actually see this as an escape opportunity for F#-ers. I love the language, but the runtime and C# ecosystem are not only holding it back from having cleaner semantics (until the C# team sees the value in them), they've been actively kicking it down the ladder with breaking changes and new incompatible APIs.

F# is mostly liberated from .net thanks to Fable. Although the compiler strictly is .net

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

#98

Post by debugnik »

sheepscreek wrote: post #82
notnullorvoid wrote: post #71

Earlier quoted context omitted.

That makes sense, I guess I've got web tunnel vision.

I was bit by the same spider that gave you web tunnel vision. In any case, I find OCaml too esoteric for my taste. F# is softer and feels more..modern perhaps? But I don’t think GC can be avoided in dotnet.

You can avoid GC in hot loops in F# with value-types, explicit inlining, and mutability.

Mutability may not result in very idiomatic code however, although it can often be wrapped with a functional API (e.g. parser combinators).

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

#99

Post by debugnik »

bhamta wrote: post #86

What are the chances that they are releasing this so that LLMs can index this information for free and they can use public models in their codebase rather than finetuning public models?

Given how poor LLMs are at regular OCaml, which has so much more training data that OxCaml, probably none. An MCP for docs would have been more productive for that purpose.

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

#100

Post by debugnik »

reverseblade2 wrote: post #96
debugnik wrote: post #90

Earlier quoted context omitted.

I actually see this as an escape opportunity for F#-ers. I love the language, but the runtime and C# ecosystem are not only holding it back from having cleaner semantics (until the C# team sees the value in them), they've been actively kicking it down the ladder with breaking changes and new incompatible APIs.

F# is mostly liberated from .net thanks to Fable. Although the compiler strictly is .net

Fable is the complete opposite direction to .NET and OxCaml, though. Nice for people doing web I guess (I'd rather do TypeScript than deal with interop), but the JS runtime and ecosystem are pretty much useless for my use cases.

Maybe a pure WASM target could actually liberate F#.

Post reply on HN