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

111–120 of 128 posts

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

#111

Post by clancon »

debugnik wrote: post #89
clancon wrote: post #83

Earlier quoted context omitted.

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.

Error squiggles and ocamlformat stopped working for me after the first time I restarted VS Code, compared to regular OCaml. They do work fine through the Dune CLI though.

Hmm. Did you install ocaml-lsp-server on the OxCaml switch? I also tend to run dune in polling mode (-w), not sure if that matters…

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

#112

Post by jlouis »

aseipp wrote: post #29
zozbot234 wrote: post #24

Earlier quoted context omitted.

> > Not seeing much of a point in this > ...I don't understand what you mean here. Yeah it seems there was a mistake there, it looks like my comment got cut off while you were reading it. Try reloading the page maybe?

Your comment remains completely stupid regardless of how much of it is in the quote. OxCaml's goal is to be upstreamed. "I don't see the point in this unless people have programs using OCaml" and it's like, yeah, that's the point of adding features to a computer program. Any computer program. Because people already use the computer program and it will be useful to them.

Everything I see in OxCaml are things where I go: this would be nice to have in Ocaml.

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

#113

Post by thedufer »

munchler wrote: post #34
legobmw99 wrote: post #2

The first feature that originated in this fork to be upstreamed is labeled tuples, which will be in OCaml 5.4: https://github.com/ocaml/ocaml/pull/13498 https://discuss.ocaml.org/t/first-alpha-release-of-ocaml-5-4...

> Because sum:int * product:int is a different type from product:int * sum:int, the use of a labeled tuple in this example prevents us from accidentally returning the pair in the wrong order, or mixing up the order of the initial values. Hmm, I think I like F#'s anonymous records better than this. For example, {| product = 6; sum = 5 |}. The order of the fields doesn't matter, since the value is not a tuple.

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).

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

#114

Post by wk_end »

debugnik wrote: post #92
wk_end wrote: post #74

Earlier quoted context omitted.

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.

I dunno. Jane Street started using OCaml back in 2002. Consider the world of programming languages back then: no Rust, of course...but, like Java wouldn't even have generics for another two years! At the time - and for a long time after - OCaml's offering of power/performance was pretty unbeatable. It arguably still is, but I think there's at least an argument these days. I'm not sure exactly when that argument became viable, but it would've been long-after Jane Street had already built up a pretty huge codebase and a pretty crack team of OCaml engineers.

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

#115

Post by Barrin92 »

iLoveOncall wrote: post #107
phplovesong wrote: post #102

Earlier quoted context omitted.

Why? They have one of the largest Ocaml codebases in the world. It has clearly work out VERY well for them, in terms of productivity and pure ROI in features and revenue. Ocaml has so much good going on, even being a less known language. I assume you are a rust fanboy, and i want to see just how long your smirk holds when you compile a 20M LOC project that takes 45 minutes.

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

>They NEED to be able to hire the very best of the best,

This is literally why they've chosen Ocaml. Yaron Minsky has often stated that interest in a language like this is effectively a filter and magnet for extremely smart and curious people, he credits Ocaml with being an advantage in that regard.

They don't care about transferable skills either. People at Jane Street earn hundreds of thousands per year starting out, virtually nobody ever leaves, you're set for life after a decade there.

Aso Ocaml is a pretty standard ML. If you think it's unreadable alien hieroglyphs its fair to say you're not the demographic they're trying to attract, so the system is working.

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

#116

Post by mustache_kimono »

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…

I actually asked Ron Minsky about exactly this question on Twitter[0]:

    Me: [W]hy not just use Rust for latency sensitive apps/where it may make sense?  Is JS using any Rust?

    Minsky: Rust is great, but we get a lot of value out of having the bulk of our code in a single language. We can share types, tools, libraries, idioms, and it makes it easier for folk to move from project to project.

    And we're well on our way to getting the most important advantages that Rust brings to the table in OCaml in a cleanly integrated, pay as you go way, which seems to us like a better outcome.

    There are also some things that we specifically don't love about Rust: the compile times are long, folk who know more about it than I do are pretty sad about how async/await works, the type discipline is quite complicated, etc.

    But mostly, it's about wanting to have one wider-spectrum language at our disposal.
[0]: https://x.com/arr_ohh_bee/status/1672224986638032897

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

#117

Post by munificent »

afiori wrote: post #106
munificent wrote: post #70

Earlier quoted context omitted.

The syntax is a little funny for mostly historical reasons. The curly braces are only part of the record type syntax. There's no ambiguity there because curly braces aren't used for anything else in type annotations (well, except for named parameters inside a function type's parameter list, but that's a different part of the grammar).

so my examples would be (1, (sum:2)) and (1, sum:2)?

Yes, exactly.

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

#118

Post by aguluman »

TheNumbat wrote: post #16
debugnik wrote: post #11

I wasn't aware that this fork supported SIMD! Between this, unboxed types and the local mode with explicit stack allocation, OxCaml almost entirely replaces my past interest in F#; this could actually become usable for gamedev and similar consumer scenarios if it also supported Windows.

Yeah, this would be great! Currently only 128-bit SSE/NEON is working but AVX is coming very soon. There's also nothing blocking Windows, but it will require some work. (I added the SIMD support in OxCaml)

This is so cool.

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

#119

Post by aguluman »

Barrin92 wrote: post #115
iLoveOncall wrote: post #107

Earlier quoted context omitted.

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

>They NEED to be able to hire the very best of the best, This is literally why they've chosen Ocaml. Yaron Minsky has often stated that interest in a language like this is effectively a filter and magnet for extremely smart and curious people, he credits Ocaml with being an advantage in that regard. They don't care about transferable skills either. People at Jane Street earn hundreds of thousands per year starting ou…

Well said mate. Couldn't have said it any better.

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

#120

Post by CyberDildonics »

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?

No, compared to not doing so many allocations that freeing them is time consuming or expensive. Having allocations slow a program down means that there are way too many, probably due to being too granular and being in a hot loop. On top of that it means everything is a pointer and that lack of locality will slow things down even further. The difference between allocating many millions of objects and chasing their pointers and doing a single allocation of a vector and running through that can easily be 100x faster.
Post reply on HN