5 ms·

Pain Points of OCaml

58 points by quamserena 11mo ago

Hendrikto 11mo ago
> Usually partial function application is a bug Dude, what?
- jlouis 11mo ago
  It's my favorite line of the whole thing. There's so much which can be derived from that single statement.
- dan-robertson 11mo ago
  I think this is true. It can be easy to accidentally do partial application, especially with optional and labelled arguments, eg: let bar x y z = … let foo w x = bar x (f w x) The performance and evaluation order can be a bit surprising in this case, and the errors when updating bar can be hard to understand.
- quamserena 11mo ago
  I would rather have partial function application be explicit rather than just omitting args because right now if you accidentally forget an argument (a bug) it isn’t an error there and instead becomes a type error somewhere else.
StepBroBD 11mo ago
For printing, there’s show in ppx_deriving [1], and I think ppx in general had made my overall experience with OCaml a lot better. [1] https://github.com/ocaml-ppx/ppx_deriving https://github.com/ocaml-ppx/ppx_deriving
rwmj 11mo ago
As an engineer writing OCaml (and Rust too), I don't find any of this stuff to be a pain point. The syntax is fine once you get used to it. Anecdotally one of my colleagues who is learning OCaml and contributing to the code is using an AI to help get the syntax right and that works for him. Types in Rust are way more complicated and obscure than the ones in OCaml. The ecosystem stays out of the way as much as possible - we are mainly interested in interfacing with C code directly, and OCaml (and Rust) make that pretty easy. I've been writing this project for over a decade and the language has been reasonably stable (OCaml 5 made some changes to the C interface, but we coped). Rust actually causes far more code churn - there's virtually a monthly cycle of some Rust compiler update requiring changes to existing code.
- simonask 11mo ago
  > Rust actually causes far more code churn - there's virtually a monthly cycle of some Rust compiler update requiring changes to existing code. This is really surprising to me. Which changes have you had to deal with here? The only one I can think of is the major Edition 2024 upgrade, which changed the `#[no_mangle]` attribute to `#[unsafe(no_mangle)]`. But the old syntax still compiles just fine with the newest compiler using Edition 2021.
  - quamserena 11mo ago
    I am surprised by this too. I wonder what OP is writing in Rust that requires monthly changes?
  - rwmj 11mo ago
    I guess it's because we use clippy to lint all the Rust code, combined with always pulling the latest Rust compiler (from Fedora Rawhide). But it's a real thing, there's a lot of churn. The good thing is clippy / rustc has very good diagnostics and usually tells you "do X to fix this".
    - quamserena 11mo ago
      I wish OCaml had more helpful error messages like these, right now it feels like I’m on my own solving some of the more inscrutable errors.
    - whytevuhuni 11mo ago
      I think what clippy needs the most is a way to say, "make all clippy warnings as errors, but only for warnings up to Rust 1.80". And then devs can update that number whenever they want, as opposed to whenever new updates come in. Or tie it to the current edition, or the current MSRV if defined.
    - simonask 11mo ago
      I think it’s pretty unfair to characterize new, helpful lints as “breaking changes”. There’s plenty of options to not have to deal with that (unless you want to of course).
anthk 11mo ago
On ML languages, you can try MLite first (it comes with a great manual and a paper too); and then you can jump into the biggies such as OCaML and maybe Haskell too: https://t3x.org/mlite/index.html https://t3x.org/mlite/index.html
- user____name 11mo ago
  I like the apology page.
jpfromlondon 11mo ago
Ocaml is one of the few languages I think you either really like or really don't.
- lucas_membrane 11mo ago
  Not for me. I spent a few weeks a few weeks ago trying to use it. Much I liked. Much I didn't. I like FP, so that was not a problem. But I found that lots of stuff was pretty hard for me as just an old guy trying to write some fancy little GUI apps to assist some of my other spare time activities. The project system, dune, was puzzling to me, and when I looked for clarification on-line it was pretty clear that I had lots of company. Not wanting to pass time writing code and seeing many potentialy useful packages available, I downloaded quite a few (actually, I downloaded not too many, but the dependencies required for those multiplied rapidly). Then I found myself managing multiple environments, because the different versions of this and that do not always work together so nice. Some library code has to get imported some ways, some other ways. Etc, etc. Many tutorials teach the toplevel interpreter, but that's not recommended for projects of any size, and the other environments will choke on the code that works in the toplevel. What I liked is that the OCaml ecosystem doen't look like it wants to control or ought to fear the next big thing. It's what you get when you have a lot of smart creative people who get inspired and do their best according to their own motivations and their own conception of quality. I admire that. I'm glad that I tried it.
pjmlp 11mo ago
Having learnt ML via Caml Light, back when OCaml was still going to be the next version, and known by its full name Objective Caml, I never considered any of that a pain point.
_flux 11mo ago
The article mentions that global type inference is painful, and Rust made the right call by requiring annotations, but actually I think the OCaml model is closer to the optimum: you can still annotate functions and perhaps you should (in fact the interface files are in my view great, but not everyone enjoys them), but the key benefit is that you can also use holes in such definitions, e.g. _ option list is usually quite descriptive of what data you have, but still doesn't go into some detail you don't want to (sadly "int _ list" isn't supported by the type system). The types in Rust can sometimes get quite long, in particular if you want to avoid boxing and you're dealing with futures.
- GCUMstlyHarmls 11mo ago
  I imagine there's as sweet spot between type inference, an LSP "add type annotations" action and a "function missing annotations" warning option. Smooth out the exploratory stage, flip to "strict" with one button and a way to enforce "strict" mode.
  - quamserena 11mo ago
    I actually find that annotated parameters and return types help me during the exploratory stage too otherwise I invariably end up making a typeerror somewhere and the errors aren’t helpful (the error shows up in the wrong spot, or the function mysteriously changes type)
- quamserena 11mo ago
  I second the point that Rust types can get quite long. I usually use aliases where I can but that isn’t always possible. I think that sometimes people use boxing just to avoid these long types even if the code in theory doesn’t require an allocation
user____name 11mo ago
Reminded me of this comparison between Ocaml and Sml with regards to the purity vs practicality. [0] The complaint about syntax is amusing, I get a bit annoyed when I see Rust syntax being inserted into Java/C-ish languages. [0] http://adam.chlipala.net/mlcomp/ http://adam.chlipala.net/mlcomp/
sshine 11mo ago
Standard ML was my favorite language 2008-2012, and whenever people criticize the syntax, I shake my head. ML syntax is among the most beautiful, and most readable, to me. OCaml has a few features that bring the readability down a little, like the named fields prefix. The fact that it doesn't look like C or Ruby isn't bad. Erlang can be very readable, it just feels alien, which I presume is what people don't like. The big downside is the paradigm shift + inscrutable error messages. It will make you feel dumb and/or unproductive for a very long time. A lot of the type errors can be fixed by a compiler that cares more about error messages, and OCaml in particular could do well with terminators after e.g. match blocks to improve both ambiguity and error reporting. Some of the type errors can't easily be fixed; wrong function application by omitting some value somewhere has, so far, always led to misleading errors; are there any other examples than Elm that address these? I also switched from ML to Haskell to Rust. To me, the main downside of ML is the explicitly instantiated module systems not tied to the filesystem hierarchy. Once you get used to traits and parameterised trait instances, bringing every module instantiation into scope after separately importing them is just slooow. The standard library situation is also somewhat not great. Maybe I just never got used to it, but I sense that there are people think Jane Street Base is a must, and people who think it's completely overkill. OCaml programmers have a weird fetish with micro-optimization because the compiler lets you think about the asm output. It's a remarkable property of an otherwise high-level language that you can really care about the asm output.
- StopDisinfo910 11mo ago
  > OCaml in particular could do well with terminators after e.g. match blocks to improve both ambiguity and error reporting You can use either begin/end or parentheses as terminators around any blocks of Ocaml for exactly that purpose. > To me, the main downside of ML is the explicitly instantiated module systems not tied to the filesystem hierarchy. That's one of the greatest strenght of ML actually and especially Ocaml where parametrised modules are everywhere and a required building block of generic code. A significant part of why the article complains about type for exemple is because the author doesn't know how to use the module system. > Once you get used to traits and parameterised trait instances I like modules a lot more. It makes the code a lot clearer than traits. > The standard library situation is also somewhat not great. Maybe I just never got used to it, but I sense that there are people think Jane Street Base is a must The standard library is a lot more complete nowadays that it was some years ago and Base is used by pretty much nobody outside of JaneStreet.
ernst_klim 11mo ago
> there is no equivalent to Java's toString or Rust's #[derive(Debug)] There are devivers and a Format module for pretty printing. https://github.com/ocaml-ppx/ppx_deriving https://github.com/ocaml-ppx/ppx_deriving https://ocaml.org/manual/5.4/api/Format.html https://ocaml.org/manual/5.4/api/Format.html
- quamserena 11mo ago
  I am aware of this, but afaik it’s an external library? https://github.com/thierry-martinez/ppx_show https://github.com/thierry-martinez/ppx_show
  - ernst_klim 11mo ago
    Format is part of OCaml stdlib. You can write formatters for it manually. Derivers are a library yes, it's pretty widespread if you need derive functionality, and it can derive basic functions. Proper link: https://github.com/ocaml-ppx/ppx_deriving?tab=readme-ov-file#plugin-show https://github.com/ocaml-ppx/ppx_deriving?tab=readme-ov-file...
  - yawaramin 11mo ago
    Re: the 'external lubrary' criticism. In Rust everybody says just use serde for serializing data and anyhow for error handling. But suddenly when we say use a ppx deriver in OCaml for effectively the same thing–serializing a type to a string–it's a huge problem. That's weird to me.
    - quamserena 11mo ago
      I’m not a fan of serde either. I wish there was a way to have foreign derives (or even better: compile-time reflection). There wasn’t a great way to serialize things in Rust in the standard library and the ecosystem crystalized around serde, which is suboptimal imo. There are libraries like facet[0] that implement general reflection, rather than just a subset of it, but it probably won't be supported by all of your dependencies. [0] https://github.com/facet-rs/facet https://github.com/facet-rs/facet
sanskarix 11mo ago
what's always wild to me about these language debates is how much energy people spend defending syntax preferences instead of asking "does this help me ship?" OCaml's real pain point isn't the syntax - it's that you can't hire for it. if you're building a startup and you pick OCaml, you've just cut your hiring pool by 95%. that's way more painful than learning a different way to write functions. the whole "academic vs practical" thing is backwards. academic languages often have killer features that would save you real pain, but if your team can't debug it or you can't find Stack Overflow answers at 2am, none of that matters. language choice is a business decision, not a technical purity contest.
- yodsanklai 11mo ago
  > if you're building a startup and you pick OCaml, you've just cut your hiring pool by 95%. that's way more painful than learning a different way to write functions. You can hire anyone who already understands pattern matching, closures, map/fold (these are more and more common constructs nowadays) and train them to learn OCaml. It's a simple language overall, especially if your codebase doesn't use any complicated features.
- hocuspocus 11mo ago
  > OCaml's real pain point isn't the syntax - it's that you can't hire for it. if you're building a startup and you pick OCaml, you've just cut your hiring pool by 95%. that's way more painful than learning a different way to write functions. I hear this a lot about Scala and it's never been an issue in practice. A smaller pool of candidates makes hiring easier, I'd much rather screen 20 résumés than 400. The typical candidate, whether experienced or willing to learn, is also better on average. "We can't find qualified developers" usually tells more about the employer, in reality that means: - We aren't willing to pay market rates. - We don't invest in even the most basic on-the-job training. - Seniority distribution is junior heavy; we expect one senior developer per team who can mentor all the other ones. Or a combination of the above. I know two relatively small companies that use OCaml, they don't pay anywhere near Jane Street salaries, but they're willing to hire people who show interest in the language and invest a little in their training. This works. On my end I've hired several people coming almost purely from Python, after a few weeks they contribute to fairly advanced Scala codebases.
okhobb 11mo ago
My favorite part about Ocaml is the type checker fwiw. Pretty much as soon as I appease it I'm guaranteed a 'working' program that usually does what I intended.
- quamserena 11mo ago
  My problem is that when you’re trying to appease it the errors it spits out can be confusing or in the wrong place
adamchol 11mo ago
I've been writing OCaml for quite some time now and I don't think any of those "pain points" are "pain" or really any problem with the language. I think they're more like a preference. The syntax or no forward references are just decisions that makes the language good in some ways and bad in others, and seems like you just really don't like the cons. Also, isn't freedom of annotating a function a good thing, instead of having a requirement on it? You can just explicitly annotate some stuff when you have a type error that doesn't feel right! OCaml is way more simple from the type system perspective than Rust, I think it makes it great when you need a lot of iteration on you code. One thing I do agree on are problems with the ecosystem. Maybe not quite in the specific area described here but man we got some problems in IO/concurrency/asynchrony space. Making a GOOD standard for it would just improve all our lives as OCaml developers.
myaccountonhn 11mo ago
I employ some strategies when I work with OCaml to avoid some of these pain points: I avoid libraries with poor documentation, funky types, and preprocessors that don't throw proper error messages. So I skip ocamllex, Menhir and Reasonml because I've found like OP that the DX is too poor.. But otherwise I don't particularly agree with OPs pain points. I personally find OCaml's syntax to be great. Very easy to write and read once you're used to it. And I previously thought that it's very important to annotate all types, as it would help with my thinking, but these days I find I'm more productive when I write out the code without types, maybe add a type here and there. I only annotate if OCaml's deduced type is too complex or generic.
- quamserena 11mo ago
  Maybe it’ll grow on me as I get used to it :) but e.g. I was really confused about a nonsense error in a match statement until I realized that it was because of a nested match statement. If you don’t use ocamllex/Menhir, what do you use for parsing & compiling?
  - yawaramin 11mo ago
    > I was really confused about a nonsense error in a match statement until I realized that it was because of a nested match statement. This kind of confusion instantly goes away when you use auto-formatting with ocamlformat, which is the recommended formatting tool for the OCaml platform. It would line up your match cases in such a way that you would be able to almost immediately tell that the compiler is interpreting the dangling cases as part of the inner match.
- Taikonerd 11mo ago
  Is the DX of ReasonML poor? (I haven't used it.) If so, that would be unfortunate... because the whole raison d'etre of ReasonML is DX! Specifically, to provide a more familiar syntax for programmers coming from the curly-brace world.
  - myaccountonhn 11mo ago
phplovesong 11mo ago
Im sorry but this reads like a noob trying out ocaml for the first time and beeing annoyed because it does not work like Java.
shortrounddev2 11mo ago
My main gripe with ML variants is the poor syntax around async (F#). For networked (web) applications, you begin to find that many or most of your functions are async, and wrapping them in computation blocks which come with their own internal syntax that eliminates a lot of the elegance of ML and makes your code look more imperative often feels like it defeats the purpose of the language. In F# let Foo = async { let! data = getData() |> Async.AwaitTask return data.value } Is this the best they can do? C# just has async Task<Data> Foo() => (await getData()).value; Ive always wanted ML syntax like this: let async Foo = let data = await getData data.value I just dont write a ton of pure functions which have no I/O dependencies
- neonsunset 11mo ago
  This is outdated. let foo = task { let! data = getData() return data.value } In F#, you interoperate with Task<T> transparently, and there is a number of community libraries to further enhance the experience. It also supports nice combinators like and! out of box.
- sasmithjr 11mo ago
  You can write a helper method (or use FsToolkit.ErrorHandling[0]) to simplify the F# example to: let Foo () = getData() |> Task.map _.value And it'll be easier to work with the .NET ecosystem if you use the task computation expression[1] over the async one. [0]: https://github.com/demystifyfp/FsToolkit.ErrorHandling https://github.com/demystifyfp/FsToolkit.ErrorHandling [1]: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/task-expressions https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
  - shortrounddev2 11mo ago
    Isn't that a synchronous call?
- yawaramin 11mo ago
  We have exactly that in OCaml. Check out Eio.

58 points by quamserena 11mo ago

Hendrikto 11mo ago

> Usually partial function application is a bug Dude, what?

jlouis 11mo ago
It's my favorite line of the whole thing. There's so much which can be derived from that single statement.
dan-robertson 11mo ago
I think this is true. It can be easy to accidentally do partial application, especially with optional and labelled arguments, eg: let bar x y z = … let foo w x = bar x (f w x) The performance and evaluation order can be a bit surprising in this case, and the errors when updating bar can be hard to understand.
quamserena 11mo ago
I would rather have partial function application be explicit rather than just omitting args because right now if you accidentally forget an argument (a bug) it isn’t an error there and instead becomes a type error somewhere else.

StepBroBD 11mo ago

For printing, there’s show in ppx_deriving [1], and I think ppx in general had made my overall experience with OCaml a lot better. [1] https://github.com/ocaml-ppx/ppx_deriving https://github.com/ocaml-ppx/ppx_deriving

rwmj 11mo ago

As an engineer writing OCaml (and Rust too), I don't find any of this stuff to be a pain point. The syntax is fine once you get used to it. Anecdotally one of my colleagues who is learning OCaml and contributing to the code is using an AI to help get the syntax right and that works for him. Types in Rust are way more complicated and obscure than the ones in OCaml. The ecosystem stays out of the way as much as possible - we are mainly interested in interfacing with C code directly, and OCaml (and Rust) make that pretty easy. I've been writing this project for over a decade and the language has been reasonably stable (OCaml 5 made some changes to the C interface, but we coped). Rust actually causes far more code churn - there's virtually a monthly cycle of some Rust compiler update requiring changes to existing code.

simonask 11mo ago
> Rust actually causes far more code churn - there's virtually a monthly cycle of some Rust compiler update requiring changes to existing code. This is really surprising to me. Which changes have you had to deal with here? The only one I can think of is the major Edition 2024 upgrade, which changed the `#[no_mangle]` attribute to `#[unsafe(no_mangle)]`. But the old syntax still compiles just fine with the newest compiler using Edition 2021.
- quamserena 11mo ago
  I am surprised by this too. I wonder what OP is writing in Rust that requires monthly changes?
- rwmj 11mo ago
  I guess it's because we use clippy to lint all the Rust code, combined with always pulling the latest Rust compiler (from Fedora Rawhide). But it's a real thing, there's a lot of churn. The good thing is clippy / rustc has very good diagnostics and usually tells you "do X to fix this".
  - quamserena 11mo ago
    I wish OCaml had more helpful error messages like these, right now it feels like I’m on my own solving some of the more inscrutable errors.
  - whytevuhuni 11mo ago
    I think what clippy needs the most is a way to say, "make all clippy warnings as errors, but only for warnings up to Rust 1.80". And then devs can update that number whenever they want, as opposed to whenever new updates come in. Or tie it to the current edition, or the current MSRV if defined.
  - simonask 11mo ago
    I think it’s pretty unfair to characterize new, helpful lints as “breaking changes”. There’s plenty of options to not have to deal with that (unless you want to of course).

anthk 11mo ago

On ML languages, you can try MLite first (it comes with a great manual and a paper too); and then you can jump into the biggies such as OCaML and maybe Haskell too: https://t3x.org/mlite/index.html https://t3x.org/mlite/index.html

user____name 11mo ago
I like the apology page.

jpfromlondon 11mo ago

Ocaml is one of the few languages I think you either really like or really don't.

lucas_membrane 11mo ago
Not for me. I spent a few weeks a few weeks ago trying to use it. Much I liked. Much I didn't. I like FP, so that was not a problem. But I found that lots of stuff was pretty hard for me as just an old guy trying to write some fancy little GUI apps to assist some of my other spare time activities. The project system, dune, was puzzling to me, and when I looked for clarification on-line it was pretty clear that I had lots of company. Not wanting to pass time writing code and seeing many potentialy useful packages available, I downloaded quite a few (actually, I downloaded not too many, but the dependencies required for those multiplied rapidly). Then I found myself managing multiple environments, because the different versions of this and that do not always work together so nice. Some library code has to get imported some ways, some other ways. Etc, etc. Many tutorials teach the toplevel interpreter, but that's not recommended for projects of any size, and the other environments will choke on the code that works in the toplevel. What I liked is that the OCaml ecosystem doen't look like it wants to control or ought to fear the next big thing. It's what you get when you have a lot of smart creative people who get inspired and do their best according to their own motivations and their own conception of quality. I admire that. I'm glad that I tried it.

pjmlp 11mo ago

Having learnt ML via Caml Light, back when OCaml was still going to be the next version, and known by its full name Objective Caml, I never considered any of that a pain point.

_flux 11mo ago

The article mentions that global type inference is painful, and Rust made the right call by requiring annotations, but actually I think the OCaml model is closer to the optimum: you can still annotate functions and perhaps you should (in fact the interface files are in my view great, but not everyone enjoys them), but the key benefit is that you can also use holes in such definitions, e.g. _ option list is usually quite descriptive of what data you have, but still doesn't go into some detail you don't want to (sadly "int _ list" isn't supported by the type system). The types in Rust can sometimes get quite long, in particular if you want to avoid boxing and you're dealing with futures.

GCUMstlyHarmls 11mo ago
I imagine there's as sweet spot between type inference, an LSP "add type annotations" action and a "function missing annotations" warning option. Smooth out the exploratory stage, flip to "strict" with one button and a way to enforce "strict" mode.
- quamserena 11mo ago
  I actually find that annotated parameters and return types help me during the exploratory stage too otherwise I invariably end up making a typeerror somewhere and the errors aren’t helpful (the error shows up in the wrong spot, or the function mysteriously changes type)
quamserena 11mo ago
I second the point that Rust types can get quite long. I usually use aliases where I can but that isn’t always possible. I think that sometimes people use boxing just to avoid these long types even if the code in theory doesn’t require an allocation

user____name 11mo ago

Reminded me of this comparison between Ocaml and Sml with regards to the purity vs practicality. [0] The complaint about syntax is amusing, I get a bit annoyed when I see Rust syntax being inserted into Java/C-ish languages. [0] http://adam.chlipala.net/mlcomp/ http://adam.chlipala.net/mlcomp/

sshine 11mo ago

Standard ML was my favorite language 2008-2012, and whenever people criticize the syntax, I shake my head. ML syntax is among the most beautiful, and most readable, to me. OCaml has a few features that bring the readability down a little, like the named fields prefix. The fact that it doesn't look like C or Ruby isn't bad. Erlang can be very readable, it just feels alien, which I presume is what people don't like. The big downside is the paradigm shift + inscrutable error messages. It will make you feel dumb and/or unproductive for a very long time. A lot of the type errors can be fixed by a compiler that cares more about error messages, and OCaml in particular could do well with terminators after e.g. match blocks to improve both ambiguity and error reporting. Some of the type errors can't easily be fixed; wrong function application by omitting some value somewhere has, so far, always led to misleading errors; are there any other examples than Elm that address these? I also switched from ML to Haskell to Rust. To me, the main downside of ML is the explicitly instantiated module systems not tied to the filesystem hierarchy. Once you get used to traits and parameterised trait instances, bringing every module instantiation into scope after separately importing them is just slooow. The standard library situation is also somewhat not great. Maybe I just never got used to it, but I sense that there are people think Jane Street Base is a must, and people who think it's completely overkill. OCaml programmers have a weird fetish with micro-optimization because the compiler lets you think about the asm output. It's a remarkable property of an otherwise high-level language that you can really care about the asm output.

StopDisinfo910 11mo ago
> OCaml in particular could do well with terminators after e.g. match blocks to improve both ambiguity and error reporting You can use either begin/end or parentheses as terminators around any blocks of Ocaml for exactly that purpose. > To me, the main downside of ML is the explicitly instantiated module systems not tied to the filesystem hierarchy. That's one of the greatest strenght of ML actually and especially Ocaml where parametrised modules are everywhere and a required building block of generic code. A significant part of why the article complains about type for exemple is because the author doesn't know how to use the module system. > Once you get used to traits and parameterised trait instances I like modules a lot more. It makes the code a lot clearer than traits. > The standard library situation is also somewhat not great. Maybe I just never got used to it, but I sense that there are people think Jane Street Base is a must The standard library is a lot more complete nowadays that it was some years ago and Base is used by pretty much nobody outside of JaneStreet.

ernst_klim 11mo ago

> there is no equivalent to Java's toString or Rust's #[derive(Debug)] There are devivers and a Format module for pretty printing. https://github.com/ocaml-ppx/ppx_deriving https://github.com/ocaml-ppx/ppx_deriving https://ocaml.org/manual/5.4/api/Format.html https://ocaml.org/manual/5.4/api/Format.html

quamserena 11mo ago
I am aware of this, but afaik it’s an external library? https://github.com/thierry-martinez/ppx_show https://github.com/thierry-martinez/ppx_show
- ernst_klim 11mo ago
  Format is part of OCaml stdlib. You can write formatters for it manually. Derivers are a library yes, it's pretty widespread if you need derive functionality, and it can derive basic functions. Proper link: https://github.com/ocaml-ppx/ppx_deriving?tab=readme-ov-file#plugin-show https://github.com/ocaml-ppx/ppx_deriving?tab=readme-ov-file...
- yawaramin 11mo ago
  Re: the 'external lubrary' criticism. In Rust everybody says just use serde for serializing data and anyhow for error handling. But suddenly when we say use a ppx deriver in OCaml for effectively the same thing–serializing a type to a string–it's a huge problem. That's weird to me.
  - quamserena 11mo ago
    I’m not a fan of serde either. I wish there was a way to have foreign derives (or even better: compile-time reflection). There wasn’t a great way to serialize things in Rust in the standard library and the ecosystem crystalized around serde, which is suboptimal imo. There are libraries like facet[0] that implement general reflection, rather than just a subset of it, but it probably won't be supported by all of your dependencies. [0] https://github.com/facet-rs/facet https://github.com/facet-rs/facet

sanskarix 11mo ago

what's always wild to me about these language debates is how much energy people spend defending syntax preferences instead of asking "does this help me ship?" OCaml's real pain point isn't the syntax - it's that you can't hire for it. if you're building a startup and you pick OCaml, you've just cut your hiring pool by 95%. that's way more painful than learning a different way to write functions. the whole "academic vs practical" thing is backwards. academic languages often have killer features that would save you real pain, but if your team can't debug it or you can't find Stack Overflow answers at 2am, none of that matters. language choice is a business decision, not a technical purity contest.

yodsanklai 11mo ago
> if you're building a startup and you pick OCaml, you've just cut your hiring pool by 95%. that's way more painful than learning a different way to write functions. You can hire anyone who already understands pattern matching, closures, map/fold (these are more and more common constructs nowadays) and train them to learn OCaml. It's a simple language overall, especially if your codebase doesn't use any complicated features.
hocuspocus 11mo ago
> OCaml's real pain point isn't the syntax - it's that you can't hire for it. if you're building a startup and you pick OCaml, you've just cut your hiring pool by 95%. that's way more painful than learning a different way to write functions. I hear this a lot about Scala and it's never been an issue in practice. A smaller pool of candidates makes hiring easier, I'd much rather screen 20 résumés than 400. The typical candidate, whether experienced or willing to learn, is also better on average. "We can't find qualified developers" usually tells more about the employer, in reality that means: - We aren't willing to pay market rates. - We don't invest in even the most basic on-the-job training. - Seniority distribution is junior heavy; we expect one senior developer per team who can mentor all the other ones. Or a combination of the above. I know two relatively small companies that use OCaml, they don't pay anywhere near Jane Street salaries, but they're willing to hire people who show interest in the language and invest a little in their training. This works. On my end I've hired several people coming almost purely from Python, after a few weeks they contribute to fairly advanced Scala codebases.

okhobb 11mo ago

My favorite part about Ocaml is the type checker fwiw. Pretty much as soon as I appease it I'm guaranteed a 'working' program that usually does what I intended.

quamserena 11mo ago
My problem is that when you’re trying to appease it the errors it spits out can be confusing or in the wrong place

adamchol 11mo ago

I've been writing OCaml for quite some time now and I don't think any of those "pain points" are "pain" or really any problem with the language. I think they're more like a preference. The syntax or no forward references are just decisions that makes the language good in some ways and bad in others, and seems like you just really don't like the cons. Also, isn't freedom of annotating a function a good thing, instead of having a requirement on it? You can just explicitly annotate some stuff when you have a type error that doesn't feel right! OCaml is way more simple from the type system perspective than Rust, I think it makes it great when you need a lot of iteration on you code. One thing I do agree on are problems with the ecosystem. Maybe not quite in the specific area described here but man we got some problems in IO/concurrency/asynchrony space. Making a GOOD standard for it would just improve all our lives as OCaml developers.

myaccountonhn 11mo ago

I employ some strategies when I work with OCaml to avoid some of these pain points: I avoid libraries with poor documentation, funky types, and preprocessors that don't throw proper error messages. So I skip ocamllex, Menhir and Reasonml because I've found like OP that the DX is too poor.. But otherwise I don't particularly agree with OPs pain points. I personally find OCaml's syntax to be great. Very easy to write and read once you're used to it. And I previously thought that it's very important to annotate all types, as it would help with my thinking, but these days I find I'm more productive when I write out the code without types, maybe add a type here and there. I only annotate if OCaml's deduced type is too complex or generic.

quamserena 11mo ago
Maybe it’ll grow on me as I get used to it :) but e.g. I was really confused about a nonsense error in a match statement until I realized that it was because of a nested match statement. If you don’t use ocamllex/Menhir, what do you use for parsing & compiling?
- yawaramin 11mo ago
  > I was really confused about a nonsense error in a match statement until I realized that it was because of a nested match statement. This kind of confusion instantly goes away when you use auto-formatting with ocamlformat, which is the recommended formatting tool for the OCaml platform. It would line up your match cases in such a way that you would be able to almost immediately tell that the compiler is interpreting the dangling cases as part of the inner match.
Taikonerd 11mo ago
Is the DX of ReasonML poor? (I haven't used it.) If so, that would be unfortunate... because the whole raison d'etre of ReasonML is DX! Specifically, to provide a more familiar syntax for programmers coming from the curly-brace world.
- myaccountonhn 11mo ago

phplovesong 11mo ago

Im sorry but this reads like a noob trying out ocaml for the first time and beeing annoyed because it does not work like Java.

shortrounddev2 11mo ago

My main gripe with ML variants is the poor syntax around async (F#). For networked (web) applications, you begin to find that many or most of your functions are async, and wrapping them in computation blocks which come with their own internal syntax that eliminates a lot of the elegance of ML and makes your code look more imperative often feels like it defeats the purpose of the language. In F# let Foo = async { let! data = getData() |> Async.AwaitTask return data.value } Is this the best they can do? C# just has async Task<Data> Foo() => (await getData()).value; Ive always wanted ML syntax like this: let async Foo = let data = await getData data.value I just dont write a ton of pure functions which have no I/O dependencies

neonsunset 11mo ago
This is outdated. let foo = task { let! data = getData() return data.value } In F#, you interoperate with Task<T> transparently, and there is a number of community libraries to further enhance the experience. It also supports nice combinators like and! out of box.
sasmithjr 11mo ago
You can write a helper method (or use FsToolkit.ErrorHandling[0]) to simplify the F# example to: let Foo () = getData() |> Task.map _.value And it'll be easier to work with the .NET ecosystem if you use the task computation expression[1] over the async one. [0]: https://github.com/demystifyfp/FsToolkit.ErrorHandling https://github.com/demystifyfp/FsToolkit.ErrorHandling [1]: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/task-expressions https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
- shortrounddev2 11mo ago
  Isn't that a synchronous call?
yawaramin 11mo ago
We have exactly that in OCaml. Check out Eio.