5 ms·

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

by rwmj 1y 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 1y 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 1y ago
  I am surprised by this too. I wonder what OP is writing in Rust that requires monthly changes?
- rwmj 1y 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 1y 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 1y 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 1y 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).
- blarg1 1y ago
  A recent one I had was needing to include lifetimes to having to atleast specify the anon lifetime with the underscore. I forget what the actual circumstance was.
StopDisinfo910 1y ago
I stopped fighting this battle a long time ago. I think Ocaml just doesn't spoon feed people enough. They would have to actually read the documentation to understand and that's simply too hard nowadays so you end up which this kind of articles about "pain points" which are basically "I don't know what I'm doing and making a lot of mistakes, let me blame my tool". Basically, when someone complaining starts by "I don't like the Algol-like syntax", obviously without saying it's Algol-like because that would require they actually know what Algol is, the rest is probably going to be extremely poor at best. And here, it doesn't disappoint. Point 2, "I don't like type inference, it's too clever". Or you could just put type annotations at every declarations like every pieces of documentation ever produced on the language invite you to. The type paragraph and the mentions of shadowing actually shows the author doesn't know how to use the Ocaml module system. For the neophytes here, it's the main standout feature of Ocaml. It's a bit like talking about C without knowing how to use pointers. I have seen people do that actually so I probably shouldn't be too surprised. Menhir and ocamllex syntaxes are just slight twists on the actual syntaxes of yacc and lex. Nothing surprising for someone who knows both tools but I guess it's becoming a rarity nowadays. To be honest, the Ocaml compiler works exactly how you would expect a C compiler and linker to work. That makes it really simple and predictable for people who used to be C programmers but apparently completely inscrutable for young developers. For printing, they quote "#[derive(Debug)]" in Rust but apparently they never reached ppx_deriving in Ocaml. It's a shame because it does exactly the same thing. The whole conclusion with the weird segway about academics for a language which was purposefully designed to write provers and not as a research language doesn't even deserve to be commented upon. Anyway, just go use Rust, bask in the hype, fight the borrow checker for things which don't require manual memory management, and leave us be. I think a significant part of why Ocaml is nice is that it is not appealing to many developers.
- nesarkvechnep 1y ago
  As soon as I saw the author uses OCaml for a class, I immediately knew the analysis will be somewhat superficial. No wonder, remembering my limited understanding when I was studying. Thank you for your comment because I've been meaning to give OCaml a serious chance for a vary long time.
thw_9a83c 1y ago
> Types in Rust are way more complicated and obscure than the ones in OCaml For the most common cases, I agree. I always wondered why OCaml remained such a niche language, given that many of its nice features took decades to appear in more mainstream languages. I thought it was because the language was too complex and advanced for the mainstream audience. However, with the rise of Rust, I don't think so anymore. Rust is, in many ways, as complex as OCaml and, in certain cases, even more complicated. Yet, it's becoming very popular. So my second theory about its lack of popularity must be correct: it has beginner-unfriendly documentation. In fact, I would even say it's unfriendly to engineers (as developers). The OCaml community prefers to see this language as an academic affair and doesn't see the need to attract the masses. Rust is an example of the opposite. It's a complex language, but it's pushing hard to become mainstream.

by rwmj 1y ago

simonask 1y 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 1y ago
I am surprised by this too. I wonder what OP is writing in Rust that requires monthly changes?
rwmj 1y 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 1y 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 1y 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 1y 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).
blarg1 1y ago
A recent one I had was needing to include lifetimes to having to atleast specify the anon lifetime with the underscore. I forget what the actual circumstance was.

StopDisinfo910 1y ago

I stopped fighting this battle a long time ago. I think Ocaml just doesn't spoon feed people enough. They would have to actually read the documentation to understand and that's simply too hard nowadays so you end up which this kind of articles about "pain points" which are basically "I don't know what I'm doing and making a lot of mistakes, let me blame my tool". Basically, when someone complaining starts by "I don't like the Algol-like syntax", obviously without saying it's Algol-like because that would require they actually know what Algol is, the rest is probably going to be extremely poor at best. And here, it doesn't disappoint. Point 2, "I don't like type inference, it's too clever". Or you could just put type annotations at every declarations like every pieces of documentation ever produced on the language invite you to. The type paragraph and the mentions of shadowing actually shows the author doesn't know how to use the Ocaml module system. For the neophytes here, it's the main standout feature of Ocaml. It's a bit like talking about C without knowing how to use pointers. I have seen people do that actually so I probably shouldn't be too surprised. Menhir and ocamllex syntaxes are just slight twists on the actual syntaxes of yacc and lex. Nothing surprising for someone who knows both tools but I guess it's becoming a rarity nowadays. To be honest, the Ocaml compiler works exactly how you would expect a C compiler and linker to work. That makes it really simple and predictable for people who used to be C programmers but apparently completely inscrutable for young developers. For printing, they quote "#[derive(Debug)]" in Rust but apparently they never reached ppx_deriving in Ocaml. It's a shame because it does exactly the same thing. The whole conclusion with the weird segway about academics for a language which was purposefully designed to write provers and not as a research language doesn't even deserve to be commented upon. Anyway, just go use Rust, bask in the hype, fight the borrow checker for things which don't require manual memory management, and leave us be. I think a significant part of why Ocaml is nice is that it is not appealing to many developers.

nesarkvechnep 1y ago
As soon as I saw the author uses OCaml for a class, I immediately knew the analysis will be somewhat superficial. No wonder, remembering my limited understanding when I was studying. Thank you for your comment because I've been meaning to give OCaml a serious chance for a vary long time.

thw_9a83c 1y ago

> Types in Rust are way more complicated and obscure than the ones in OCaml For the most common cases, I agree. I always wondered why OCaml remained such a niche language, given that many of its nice features took decades to appear in more mainstream languages. I thought it was because the language was too complex and advanced for the mainstream audience. However, with the rise of Rust, I don't think so anymore. Rust is, in many ways, as complex as OCaml and, in certain cases, even more complicated. Yet, it's becoming very popular. So my second theory about its lack of popularity must be correct: it has beginner-unfriendly documentation. In fact, I would even say it's unfriendly to engineers (as developers). The OCaml community prefers to see this language as an academic affair and doesn't see the need to attract the masses. Rust is an example of the opposite. It's a complex language, but it's pushing hard to become mainstream.