6 ms·

Well for example in the upcoming 4.12, the core team has integrated plenty of "practical" language features (such as support for iOS/OSX ARM64, or many changes

Well for example in the upcoming 4.12, the core team has integrated plenty of "practical" language features (such as support for iOS/OSX ARM64, or many changes related to multicore).

throwaway894345 6y ago
No doubt, but why are there still so many “standard” libraries? Where are is of the guides for building production applications? Why is the documentation so poor? How do the editor plugins compare to those for Go, Rust, etc? How familiar is the syntax to the broader body of developers? I’m not saying the Ocaml community never does anything practical; only that they don’t do enough to make their language mainstream. And maybe they don’t want their language to be mainstream—that’s perfectly fine, but that undermines all of the arguments that this or that project should be (re)written in Ocaml or that Ocaml is otherwise a better language than $x for general software development.
- yawaramin 6y ago
  > why are there still so many “standard” libraries? There is one standard library--the one that ships with OCaml. You can use replacement libraries if you really need them--I haven't yet needed to, but for heavy-duty production use maybe one day I will. > Where are is of the guides for building production applications? Is the emphasis on 'building' here, as in 'build tool'? If so, then https://dune.build/ https://dune.build/ is what you need. If the emphasis is on 'production application', then I'm sure there are others but https://shonfeder.gitlab.io/ocaml_webapp/ https://shonfeder.gitlab.io/ocaml_webapp/ comes to mind immediately. > Why is the documentation so poor? Which documentation specifically? If you mean OCaml itself, then you should check out https://ocaml.org/ https://ocaml.org/ , it has tons of high-quality documentation. If you mean third-party libraries, then it's probably mostly a lack of tooling that publishes docs automatically, but I think this is starting to change. > How do the editor plugins compare to those for Go, Rust, etc? The OCaml Language Server and its main editor plugin (for VSCode) are nearly feature-complete. The older Merlin tooling has been used for a long time. > How familiar is the syntax to the broader body of developers? Syntax can be learned, but for those who don't want to try, there is always ReasonML syntax that uses semicolons and curly braces to make OCaml look like JavaScript. > I’m not saying the Ocaml community never does anything practical; only that they don’t do enough to make their language mainstream. It's easy to make assertions without actually knowing anything, but it's better to do the research first to back them up, instead of asking a bunch of questions ;-)
  - throwaway894345 6y ago
    > There is one standard library--the one that ships with OCaml. You can use replacement libraries if you really need them--I haven't yet needed to, but for heavy-duty production use maybe one day I will. You're mistaken (or you're making an unrelated semantic argument because you don't want to argue the actual point; not sure which); there are multiple "standard" libraries used across the ecosystem (because the ecosystem has deemed "the one that ships with OCaml" to be inadequate) which makes integrating libraries throughout the ecosystem tedious and painful, especially to new OCaml developers. > Is the emphasis on 'building' here, as in 'build tool'? No, I expect an abundance of tutorials that explain how to build production-grade applications, soup to nuts. E.g., for a generic CRUD app, what are the best frameworks, ORMs, etc to use, how to integrate them, etc? > The older Merlin tooling has been used for a long time. Yes, but it's incredibly difficult to configure properly, or at least that was my experience when I got started. I'm actually not sure if I ever got it working with vim. > Syntax can be learned, but for those who don't want to try, there is always ReasonML syntax that uses semicolons and curly braces to make OCaml look like JavaScript. It can, but it's a burden with no advantage. Last I checked, ReasonML's support was pretty abysmal--it seemed like native compilation was neglected altogether in favor of something called "bucklescript" (presumably compilation to JS) and the integrations with the rest of the ecosystem (e.g., how to build native programs, link against ocaml dependencies, integrate with editor tools, etc) were either poorly documented or inadequate/incomplete or both. No doubt some of that has improved in the intervening years, but I'm doubtful that it has significantly improved. > It's easy to make assertions without actually knowing anything, but it's better to do the research first to back them up, instead of asking a bunch of questions ;-) You've provided the same unhelpful, pat answers that the OCaml community provides. For example, "Just use ReasonML!" as though setting up or using Reason is trivial or well documented or otherwise comparable to using Rust or Go out of the box. For another example, you altogether dodged the issues associated with multiple "standard" libraries. It would be great if the OCaml community were as committed to making their language useful for production applications as they were on convincing everyone else that it already was.
    - brmgb 6y ago
      > as though setting up or using Reason is trivial or well documented It's both trivial and well documented. There is an installation page and a tutorial on the Reason website. The installation in itself is one npm command. > For another example, you altogether dodged the issues associated with multiple "standard" libraries. There is only one standard library. It's the one shipped with the compiler. It is also significantly more battery included now than it used to be. > It would be great if the OCaml community were as committed to making their language useful for production applications as they were on convincing everyone else that it already was. The OCaml community as a whole is one of the least vocal on the internet. It does very little outreach. I never see any of the people I consider relevant to the community on HN for example. No one cares about convincing you that OCaml is ready for production use. It doesn't need to be argued, it can just be shown. OCaml is not an up and coming language, it's a 25 years old one. It powers a lot of Jane Street infrastructure. It is used to develop Coq and Frama-C. It is transpiled to javascript at Facebook and Bloomberg. Heck, Rust which you apparently hold dear was originally written in it.

Well for example in the upcoming 4.12, the core team has integrated plenty of "practical" language features (such as support for iOS/OSX ARM64, or many changes related to multicore).

throwaway894345 6y ago

No doubt, but why are there still so many “standard” libraries? Where are is of the guides for building production applications? Why is the documentation so poor? How do the editor plugins compare to those for Go, Rust, etc? How familiar is the syntax to the broader body of developers? I’m not saying the Ocaml community never does anything practical; only that they don’t do enough to make their language mainstream. And maybe they don’t want their language to be mainstream—that’s perfectly fine, but that undermines all of the arguments that this or that project should be (re)written in Ocaml or that Ocaml is otherwise a better language than $x for general software development.

yawaramin 6y ago
> why are there still so many “standard” libraries? There is one standard library--the one that ships with OCaml. You can use replacement libraries if you really need them--I haven't yet needed to, but for heavy-duty production use maybe one day I will. > Where are is of the guides for building production applications? Is the emphasis on 'building' here, as in 'build tool'? If so, then https://dune.build/ https://dune.build/ is what you need. If the emphasis is on 'production application', then I'm sure there are others but https://shonfeder.gitlab.io/ocaml_webapp/ https://shonfeder.gitlab.io/ocaml_webapp/ comes to mind immediately. > Why is the documentation so poor? Which documentation specifically? If you mean OCaml itself, then you should check out https://ocaml.org/ https://ocaml.org/ , it has tons of high-quality documentation. If you mean third-party libraries, then it's probably mostly a lack of tooling that publishes docs automatically, but I think this is starting to change. > How do the editor plugins compare to those for Go, Rust, etc? The OCaml Language Server and its main editor plugin (for VSCode) are nearly feature-complete. The older Merlin tooling has been used for a long time. > How familiar is the syntax to the broader body of developers? Syntax can be learned, but for those who don't want to try, there is always ReasonML syntax that uses semicolons and curly braces to make OCaml look like JavaScript. > I’m not saying the Ocaml community never does anything practical; only that they don’t do enough to make their language mainstream. It's easy to make assertions without actually knowing anything, but it's better to do the research first to back them up, instead of asking a bunch of questions ;-)
- throwaway894345 6y ago
  > There is one standard library--the one that ships with OCaml. You can use replacement libraries if you really need them--I haven't yet needed to, but for heavy-duty production use maybe one day I will. You're mistaken (or you're making an unrelated semantic argument because you don't want to argue the actual point; not sure which); there are multiple "standard" libraries used across the ecosystem (because the ecosystem has deemed "the one that ships with OCaml" to be inadequate) which makes integrating libraries throughout the ecosystem tedious and painful, especially to new OCaml developers. > Is the emphasis on 'building' here, as in 'build tool'? No, I expect an abundance of tutorials that explain how to build production-grade applications, soup to nuts. E.g., for a generic CRUD app, what are the best frameworks, ORMs, etc to use, how to integrate them, etc? > The older Merlin tooling has been used for a long time. Yes, but it's incredibly difficult to configure properly, or at least that was my experience when I got started. I'm actually not sure if I ever got it working with vim. > Syntax can be learned, but for those who don't want to try, there is always ReasonML syntax that uses semicolons and curly braces to make OCaml look like JavaScript. It can, but it's a burden with no advantage. Last I checked, ReasonML's support was pretty abysmal--it seemed like native compilation was neglected altogether in favor of something called "bucklescript" (presumably compilation to JS) and the integrations with the rest of the ecosystem (e.g., how to build native programs, link against ocaml dependencies, integrate with editor tools, etc) were either poorly documented or inadequate/incomplete or both. No doubt some of that has improved in the intervening years, but I'm doubtful that it has significantly improved. > It's easy to make assertions without actually knowing anything, but it's better to do the research first to back them up, instead of asking a bunch of questions ;-) You've provided the same unhelpful, pat answers that the OCaml community provides. For example, "Just use ReasonML!" as though setting up or using Reason is trivial or well documented or otherwise comparable to using Rust or Go out of the box. For another example, you altogether dodged the issues associated with multiple "standard" libraries. It would be great if the OCaml community were as committed to making their language useful for production applications as they were on convincing everyone else that it already was.
  - brmgb 6y ago
    > as though setting up or using Reason is trivial or well documented It's both trivial and well documented. There is an installation page and a tutorial on the Reason website. The installation in itself is one npm command. > For another example, you altogether dodged the issues associated with multiple "standard" libraries. There is only one standard library. It's the one shipped with the compiler. It is also significantly more battery included now than it used to be. > It would be great if the OCaml community were as committed to making their language useful for production applications as they were on convincing everyone else that it already was. The OCaml community as a whole is one of the least vocal on the internet. It does very little outreach. I never see any of the people I consider relevant to the community on HN for example. No one cares about convincing you that OCaml is ready for production use. It doesn't need to be argued, it can just be shown. OCaml is not an up and coming language, it's a 25 years old one. It powers a lot of Jane Street infrastructure. It is used to develop Coq and Frama-C. It is transpiled to javascript at Facebook and Bloomberg. Heck, Rust which you apparently hold dear was originally written in it.