4 ms·

Python had no multicore during the same period and that never prevented it from becoming successful. Plus, Ocaml always had descent solution for concurrent I/O.

Python had no multicore during the same period and that never prevented it from becoming successful. Plus, Ocaml always had descent solution for concurrent I/O. The absence of multicore is a complete red herring in why Ocaml isn't more successful. Ocaml issue never was the syntax which is completely fine. The current syntax is actually a lot nicer that what Facebook proposed. Ocaml issue is not being a USA-born project nor having a significant marketing push in English. Plus, Ocaml always was too far ahead of its time (including now with its effect system). First, you have the functional approach which was already very unfamiliar for most. Then, you have to add module level programming on top which is still very unfamiliar to most. Just look at this comment page and people thinking Ocaml is not fun to use or less interesting than Haskell, it's trully sad. Multicore has added the extremely promising effect system but that's once again a step too far for most current developers. In a lof of way, Ocaml is to programming language what the Pixies are to rock music. Everyone who felt deeply in love with it went on to write a language of their own. Some got really successful.

behnamoh 1y ago
> Ocaml issue is not being a USA-born project nor having a significant marketing push in English. Python is a counter argument here.
- StopDisinfo910 1y ago
  It's not. Van Rossum is Dutch but Python always had a strong marketing push in English. The first version was announced in English on Usenet. Van Rossum moved to the USA quite quickly to work on Python from CNRI in 1995. Then, it got funding from DARPA in 1999 with this as part of its pitch: "Create a code that is easy to understand and looks as easy as the English language." Ocaml meanwhile is an INRIA child made by a French team to develop another INRIA child made by another French team. I think in Europe, that's approximately as US hostile as you can be. Actually, Ocaml has only become somewhat popular since it's pushed a bit from the UK which I find amusing.
kangda123 1y ago
As far as my experience, there's little code in Python that I would like to replace with OCaml. Python stuff is research code and small services that were written hastily. I would love to replace my Go code with OCaml. It was always kind of on the verge though. On one hand, once you use a proper type system, you cannot look at Go. On the other, Go's multicore is just so much better than Async/Lwt. In terms of programming, in terms of debuggability, surely in terms of performance too. Having proper multithreading in 5.0 suddenly makes OCaml strictly superior in my (rather biased) opinion.
- neonsunset 1y ago
  Maybe F# as a middle ground? Although if you have religious avoidance of JIT compilation, using NativeAOT with F# has a few rough edges right now (it works, but you need to be aware of edge cases, with that said, you can still make fairly compact standalone binaries with JIT, it's just that they'll take say 10MB and not 2-3).
deredede 1y ago
The lack of ad-hoc polymorphism has to be there somewhere as well.
- giraffe_lady 1y ago
  I don't think so really. It might help lure people over from haskell or rust or whatever but ocaml has its own solutions to the problems solved by ad hoc polymorphism. Usually in the module system, sometimes a ppx. There's nothing comparable to ocaml's module system that I know of in any other mature language so no one really arrives in ocaml with well developed intuition for what sorts of things are possible and worth doing with it. But once you've put the time in it's usually the correct answer to "how to do I do <haskell type system thing> in ocaml." I'm not a type systems expert though and it's likely there are some novel & unique situations where it's the best or only solution. Just maybe not as much as people assume from outside. Anyway I think there is a proposal for it so it'll probably work its way in eventually.
  - hajile 1y ago
    Isn't Ocaml's module system based on StandardML? SML predates Ocaml by a few years and non-standardized ML by a couple decades.
    - giraffe_lady 1y ago
      Oh actually I'm not sure. I was thinking it was one of the things ocaml added but now I think you're right.
  - aseipp 1y ago
    Haskell's "mixin modules" AKA backpack are I think the closest thing you're going to get outside of SML (they are a different trade off in the design space, it's not 1-to-1), but they have languished in the broader community due to a couple social factors. They are excellent for many of the same things you use modules for, though, and work just fine in my experience. On the same note, the lack of some kind of module system along these lines (broadly all defined in terms of "holes" in a compilation unit which are "plugged up" later on at instantiation time), is one of my biggest complaints about Rust. The extensive usage of traits in the broader ecosystem results in this phenomenon (identical to Haskell) where global coherence requires your dependency tree gets tied up in the location of types and their trait impls. In other words, you cannot abstract over your dependencies in a truly modular way. Global coherence requirements are fine (preferable even!) for many things but if it's the only hammer you have, well, you know the rest of the metaphor. > Anyway I think there is a proposal for it so it'll probably work its way in eventually. Modular implicits have been shelved indefinitely from what I understand, if that's what you're referring to.
hardwaregeek 1y ago
I'd disagree about syntax. It really does matter. So much of Rust's success is tricking people into writing a functional style while having it look like an imperative language. OCaml syntax isn't bad per se but it's unfamiliar and that's enough to discourage users.
- myaccountonhn 1y ago
  I think you're right, and I hate it. Just look at Gleam as an example where adopting a more C like syntax got them a ton more adoption almost over night. I love Ocaml (and Haskell-esque) syntax, but I must admit it can be detrimental to getting adopted. I think another issue was bad tooling for a long time. Now with Dune it's great though, with very fast compile speeds. Hopefully OCaml slowly gets the recognition it deserves, because it really is a great language.
- sesm 1y ago
  Rust refs are not OCaml refs though. Rust just places more guardrails around update-in-place model, instead of using controlled references to immutable data like OCaml (and Clojure).
noelwelsh 1y ago
Go / Rust / Scala are the competition for OCaml, not Python. Around 2010 there weren't great options if you wanted a vaguely modern language in the server backend space. Java was stagnant and Scala was just getting going commercially. OCaml could have been in there.
- vips7L 1y ago
  Scala really had potential. But I really think they pushed away the average developer and with Scala 3 fractured their ecosystem even more. I personally wish the community had stayed true to the vision of fusing object and functional programming.
dismalaf 1y ago
> Ocaml issue is not being a USA-born project Tons of languages started outside the US. Python and Ruby being notable.
aseipp 1y ago
OCaml's syntax is not what's "holding it back" in my personal opinion, but that doesn't mean it's "fine". I regularly praise it as a language (even as a former developer of the main Haskell compiler, which adopted Mixin-style modules decades after the fact) and "the syntax looks like shit" is absolutely one of the first immediate turn-offs for pretty much everyone I talk to. It's also one of my own complaints, but OCaml has a lot of good stuff too so I can put up with it.
GIFtheory 1y ago
100% agreed. The moment I saw the “revised” syntax I had a real “what were they thinking” moment. You’re supposed to take the good parts of a good thing and add it to a bad thing, not the other way around! Really, OCaml’s syntax is beautiful, unless you’re one of those people who loves to show off how adept they are at typing matching braces, parentheses, commas, and semicolons. Writing a little lambda in C++ is an impressive display of manual dexterity… [&](…,…){… return …; }; Who would rather write that than let f x y = … in? The only way I’d improve OCaml syntax would be to add something like python style list comprehension.

behnamoh 1y ago

> Ocaml issue is not being a USA-born project nor having a significant marketing push in English. Python is a counter argument here.

StopDisinfo910 1y ago
It's not. Van Rossum is Dutch but Python always had a strong marketing push in English. The first version was announced in English on Usenet. Van Rossum moved to the USA quite quickly to work on Python from CNRI in 1995. Then, it got funding from DARPA in 1999 with this as part of its pitch: "Create a code that is easy to understand and looks as easy as the English language." Ocaml meanwhile is an INRIA child made by a French team to develop another INRIA child made by another French team. I think in Europe, that's approximately as US hostile as you can be. Actually, Ocaml has only become somewhat popular since it's pushed a bit from the UK which I find amusing.

kangda123 1y ago

As far as my experience, there's little code in Python that I would like to replace with OCaml. Python stuff is research code and small services that were written hastily. I would love to replace my Go code with OCaml. It was always kind of on the verge though. On one hand, once you use a proper type system, you cannot look at Go. On the other, Go's multicore is just so much better than Async/Lwt. In terms of programming, in terms of debuggability, surely in terms of performance too. Having proper multithreading in 5.0 suddenly makes OCaml strictly superior in my (rather biased) opinion.

neonsunset 1y ago
Maybe F# as a middle ground? Although if you have religious avoidance of JIT compilation, using NativeAOT with F# has a few rough edges right now (it works, but you need to be aware of edge cases, with that said, you can still make fairly compact standalone binaries with JIT, it's just that they'll take say 10MB and not 2-3).

deredede 1y ago

The lack of ad-hoc polymorphism has to be there somewhere as well.

giraffe_lady 1y ago
I don't think so really. It might help lure people over from haskell or rust or whatever but ocaml has its own solutions to the problems solved by ad hoc polymorphism. Usually in the module system, sometimes a ppx. There's nothing comparable to ocaml's module system that I know of in any other mature language so no one really arrives in ocaml with well developed intuition for what sorts of things are possible and worth doing with it. But once you've put the time in it's usually the correct answer to "how to do I do <haskell type system thing> in ocaml." I'm not a type systems expert though and it's likely there are some novel & unique situations where it's the best or only solution. Just maybe not as much as people assume from outside. Anyway I think there is a proposal for it so it'll probably work its way in eventually.
- hajile 1y ago
  Isn't Ocaml's module system based on StandardML? SML predates Ocaml by a few years and non-standardized ML by a couple decades.
  - giraffe_lady 1y ago
    Oh actually I'm not sure. I was thinking it was one of the things ocaml added but now I think you're right.
- aseipp 1y ago
  Haskell's "mixin modules" AKA backpack are I think the closest thing you're going to get outside of SML (they are a different trade off in the design space, it's not 1-to-1), but they have languished in the broader community due to a couple social factors. They are excellent for many of the same things you use modules for, though, and work just fine in my experience. On the same note, the lack of some kind of module system along these lines (broadly all defined in terms of "holes" in a compilation unit which are "plugged up" later on at instantiation time), is one of my biggest complaints about Rust. The extensive usage of traits in the broader ecosystem results in this phenomenon (identical to Haskell) where global coherence requires your dependency tree gets tied up in the location of types and their trait impls. In other words, you cannot abstract over your dependencies in a truly modular way. Global coherence requirements are fine (preferable even!) for many things but if it's the only hammer you have, well, you know the rest of the metaphor. > Anyway I think there is a proposal for it so it'll probably work its way in eventually. Modular implicits have been shelved indefinitely from what I understand, if that's what you're referring to.

hardwaregeek 1y ago

I'd disagree about syntax. It really does matter. So much of Rust's success is tricking people into writing a functional style while having it look like an imperative language. OCaml syntax isn't bad per se but it's unfamiliar and that's enough to discourage users.

myaccountonhn 1y ago
I think you're right, and I hate it. Just look at Gleam as an example where adopting a more C like syntax got them a ton more adoption almost over night. I love Ocaml (and Haskell-esque) syntax, but I must admit it can be detrimental to getting adopted. I think another issue was bad tooling for a long time. Now with Dune it's great though, with very fast compile speeds. Hopefully OCaml slowly gets the recognition it deserves, because it really is a great language.
sesm 1y ago
Rust refs are not OCaml refs though. Rust just places more guardrails around update-in-place model, instead of using controlled references to immutable data like OCaml (and Clojure).

noelwelsh 1y ago

Go / Rust / Scala are the competition for OCaml, not Python. Around 2010 there weren't great options if you wanted a vaguely modern language in the server backend space. Java was stagnant and Scala was just getting going commercially. OCaml could have been in there.

vips7L 1y ago
Scala really had potential. But I really think they pushed away the average developer and with Scala 3 fractured their ecosystem even more. I personally wish the community had stayed true to the vision of fusing object and functional programming.

dismalaf 1y ago

> Ocaml issue is not being a USA-born project Tons of languages started outside the US. Python and Ruby being notable.

aseipp 1y ago

OCaml's syntax is not what's "holding it back" in my personal opinion, but that doesn't mean it's "fine". I regularly praise it as a language (even as a former developer of the main Haskell compiler, which adopted Mixin-style modules decades after the fact) and "the syntax looks like shit" is absolutely one of the first immediate turn-offs for pretty much everyone I talk to. It's also one of my own complaints, but OCaml has a lot of good stuff too so I can put up with it.

GIFtheory 1y ago

100% agreed. The moment I saw the “revised” syntax I had a real “what were they thinking” moment. You’re supposed to take the good parts of a good thing and add it to a bad thing, not the other way around! Really, OCaml’s syntax is beautiful, unless you’re one of those people who loves to show off how adept they are at typing matching braces, parentheses, commas, and semicolons. Writing a little lambda in C++ is an impressive display of manual dexterity… [&](…,…){… return …; }; Who would rather write that than let f x y = … in? The only way I’d improve OCaml syntax would be to add something like python style list comprehension.