3 ms·

OCaml was my first serious language, and while I think it's a bit weak for "programming in the large" (cumbersome types, typeclasses, lack of type annotations s

by tomp 7y ago

OCaml was my first serious language, and while I think it's a bit weak for "programming in the large" (cumbersome types, typeclasses, lack of type annotations sometimes hurts) I'm still incredibly fond of it. Unfortunately, I haven't had much experience using it recently, as most of my work is in Python / Scala etc. I'm assuming you're a current, up-to-date user, so I'd like to ask you: - what are the current reasonable options for a StdLib? Last I checked, the default lib was still very poor, while JaneStreet's I found barely documented. - Multicore I guess I can forgive, it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java). - What's an example of a recent codebase written in "modern" OCaml / Reason?

osener 7y ago
I've been writing a lot for Reason and OCaml last few years, but the majority of it target BuckleScript and React. My front-end bias alone means it's a better stack than any other alternatives mentioned in this thread (and I even find it more productive than TypeScript), so take it with a grain of salt. I do use ocaml-graphql-server and such a lot to write small services, but I often don't interact with databases or build complex backends that would require a bigger back-end webdev ecosystem. Most of my native development happens far from the cloud, and mostly around CLI and GUI tools for which I adore OCaml and recently Reason (https://github.com/revery-ui/revery https://github.com/revery-ui/revery). > cumbersome types, typeclasses, lack of type annotations sometimes hurts I've grown to really like the explicitness of OCaml actually. Nothing implicit or circular, and I can just read a module from top to bottom. The lack of type annotations don't bother me as much with tools such as Merlin, and I find that the amazing type inference lets me prototype code as fast as dynamic languages. > - what are the current reasonable options for a StdLib? Last I checked, the default lib was still very poor, while JaneStreet's I found barely documented. I use Containers (https://github.com/c-cube/ocaml-containers/ https://github.com/c-cube/ocaml-containers/), Lwt, and a few other small libraries like Rresult and Bos pretty heavily. For a big application with many contributors I'd still suggest giving Core another try as it's very well thought out and extensive (compared to npm-style dozens of dependencies you need to introduce with different API designs). I must say that even though I'm pretty used to reading type signatures and jumping to interface files for documentation (and even prefer it to tutorial style docs in markdown), and wouldn't say Core's documentation is _poor_, I agree with you at some level. Because of how it's built and split up across different packages and modules, it gets pretty tiring having to power through many levels of indirection every time you want to look something up. > - Multicore I guess I can forgive, it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java). I find that, compared to some other languages I've used, my naive and readable implementation in OCaml last much longer before I need to optimize it. I do use Lwt_preemptive threads that call C code and subprocesses often, but usually because of the nature of the problem I'm solving and not as a parallelization technique. > - What's an example of a recent codebase written in "modern" OCaml / Reason? Most open source projects I can think of are libraries and tools such as compilers, but here are some real-world applications off the top of my head: - https://github.com/onivim/oni2 https://github.com/onivim/oni2 (native, desktop) - https://github.com/SVdotCO/pupilfirst https://github.com/SVdotCO/pupilfirst (bucklescript, react) - https://github.com/Schniz/fnm https://github.com/Schniz/fnm (native, CLI) Some of the cool stuff I saw in the wild: https://github.com/osener?language=reason&tab=stars https://github.com/osener?language=reason&tab=stars https://github.com/osener?language=ocaml&tab=stars https://github.com/osener?language=ocaml&tab=stars Hope this helps! I think with the recent convergence around tools such as dune, opam, esy, it is a great time to start writing OCaml again.
jasim 7y ago
Here is a non-trivial production web application (a learning management system) that runs Rails on the back-end, GraphQL for network communication, and Reason on the front-end: https://github.com/svdotCO/pupilfirst https://github.com/svdotCO/pupilfirst
azakai 7y ago
> it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java). Go is another exception, goroutines are a core part of the design.
- mr_luc 7y ago
  BEAM languages too.
pjmlp 7y ago
Multicore will eventually come, however in the age of Spectre and Meltdown, alongside in-process exploits and browsers going into multi-processes for security and stability reasons, I don't find that bad about multi-process usage. And there is always Lwt as well. Regarding your mention of Java, count .NET and Erlang there as well.
yawaramin 7y ago
> I think it's a bit weak for "programming in the large" Really have to disagree with this one, for programming in the large the best tool you have is modularization, and OCaml's module implementation is second to none. > (cumbersome types, This is usually an indication of trying to program OCaml 'like Haskell' or some other language, instead of learning the OCaml way. > typeclasses, Matter of opinion but I honestly think not having return-type polymorphism, and having a slightly more explicit model, actually works in OCaml's favour–faster compile times, more explicit type errors, less 'magical-looking' code that's easier to follow. > lack of type annotations sometimes hurts) Sometimes–but the idiom is very much to put type annotations in separate interface files, which I think is the best of both worlds–implementations look clutter-free and almost dynamic; and interfaces are explicitly typed and documented. > Last I checked, the default lib was still very poor, I encourage checking again, the default standard library has received a lot of updates. Of course there may be a difference of philosophy here, the OCaml standard library is not Go-style. In other words, it's not going to ship a JSON decoder and an HTTP server. But very high-quality packages are available on OPAM nowadays so IMHO this is not really a big deal. > Multicore I guess I can forgive, OK, great! ;-) > What's an example of a recent codebase written in "modern" OCaml / Reason? Well I'm working on an OCaml/Reason web framework written in a pretty modern OCaml style: https://github.com/yawaramin/re-web https://github.com/yawaramin/re-web
sideeffffect 7y ago
> Multicore I guess I can forgive, it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java) Couldn't agree more, Scala with Monix/cats-effect/fs2 excels at writing highly efficient parallel and concurrent programs
AlexCoventry 7y ago
> it's not like there are any other modern GC languages that make multi-threading particularly easy Where does golang fit, in this picture?
- tomp 7y ago
  I forgot about Go. They actually did some really great work on their GC! Plus decent support for lightweight & actual threads. I just so strongly dislike the language itself (mainly because of the poor type system) that I must have suppressed it :)

by tomp 7y ago

osener 7y ago

I've been writing a lot for Reason and OCaml last few years, but the majority of it target BuckleScript and React. My front-end bias alone means it's a better stack than any other alternatives mentioned in this thread (and I even find it more productive than TypeScript), so take it with a grain of salt. I do use ocaml-graphql-server and such a lot to write small services, but I often don't interact with databases or build complex backends that would require a bigger back-end webdev ecosystem. Most of my native development happens far from the cloud, and mostly around CLI and GUI tools for which I adore OCaml and recently Reason (https://github.com/revery-ui/revery https://github.com/revery-ui/revery). > cumbersome types, typeclasses, lack of type annotations sometimes hurts I've grown to really like the explicitness of OCaml actually. Nothing implicit or circular, and I can just read a module from top to bottom. The lack of type annotations don't bother me as much with tools such as Merlin, and I find that the amazing type inference lets me prototype code as fast as dynamic languages. > - what are the current reasonable options for a StdLib? Last I checked, the default lib was still very poor, while JaneStreet's I found barely documented. I use Containers (https://github.com/c-cube/ocaml-containers/ https://github.com/c-cube/ocaml-containers/), Lwt, and a few other small libraries like Rresult and Bos pretty heavily. For a big application with many contributors I'd still suggest giving Core another try as it's very well thought out and extensive (compared to npm-style dozens of dependencies you need to introduce with different API designs). I must say that even though I'm pretty used to reading type signatures and jumping to interface files for documentation (and even prefer it to tutorial style docs in markdown), and wouldn't say Core's documentation is _poor_, I agree with you at some level. Because of how it's built and split up across different packages and modules, it gets pretty tiring having to power through many levels of indirection every time you want to look something up. > - Multicore I guess I can forgive, it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java). I find that, compared to some other languages I've used, my naive and readable implementation in OCaml last much longer before I need to optimize it. I do use Lwt_preemptive threads that call C code and subprocesses often, but usually because of the nature of the problem I'm solving and not as a parallelization technique. > - What's an example of a recent codebase written in "modern" OCaml / Reason? Most open source projects I can think of are libraries and tools such as compilers, but here are some real-world applications off the top of my head: - https://github.com/onivim/oni2 https://github.com/onivim/oni2 (native, desktop) - https://github.com/SVdotCO/pupilfirst https://github.com/SVdotCO/pupilfirst (bucklescript, react) - https://github.com/Schniz/fnm https://github.com/Schniz/fnm (native, CLI) Some of the cool stuff I saw in the wild: https://github.com/osener?language=reason&tab=stars https://github.com/osener?language=reason&tab=stars https://github.com/osener?language=ocaml&tab=stars https://github.com/osener?language=ocaml&tab=stars Hope this helps! I think with the recent convergence around tools such as dune, opam, esy, it is a great time to start writing OCaml again.

jasim 7y ago

Here is a non-trivial production web application (a learning management system) that runs Rails on the back-end, GraphQL for network communication, and Reason on the front-end: https://github.com/svdotCO/pupilfirst https://github.com/svdotCO/pupilfirst

azakai 7y ago

> it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java). Go is another exception, goroutines are a core part of the design.

mr_luc 7y ago
BEAM languages too.

pjmlp 7y ago

Multicore will eventually come, however in the age of Spectre and Meltdown, alongside in-process exploits and browsers going into multi-processes for security and stability reasons, I don't find that bad about multi-process usage. And there is always Lwt as well. Regarding your mention of Java, count .NET and Erlang there as well.

yawaramin 7y ago

> I think it's a bit weak for "programming in the large" Really have to disagree with this one, for programming in the large the best tool you have is modularization, and OCaml's module implementation is second to none. > (cumbersome types, This is usually an indication of trying to program OCaml 'like Haskell' or some other language, instead of learning the OCaml way. > typeclasses, Matter of opinion but I honestly think not having return-type polymorphism, and having a slightly more explicit model, actually works in OCaml's favour–faster compile times, more explicit type errors, less 'magical-looking' code that's easier to follow. > lack of type annotations sometimes hurts) Sometimes–but the idiom is very much to put type annotations in separate interface files, which I think is the best of both worlds–implementations look clutter-free and almost dynamic; and interfaces are explicitly typed and documented. > Last I checked, the default lib was still very poor, I encourage checking again, the default standard library has received a lot of updates. Of course there may be a difference of philosophy here, the OCaml standard library is not Go-style. In other words, it's not going to ship a JSON decoder and an HTTP server. But very high-quality packages are available on OPAM nowadays so IMHO this is not really a big deal. > Multicore I guess I can forgive, OK, great! ;-) > What's an example of a recent codebase written in "modern" OCaml / Reason? Well I'm working on an OCaml/Reason web framework written in a pretty modern OCaml style: https://github.com/yawaramin/re-web https://github.com/yawaramin/re-web

sideeffffect 7y ago

> Multicore I guess I can forgive, it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java) Couldn't agree more, Scala with Monix/cats-effect/fs2 excels at writing highly efficient parallel and concurrent programs

AlexCoventry 7y ago

> it's not like there are any other modern GC languages that make multi-threading particularly easy Where does golang fit, in this picture?

tomp 7y ago
I forgot about Go. They actually did some really great work on their GC! Plus decent support for lightweight & actual threads. I just so strongly dislike the language itself (mainly because of the poor type system) that I must have suppressed it :)