[HN Gopher] OxCaml - a set of extensions to the OCaml programmin...
___________________________________________________________________
OxCaml - a set of extensions to the OCaml programming language.
Author : lairv
Score : 298 points
Date : 2025-06-13 14:20 UTC (1 days ago)
(HTM) web link (oxcaml.org)
(TXT) w3m dump (oxcaml.org)
| legobmw99 wrote:
| 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...
| debugnik wrote:
| Immutable arrays were ported from this fork as well, and merged
| for 5.4; although with different syntax I think.
| andrepd wrote:
| Anonymous labeled structs and enums are some of my top wished-
| for features in programming languages! For instance, in Rust
| you can define labelled and unlabelled (i.e. tuple) structs
| struct Foo(i32, i32); struct Bar{sum: i32, product:
| i32}
|
| But you can only e.g. return from functions an anonymous tuple,
| not an anonymous labelled struct fn can() ->
| (i32, i32) fn cant() -> {sum: i32, product: i32}
| tialaramex wrote:
| 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)
|
| You want First and Fourth as the same type, but Second and
| Third are different - how about Fifth?
|
| 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.
| cAtte_ wrote:
| they're not asking for a structural typing overhaul, just a
| way to make ad-hoc anonymous types with named fields and
| pass them around. a lot of times with tuple return types
| you're left wondering what that random `usize` is supposed
| to represent, so having names for it would be very
| convenient. i don't see why, under the hood, it couldn't
| just be implemented the exact same way as current tuple
| return types
| zozbot234 wrote:
| > they're not asking for a structural typing overhaul,
| just a way to make ad-hoc anonymous types with named
| fields and pass them around.
|
| And their point is that the two boil down to the same
| thing, especially in a non-trivial program. If switching
| field positions around changes their semantics, tuples
| may well the most sensible choice. As for "what that
| random usize is supposed to represent" that's something
| that can be addressed with in-code documentation, which
| Rust has great support for.
| tialaramex wrote:
| Also, if it's _not_ just a "random usize" then you
| should use the new type paradigm. In a language like Rust
| that's not _quite_ as smooth as it could possibly be, but
| it 's transparent to the machine code. Rust's
| Option<OwnedFd> is the same _machine code_ as C 's int
| file descriptor, but the same _ergonomics_ as a fancy
| Haskell type. We can 't accidentally confuse "None, there
| isn't a file descriptor" for an actual file descriptor as
| we so easily could in C, nor can we mistakenly do
| arithmetic with file descriptors - which is nonsense but
| would work (hilarity ensues) in C.
|
| If these aren't "random" usizes but FileSizes or
| ColumnNumbers or SocketTimeouts then say so and the
| confusion is eliminated.
| munificent wrote:
| 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);
|
| The curly braces in the record type annotation distinguish
| the named fields from the positional ones. I don't love the
| syntax, but it's consistent with function parameter lists
| where the curly braces delimit the named parameters.
|
| https://dart.dev/language/records
| afiori wrote:
| How do you distinguish a tuple with both positional and
| named fields from a tuple that has a record as a field
|
| Like how do you write the type of (1, {sum:2}) ? Is it
| different from (1 , sum :2)?
| munificent wrote:
| 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).
| afiori wrote:
| so my examples would be (1, (sum:2)) and (1, sum:2)?
| munificent wrote:
| Yes, exactly.
| int_19h wrote:
| 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.
| munk-a wrote:
| 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.
| aseipp wrote:
| Yeah, pretty excited about this one even though it seems minor.
| A paper and talk by the author of this particular feature from
| ML2024, too:
|
| - https://www.youtube.com/watch?v=WM7ZVne8eQE
|
| - https://tyconmismatch.com/papers/ml2024_labeled_tuples.pdf
| munchler wrote:
| > 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.
| rwmj wrote:
| Isn't that just the same as the ordinary OCaml { product = 6;
| sum = 5 } (with a very slightly different syntax)?
| munchler wrote:
| The difference between { ... } and {| ... |} is that the
| latter's type is anonymous, so it doesn't have to be
| declared ahead of time.
| rwmj wrote:
| Oh I see, good point. I'm wondering how this is
| represented internally. Fields alphabetically? I've also
| desired _extensible_ anonymous structs (with defaults)
| from time to time, but implementing that would involve
| some kind of global analysis I suppose.
| reycharles wrote:
| 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.
| thedufer wrote:
| 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).
| IshKebab wrote:
| So this is "oxidized" because it tries to achieve the same
| features as Rust (e.g. "fearless concurrency" is mentioned, and
| avoiding GC)... Not because it actually uses Rust in any way
| right? Slightly confusing.
| debugnik wrote:
| Correct, Jane Street has been publishing a series of blog posts
| titled "Oxidizing OCaml" for a while.
| zozbot234 wrote:
| Rust will probably become usable with custom tracing GCs (which
| is helpful if you're dealing with general graph-like data but
| still want the highest performance as far as practical) way
| before this effort reaches genuine feature parity with Rust.
| Not seeing much of a point in this, unless they perhaps intend
| to focus on the lowest-hanging fruit and have big O(x)Caml
| codebases that they care about.
| greener_grass wrote:
| 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.
| aseipp wrote:
| > 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.
| zozbot234 wrote:
| > > 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?
| aseipp wrote:
| 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.
| jlouis wrote:
| Everything I see in OxCaml are things where I go: this
| would be nice to have in Ocaml.
| aseipp wrote:
| Yes, they've used this terminology for a while, even the recent
| technical paper on this effort was titled "Oxidizing OCaml with
| Modal Memory Management", though the word "oxidize" itself is
| never actually referenced or defined in the paper. A bit
| strange, I agree, though it's kind of catchy I admit.
| john-h-k wrote:
| It's ironic of course because Rust (the language) is named
| after the fungus called Rust, rather than iron-oxide
| avsm wrote:
| If anyone's trying out the new opam switch, I found it helpful to
| use:
|
| env OCAMLPARAM="alert=-unsafe_multidomain,_," opam install
| cohttp-lwt-unix
|
| Because alerts are promoted to errors, they break existing
| package installs unnecessarily. The OCAMLPARAM environment
| variable just forces that alert to be disabled and allows the
| package installation to continue.
| Lyngbakr wrote:
| 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/performance-engineering-on-
| har...
| enricozb wrote:
| Haven't looked at the link, but I think for a scenario like
| trading where there are market open and close times, you can
| just disable the GC, and restart the program after market
| close.
| spooneybarger wrote:
| It is a common strategy.
| rauljara wrote:
| GC compactions were indeed a problem for a number of systems.
| The trading systems in general had a policy of not allocating
| after startup. JS has a library, called "Zero" that provides a
| host of non-allocating ways of doing things.
| jitl wrote:
| Couldn't find this after 6 seconds of googling, link?
| jallmann wrote:
| The linked podcast episode mentions it.
| notnullorvoid wrote:
| There's no mention of a library called zero, or even
| JavaScript.
| garbthetill wrote:
| Im assuming the JS refers to Janes street
| notnullorvoid wrote:
| That makes sense, I guess I've got web tunnel vision.
| sheepscreek wrote:
| 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.
| debugnik wrote:
| 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).
| jallmann wrote:
| > This is what I like to call a dialect of OCaml. We
| speak in sometimes and sometimes we gently say it's zero
| alloc OCaml. And the most notable thing about it, it
| tries to avoid touching the garbage collector ...
| mardifoufs wrote:
| You just let the garbage accumulate and collect it whenever
| markets are closed. In most cases, whenever you need ultra low
| latency in trading, you usually have very well defined time
| constraints (market open/close).
|
| Maybe it's different for markets that are always open (crypto?)
| but most HFT happens during regular market hours.
| dmkolobov wrote:
| Is that really a viable solution for a timeframe of 6+ hours?
| logicchains wrote:
| You can just add more RAM until it is viable.
| jitl wrote:
| Sure, if you know how much you allocate per minute (and
| don't exceed your budget) you just buy enough RAM and it's
| fine.
| mayoff wrote:
| (this comment was off topic, sorry)
| robertlagrant wrote:
| Is this relevant to OCaml?
| mayoff wrote:
| ha ha oops I got confused
| ackfoobar wrote:
| This will decrease performance because of reduced
| locality. Maybe increased jitter because of TLB misses.
| jitl wrote:
| Compared to what, running a garbage collector?
| dmkolobov wrote:
| 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.
| spooneybarger wrote:
| Yes. It is a very common design pattern within banks for
| systems that only need to run during market hours.
| iainctduncan wrote:
| I talk about doing this in an audio context and get met
| with raised eyebrows, I'd love some references on others
| doing it, if anyone can share!
| mardifoufs wrote:
| I think it is, but to be clear I think (from my very
| limited experience, just a couple of years before leaving
| finance, and the people with more experience that I've
| talked with) that c++ is still a lot more common than any
| GC language (typically java, since OCaml is even rarer). So
| it is possible, and some firms seem to take that approach,
| but I'm not sure exactly how besides turning off GC or very
| specific GC tuning.
|
| Here is a JVM project I saw a few years back, I'm not sure
| how successful the creators are but they seem to use it in
| actual production. It's super rare to get even a glimpse at
| HFT infra from the outside so it's still useful.
|
| https://github.com/OpenHFT
| amw-zero wrote:
| 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?
| great_wubwub wrote:
| *Jane Street
| esafak wrote:
| It's a great name for a competitor :)
| AdieuToLogic wrote:
| > 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 not provide hard guarantees however, so over-
| provisioning system RAM may also be needed in order to achieve
| required system performance.
|
| Another more complex approach is to over-provision the servers
| such that each can drop out of the available pool for a short
| time, thus allowing "offline GC." This involves collaboration
| between request routers and other servers, so may not be worth
| the effort if a deployment can financially support over-
| provisioning servers such that there is always an idle CPU
| available for parallel GC on each.
|
| 0 -
| https://docs.oracle.com/en/java/javase/17/gctuning/parallel-...
| pjmlp wrote:
| 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.
| pjmlp wrote:
| 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.
| jaennaet wrote:
| 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
| pjmlp wrote:
| The knobs aren't on the GC necessarily, rather language
| features.
|
| With a Go compiler toolchain you have stack and global
| memory static allocation, use of compiler flags to track
| down when references escape, manually allocate via OS
| bindings, there is the unsafe package, and use slices with
| it, an assembler is part of the toolchain learn to use it,
| and regardless of CGO is not Go memes, it is another tool
| to reach for if Assembly isn't your thing.
| jaennaet wrote:
| Ohh right yes, now I get what you mean. My brain just
| immediately went for "GC knobs" when you mentioned
| "knobs", but in my defense I'm running a 40degC fever so
| I should probably not be commenting at all
| pjmlp wrote:
| All the best and get well.
| mustache_kimono wrote:
| 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
| debugnik wrote:
| 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.
| TheNumbat wrote:
| 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)
| aseipp wrote:
| 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/
| TheNumbat wrote:
| Indeed, it says that because we don't have a library of
| NEON intrinsics (like ocaml_simd_sse) yet, but the
| extension itself works.
| aseipp wrote:
| Ah, that clears it up a bit. Thanks! Looking forward to
| all of this. (For the interested readers, here's the SSE
| library:
| https://github.com/janestreet/ocaml_simd/tree/with-
| extension...)
| debugnik wrote:
| 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.
| avsm wrote:
| David Allsopp had an oxcaml branch compiling on Windows a
| few months ago, so it's in the queue...
| aguluman wrote:
| This is so cool.
| croes wrote:
| So OxCaml is the extension of the extension of a dialect of ML.
|
| Can't wait for the next level
| munchler wrote:
| Can I interest you in F#?
| jasperry wrote:
| 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.
| debugnik wrote:
| 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.
| anthk wrote:
| OcaML's micro cousin:
|
| http://t3x.org/mlite/index.html
| iLoveOncall wrote:
| The sunk cost fallacy at Jane Street is strong.
| ackfoobar wrote:
| Maybe it's sunk cost fallacy for them. But without them there
| wouldn't be a language that gets me 80/20 benefit/effort of
| Rust.
| fuzztester wrote:
| what is the sunk cost fallacy in the Jane Street case?
| ackfoobar wrote:
| I said "maybe" as granting the root comment's premise - I
| don't believe that.
| abathologist wrote:
| What are you talking about?
| wk_end wrote:
| 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.
| abathologist wrote:
| Ah yeah, that is absurd, given how successful they have
| been, and how much they attribute that success to their
| technical decisions.
|
| People love to sulk in their parochial pits, I guess?
|
| Thanks for clarifying :)
| ng12 wrote:
| Maybe Jane Street succeeds because of the people who are
| good at finance in spite of the people who like OCaml.
| debugnik wrote:
| 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.
| wk_end wrote:
| 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.
| umanwizard wrote:
| Wait til you hear about PHP at Meta...
| agumonkey wrote:
| did they talked about it publicly ? i stopped following
| around the hiphop vm era
| toolslive wrote:
| You can also argue it's "Stockholm syndrome". Anyway,it's funny
| how opinions differ: I still consider Rust to be a poor man's
| OCaml.
| phplovesong wrote:
| 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.
| iLoveOncall wrote:
| 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.).
| phplovesong wrote:
| Thats BS. I have learnt Ocaml and im far from "the best if
| the best". Its just syntax in the end, took me a few weeks
| to get productive enough to ship features.
|
| Rust on the other hand, takes usually way longer to grok,
| mostly because of its borrow checker that is quite unique
| to rust.
| iLoveOncall wrote:
| This is not at all what I said. At least we can agree on
| the fact that you're far from being the best of the best
| with that reading comprehension...
| Barrin92 wrote:
| >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.
| aguluman wrote:
| Well said mate. Couldn't have said it any better.
| dingdingdang wrote:
| Probably spoilt here but being used to the excellent vscode
| plugin (well vscodium in my case) for Golang but... any plans to
| integrate with vscode ecosystem? Makes setup so straightforward!
| jasperry wrote:
| The OCaml vscode plugin seems to have already integrated a lot
| of new syntaxes (dune, menhir, reason), so if OxCaml gains
| traction it should only be a matter of time.
|
| (can't really speak for that myself, though, I use emacs)
| clancon wrote:
| 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.
| debugnik wrote:
| 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.
| clancon wrote:
| 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...
| bhamta wrote:
| 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?
| debugnik wrote:
| 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.
| jdiff wrote:
| Not good at all. It's not a strong enough signal. For instance,
| LLMs are absolute dogshit at completing Gleam, even if given
| files with the exact pattern they need to mimic just lines
| away, or given explicit instructions on common mistakes it
| makes.
| reverseblade2 wrote:
| Just use F# for sake
| debugnik wrote:
| 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.
| reverseblade2 wrote:
| F# is mostly liberated from .net thanks to Fable. Although
| the compiler strictly is .net
| debugnik wrote:
| 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#.
___________________________________________________________________
(page generated 2025-06-14 23:01 UTC)