7 ms·

Biggest thing impeding Ocaml for the average developer is the situation with the Stdlib, and multicore. It's not exactly a struggle to get Base or Core working

Biggest thing impeding Ocaml for the average developer is the situation with the Stdlib, and multicore. It's not exactly a struggle to get Base or Core working, but it's way less streamlined than it really ought to be. I see things like F# picking up some popularity and it strikes me as a bit of a tragedy on Ocaml's part. .NET is pretty bad to work with, imo. I know C# people will hate that, and indeed if I was meaning C# then they'd be right to feel that way. The fact is, there are few FP languages with a deep platform (like JVM, .NET, js/browser) already, and even fewer pleasant enough to work with on a daily basis. I've been blessed to use Ocaml for some of my statistics work, and I'm watching very close the OWL project (ocaml.xyz), and hopefully it will come together nicely. Still, I see the quickstart process of F#, Scala, Clojure, Elixir, even Haskell, and it's just much less headache than Ocaml for the first 10-15 minutes. Ultimately, I don't know. I use Python a LOT, and I REALLY enjoy it. A lot of what people don't like about Python just doesn't get in my way that much. Really the only thing that I could see myself yearning for in the language is pattern-matching (which we're getting soon) and some form of piping with better lambda support. I really miss |>, <| in the way I build my tools, but in the end I get along just fine. I'm glad that SO many languages have taken inspiration from Ocaml, and I'm sure that as time goes on, many more still will draw water from the plentiful well of its beautiful type inference, compiler architecture, domain modeling capabilities without annotations, et al. Finally, I think it remiss to sorta colloquialize projects by a sum of their most recent decisions. It's not difficult to look around and go "Man, ReScript is sort of a shit-show, ReasonML doesn't really offer anything except different syntax at this point, and there's typescript anyhow, which has a vastly superior dev experience in just about every modern code editor." But that doesn't do justice to how incredibly epic it is that a project is still alive and competitive at a deep, academic level, across continents, for 25 years. I could munge around my emails and find projects starting near me that are using things like Coq (now called something else, I think), it's very much still alive for important technical work even throughout the Numpy-pocalypse. Anyhow, this comment is a mess. Congratulations Ocaml team. Keep on truckin'. <3

baby 5y ago
As a newcomer it’s a fantastic language but the tooling and the ecosystem story is really lacking. I really think the language needs more hype in order to get more people to do things for it. The versioning story of dependencies is almost inexistant, the interaction between the package manager (opam) and buil tool (dune) is filled with issues, there are no conventions in the way you set up a project (you can put your files in any folder), stdlib vs base? Poor documentation, poor compiler errors, poor managements for patches (opam pin) and different versions of the compiler (opam switch creates a local repo in all your projects), etc. Coincidentally I’ve been writing up an OCamlbyexample page that hopefully I can post here at some point to motivate people to learn the language:)
- rwmj 5y ago
  I'm an actual OCaml programmer, almost daily, and I don't understand this objection. We use autotools and make as the build tool (but you could use ninja/meson, cmake or whatever), and don't bother with opam/dune. We properly package over 100 OCaml packages in Fedora. For anything else not covered by a package we mostly call into C libraries, which is very easy to do from OCaml. I guess it depends on exactly what you're trying to do, but we've developed a large amount of complex software in OCaml this way.
  - nicoburns 5y ago
    The C-ecosystem build tools you refer to are pretty far behind those of pretty much every other langauge. And most developers don't want to wait for their OS to package it to start using the new version of a library (not to mention this style of packaging isn't typically available on windows/macos).
    - yawaramin 5y ago
      In case you don't know, OCaml Platform recommended tooling is on par with or better than that of many other languages. Check out https://news.ycombinator.com/item?id=27099050 https://news.ycombinator.com/item?id=27099050
    - gnubison 5y ago
      > The C-ecosystem build tools you refer to are pretty far behind those of pretty much every other langauge. For developers, maybe. But as a user, I love compiling and installing Autoconf software (compared to the alternatives).
  - jolux 5y ago
    You roll your own build system instead of using the built-in tools and you don't understand why people wouldn't want to do that? This isn't a typical situation in Rust or even Haskell these days. Come on. Rarely are people arguing that a situation like this makes writing software impossible. The question is whether it adds friction, and in adding friction impedes adoption. I think it clearly does, and that tooling is one of the highest-impact features a language can prioritize to improve adoption. If the story for building and packaging OCaml software is "go make yourself proficient in the C build tooling ecosystem first," of course that makes it harder to adopt (and you're not the first person in the community to give this answer, either). This hostility to beginners is one of the major things that irks me about the OCaml community, and OCaml is probably my favorite language.
adsharma 5y ago
Python's pattern matching is not the same as Ocaml's. It's a statement, not an expression. But I like your line of thinking. Create a variant of python with ML like features without sacrificing compatibility too much. An effort in this direction is a transpiler I'm working on. So far it sticks to a strict subset of python3. But I'm open to incorporating ML like features in an incompatible way if there is a compelling argument. By sticking to a statically typed subset we've already given up some compatibility.
- nickmain 5y ago
  If you want to use OCaml-like GADTs and pattern matching in Python then there is the Haxe -> Python route. The Haxe compiler is actually written in OCaml and its type system is influenced by it.
  - adsharma 5y ago
    Thanks for the link. I'm thinking along the same lines and might derive some inspiration from Haxe on how to evolve python syntax to support features like GADT and FP that can be easily transpiled to other languages. It looks like Haxe was designed from day 1 to be transpiler friendly, whereas I'm trying to leverage python's popularity and language ecosystem to achieve similar goals. Sticking to a strict subset of python has the advantage that all the scripts are directly executable by the python interpreter. If we add some features (say implemented pattern matching similar to OCaml), we lose that. Perhaps some macros/library features can bridge that gap. Or over time, python evolves to be more like OCaml.
- adenozine 5y ago
  I mean, obviously you're right. I guess I just meant that it's good enough for what I'm doing in Python. People don't write verified provers for deep numerical projects in Python, they'd use Ocaml. For digging through a little sqlite collection, parsing through csv files and correlating a few simple features in dataframes, python works fine and the pattern matching that we'll be getting will make it easier to write THAT sort of code. I don't see Python growing very much more functionally. There's two decades of resisting FP with much vigor, and I expect another two decades of fighting about what little FP has grown into Python thus far. I'd love to see your transpiler work! It sounds pretty cool. I keep an eye on mys-lang (@github/mys-lang/mys) and mypyc, to see what's going on in that realm of Python. Compatibility is a double-edged sword, as I'm sure you realize.
fishmaster 5y ago
There's also the issue with the non-existent unicode support.
- yawaramin 5y ago
  IMHO, OCaml's decision to not encode strings in a Unicode encoding by default is the correct one. OCaml treats strings as just bytestrings, leaving the programmer to take care of the specific encoding, with the help of sophisticated and powerful libraries like Camomile. For an example of what happens when language implementations try to shoehorn in Unicode into their strings, look at JavaScript's UTF-16 strings or this Python example: https://www.reddit.com/r/programming/comments/asi2qo/go_is_a_pretty_average_language_but_ocaml_is/egvalzv/ https://www.reddit.com/r/programming/comments/asi2qo/go_is_a...
- rwmj 5y ago
  Compared to my experience with Python 3 and Ruby, OCaml is so much better. On the rare occasions I need to do something Unicode-y, I'll reach for Camomile, and the rest of the time I'm passing around strings/bytes unimpeded by silly language decisions.
- octachron 5y ago
  OCaml's decision is more to leave unicode support to libraries rather than let compiler writers handle unicode support as a side dish.

baby 5y ago

As a newcomer it’s a fantastic language but the tooling and the ecosystem story is really lacking. I really think the language needs more hype in order to get more people to do things for it. The versioning story of dependencies is almost inexistant, the interaction between the package manager (opam) and buil tool (dune) is filled with issues, there are no conventions in the way you set up a project (you can put your files in any folder), stdlib vs base? Poor documentation, poor compiler errors, poor managements for patches (opam pin) and different versions of the compiler (opam switch creates a local repo in all your projects), etc. Coincidentally I’ve been writing up an OCamlbyexample page that hopefully I can post here at some point to motivate people to learn the language:)

rwmj 5y ago
I'm an actual OCaml programmer, almost daily, and I don't understand this objection. We use autotools and make as the build tool (but you could use ninja/meson, cmake or whatever), and don't bother with opam/dune. We properly package over 100 OCaml packages in Fedora. For anything else not covered by a package we mostly call into C libraries, which is very easy to do from OCaml. I guess it depends on exactly what you're trying to do, but we've developed a large amount of complex software in OCaml this way.
- nicoburns 5y ago
  The C-ecosystem build tools you refer to are pretty far behind those of pretty much every other langauge. And most developers don't want to wait for their OS to package it to start using the new version of a library (not to mention this style of packaging isn't typically available on windows/macos).
  - yawaramin 5y ago
    In case you don't know, OCaml Platform recommended tooling is on par with or better than that of many other languages. Check out https://news.ycombinator.com/item?id=27099050 https://news.ycombinator.com/item?id=27099050
  - gnubison 5y ago
    > The C-ecosystem build tools you refer to are pretty far behind those of pretty much every other langauge. For developers, maybe. But as a user, I love compiling and installing Autoconf software (compared to the alternatives).
- jolux 5y ago
  You roll your own build system instead of using the built-in tools and you don't understand why people wouldn't want to do that? This isn't a typical situation in Rust or even Haskell these days. Come on. Rarely are people arguing that a situation like this makes writing software impossible. The question is whether it adds friction, and in adding friction impedes adoption. I think it clearly does, and that tooling is one of the highest-impact features a language can prioritize to improve adoption. If the story for building and packaging OCaml software is "go make yourself proficient in the C build tooling ecosystem first," of course that makes it harder to adopt (and you're not the first person in the community to give this answer, either). This hostility to beginners is one of the major things that irks me about the OCaml community, and OCaml is probably my favorite language.

adsharma 5y ago

Python's pattern matching is not the same as Ocaml's. It's a statement, not an expression. But I like your line of thinking. Create a variant of python with ML like features without sacrificing compatibility too much. An effort in this direction is a transpiler I'm working on. So far it sticks to a strict subset of python3. But I'm open to incorporating ML like features in an incompatible way if there is a compelling argument. By sticking to a statically typed subset we've already given up some compatibility.

nickmain 5y ago
If you want to use OCaml-like GADTs and pattern matching in Python then there is the Haxe -> Python route. The Haxe compiler is actually written in OCaml and its type system is influenced by it.
- adsharma 5y ago
  Thanks for the link. I'm thinking along the same lines and might derive some inspiration from Haxe on how to evolve python syntax to support features like GADT and FP that can be easily transpiled to other languages. It looks like Haxe was designed from day 1 to be transpiler friendly, whereas I'm trying to leverage python's popularity and language ecosystem to achieve similar goals. Sticking to a strict subset of python has the advantage that all the scripts are directly executable by the python interpreter. If we add some features (say implemented pattern matching similar to OCaml), we lose that. Perhaps some macros/library features can bridge that gap. Or over time, python evolves to be more like OCaml.
adenozine 5y ago
I mean, obviously you're right. I guess I just meant that it's good enough for what I'm doing in Python. People don't write verified provers for deep numerical projects in Python, they'd use Ocaml. For digging through a little sqlite collection, parsing through csv files and correlating a few simple features in dataframes, python works fine and the pattern matching that we'll be getting will make it easier to write THAT sort of code. I don't see Python growing very much more functionally. There's two decades of resisting FP with much vigor, and I expect another two decades of fighting about what little FP has grown into Python thus far. I'd love to see your transpiler work! It sounds pretty cool. I keep an eye on mys-lang (@github/mys-lang/mys) and mypyc, to see what's going on in that realm of Python. Compatibility is a double-edged sword, as I'm sure you realize.

fishmaster 5y ago

There's also the issue with the non-existent unicode support.

yawaramin 5y ago
IMHO, OCaml's decision to not encode strings in a Unicode encoding by default is the correct one. OCaml treats strings as just bytestrings, leaving the programmer to take care of the specific encoding, with the help of sophisticated and powerful libraries like Camomile. For an example of what happens when language implementations try to shoehorn in Unicode into their strings, look at JavaScript's UTF-16 strings or this Python example: https://www.reddit.com/r/programming/comments/asi2qo/go_is_a_pretty_average_language_but_ocaml_is/egvalzv/ https://www.reddit.com/r/programming/comments/asi2qo/go_is_a...
rwmj 5y ago
Compared to my experience with Python 3 and Ruby, OCaml is so much better. On the rare occasions I need to do something Unicode-y, I'll reach for Camomile, and the rest of the time I'm passing around strings/bytes unimpeded by silly language decisions.
octachron 5y ago
OCaml's decision is more to leave unicode support to libraries rather than let compiler writers handle unicode support as a side dish.