5 ms·

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 m

by baby 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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.
  - rwmj 6y ago
    We have 6 lines of code that we copy and paste around projects: https://github.com/libguestfs/libguestfs/blob/d01ce082180c41801640bc233c5d6f3ad4195458/subdir-rules.mk#L85-L91 https://github.com/libguestfs/libguestfs/blob/d01ce082180c41... Now if you're saying that the autotools/make/cmake/meson tooling is hard, I sort of agree, but many people are familiar with C build tools already. I don't see how it's easier or harder than learning language-specific tools.
    - jolux 6y ago
      >Now if you're saying that the autotools/make/cmake/meson tooling is hard, I sort of agree That's not really the main problem to me but it is a problem. >many people are familiar with C build tools already Maybe if they're C++ programmers. I don't know anyone outside of the C++ community who has ever used anything aside from Makefiles and language-specific tooling. >I don't see how it's easier or harder than learning language-specific tools. The language-specific tools are typically very well integrated with the default testing, packaging, and editor tools ecosystem. The C build tools are not going to be, at least not for OCaml. Language-specific tools show users the best experience a language can offer. More advanced users can always choose to use something else, but the advantages of the whole community using the same tool are hard to beat as well.
- dhconnelly 6y ago
  I've done a few small projects in OCaml. It's a brilliant language that I deeply enjoy using. But the situation for newcomers and those who don't have established patterns is bad. It's hard to do anything nontrivial from scratch, and the community doesn't seem to have any consensus around dependency management, builds, project structure, and so on. Make and autotools may work for you, but it's not like your setup is on the ocaml.org homepage, reproducible by an application developer in five lines of shell commands. It's common now in some language ecosystems for the default tooling to just generate all this stuff for you, and you move on to writing code. So if you're e.g. a JavaScript developer who is interested in functional programming, and you're used to npm or whatever, it's a difficult start.
  - yawaramin 6y ago
    > the community doesn't seem to have any consensus around dependency management, builds, project structure, and so on. Yes, it does. - Dependency management: opam - Builds: dune - Project structure: dictated by dune - and so on: more details at https://ocaml.org/platform/ https://ocaml.org/platform/
    - dhconnelly 6y ago
      The commenter I'm replying to uses an entirely different toolchain, and the frequently-recommended Cornell book (https://www.cs.cornell.edu/courses/cs3110/2021sp/textbook/ https://www.cs.cornell.edu/courses/cs3110/2021sp/textbook/) uses ocamlbuild and utop and makes no mention of Dune. If you (understandably) happen to land in the official OCaml manual at https://ocaml.org/manual/index.html https://ocaml.org/manual/index.html instead of the page you linked to (which I can't find from ocaml.org, by the way, but you're right that the ocaml.org tutorials do mention Dune and opam), then you don't see Dune or opam mentioned at all. I get what you're saying, but I don't think you could disagree with the premise that there are parts of the OCaml ecosystem that a newbie would land in and be confused or misled by here.
      - yawaramin 6y ago
        That's fine, but if you go to https://ocaml.org/ https://ocaml.org/ and click the big 'Install OCaml' CTA at the top of the page, it takes you through installing opam, dune, and ocaml-lsp-server. And as per the latest OCaml Survey, it looks like the majority of the community are using opam and dune: https://docs.google.com/forms/d/1OZV7WCprDnouU-rIEuw-1lDTeXrH_naVlJ77ziXQJfg/viewanalytics#c39 https://docs.google.com/forms/d/1OZV7WCprDnouU-rIEuw-1lDTeXr... Do some of the doc pages need to be updated? Yes. Do some universities take a long time to update their course materials? Yes. Does this mean there's no conensus? No.
yawaramin 6y ago
> there are no conventions in the way you set up a project (you can put your files in any folder) Dune enforces fairly strong conventions in project layout. Agree with a lot of your comment though.
- baby 6y ago
  Really? You can put your opam package files and dune files wherever you want and it’ll automagically work. Submodules can be defined far away from the library and it’s fine. If your opam packages are empty it’s fine, dune doesn’t care about versions of packages anyway. If you want to vendor/patch a library, just drop it anywhere in your project. Yet dune seems to be unaware or executables and libraries when you want to run or build something (you need to pass paths).
  - yawaramin 6y ago
    That's mostly because dune is 'composeable' so it accepts project components anywhere in the tree. But the components themselves are laid out in a certain way: - A dune file in a specific directory makes that directory a component - An .ml file in the directory with the same name as the component (in the dune file) becomes the main module of the component - Any submodules aliased inside the main module are properly wrapped and namespaced.
    - baby 6y ago
      Sure, but Cargo and go modules/vendors are composable too but there’s still a forced convention that doesn’t allow you to place your files wherever you want.
      - baby 6y ago
        Oh and, the way name and public_name works is also not great. Basically you never know what is being importer or used because it ultimately depends not on how the folder is named but on either name or public_name in a dune file. For example in rust you can import what’s in folder a/b by doing a::b but in OCaml you import a.b or a_b it it’s what set as name or public_name.

by baby 6y ago

rwmj 6y 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 6y 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 6y 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 6y 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 6y 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.
- rwmj 6y ago
  We have 6 lines of code that we copy and paste around projects: https://github.com/libguestfs/libguestfs/blob/d01ce082180c41801640bc233c5d6f3ad4195458/subdir-rules.mk#L85-L91 https://github.com/libguestfs/libguestfs/blob/d01ce082180c41... Now if you're saying that the autotools/make/cmake/meson tooling is hard, I sort of agree, but many people are familiar with C build tools already. I don't see how it's easier or harder than learning language-specific tools.
  - jolux 6y ago
    >Now if you're saying that the autotools/make/cmake/meson tooling is hard, I sort of agree That's not really the main problem to me but it is a problem. >many people are familiar with C build tools already Maybe if they're C++ programmers. I don't know anyone outside of the C++ community who has ever used anything aside from Makefiles and language-specific tooling. >I don't see how it's easier or harder than learning language-specific tools. The language-specific tools are typically very well integrated with the default testing, packaging, and editor tools ecosystem. The C build tools are not going to be, at least not for OCaml. Language-specific tools show users the best experience a language can offer. More advanced users can always choose to use something else, but the advantages of the whole community using the same tool are hard to beat as well.
dhconnelly 6y ago
I've done a few small projects in OCaml. It's a brilliant language that I deeply enjoy using. But the situation for newcomers and those who don't have established patterns is bad. It's hard to do anything nontrivial from scratch, and the community doesn't seem to have any consensus around dependency management, builds, project structure, and so on. Make and autotools may work for you, but it's not like your setup is on the ocaml.org homepage, reproducible by an application developer in five lines of shell commands. It's common now in some language ecosystems for the default tooling to just generate all this stuff for you, and you move on to writing code. So if you're e.g. a JavaScript developer who is interested in functional programming, and you're used to npm or whatever, it's a difficult start.
- yawaramin 6y ago
  > the community doesn't seem to have any consensus around dependency management, builds, project structure, and so on. Yes, it does. - Dependency management: opam - Builds: dune - Project structure: dictated by dune - and so on: more details at https://ocaml.org/platform/ https://ocaml.org/platform/
  - dhconnelly 6y ago
    The commenter I'm replying to uses an entirely different toolchain, and the frequently-recommended Cornell book (https://www.cs.cornell.edu/courses/cs3110/2021sp/textbook/ https://www.cs.cornell.edu/courses/cs3110/2021sp/textbook/) uses ocamlbuild and utop and makes no mention of Dune. If you (understandably) happen to land in the official OCaml manual at https://ocaml.org/manual/index.html https://ocaml.org/manual/index.html instead of the page you linked to (which I can't find from ocaml.org, by the way, but you're right that the ocaml.org tutorials do mention Dune and opam), then you don't see Dune or opam mentioned at all. I get what you're saying, but I don't think you could disagree with the premise that there are parts of the OCaml ecosystem that a newbie would land in and be confused or misled by here.
    - yawaramin 6y ago
      That's fine, but if you go to https://ocaml.org/ https://ocaml.org/ and click the big 'Install OCaml' CTA at the top of the page, it takes you through installing opam, dune, and ocaml-lsp-server. And as per the latest OCaml Survey, it looks like the majority of the community are using opam and dune: https://docs.google.com/forms/d/1OZV7WCprDnouU-rIEuw-1lDTeXrH_naVlJ77ziXQJfg/viewanalytics#c39 https://docs.google.com/forms/d/1OZV7WCprDnouU-rIEuw-1lDTeXr... Do some of the doc pages need to be updated? Yes. Do some universities take a long time to update their course materials? Yes. Does this mean there's no conensus? No.

yawaramin 6y ago

> there are no conventions in the way you set up a project (you can put your files in any folder) Dune enforces fairly strong conventions in project layout. Agree with a lot of your comment though.

baby 6y ago
Really? You can put your opam package files and dune files wherever you want and it’ll automagically work. Submodules can be defined far away from the library and it’s fine. If your opam packages are empty it’s fine, dune doesn’t care about versions of packages anyway. If you want to vendor/patch a library, just drop it anywhere in your project. Yet dune seems to be unaware or executables and libraries when you want to run or build something (you need to pass paths).
- yawaramin 6y ago
  That's mostly because dune is 'composeable' so it accepts project components anywhere in the tree. But the components themselves are laid out in a certain way: - A dune file in a specific directory makes that directory a component - An .ml file in the directory with the same name as the component (in the dune file) becomes the main module of the component - Any submodules aliased inside the main module are properly wrapped and namespaced.
  - baby 6y ago
    Sure, but Cargo and go modules/vendors are composable too but there’s still a forced convention that doesn’t allow you to place your files wherever you want.
    - baby 6y ago
      Oh and, the way name and public_name works is also not great. Basically you never know what is being importer or used because it ultimately depends not on how the folder is named but on either name or public_name in a dune file. For example in rust you can import what’s in folder a/b by doing a::b but in OCaml you import a.b or a_b it it’s what set as name or public_name.