5 ms·

Except that OCaml is still (for the foreseeable future) single-core only, just like Python, yet it doesn't have the ecosystem Python has. How many good database

Except that OCaml is still (for the foreseeable future) single-core only, just like Python, yet it doesn't have the ecosystem Python has. How many good database drivers are there for OCaml? How good are the web frameworks? If I wanted to write a Kafka consumer in OCaml, which battle-tested library would I pick? If I wanted to send an email through {MailGun, SendGrid, Postmarkapp}, are there any integrations that help with that? Even an example of an echo server doesn't look that appealing: https://dev.realworldocaml.org/concurrent-programming.html#improving-the-echo-server https://dev.realworldocaml.org/concurrent-programming.html#i... But, perhaps that is just unfamiliarity on my part. Rust was heavily influenced by some of OCaml's choices, but they chose to make the syntax more familiar and approachable to people coming from the mainstream programming world, although it does have its own quirks. With Go and Rust as options, I'm not sure why someone would pick OCaml in 2019. In 2014, when that article was written, Go and Rust were both much less mature. I hear ReasonML/OCaml could be interesting for frontend work, but frontend is not my specialty. Honestly, as easy as it is to hate on the npm ecosystem, Node.js can run circles around Python in performance, and TypeScript offers a pretty nice type system. If someone just wants a "better Python" for web-related stuff, TypeScript on the backend might be a good option, although I personally lean towards Rust and Go, depending on the project.

yawaramin 8y ago
Being 'single-core only' is not that much of a problem if you're coming from Python and immediately seeing a huge performance boost compiling to Go-style static native binaries, I think? People immediately jump on the 'single-core' thing with OCaml, but can you explain what exactly it is that you're trying to do with multicore that's not covered by a concurrency library like Lwt or a multi-processing library like Async Parallel? Re: database drivers–which one are you looking for? MSSQL ( https://discuss.ocaml.org/t/ann-first-release-of-mssql/3242 https://discuss.ocaml.org/t/ann-first-release-of-mssql/3242 )? Or Postgres ( http://mmottl.github.io/postgresql-ocaml/ http://mmottl.github.io/postgresql-ocaml/ )? Or SQLite ( https://github.com/mmottl/sqlite3-ocaml https://github.com/mmottl/sqlite3-ocaml )? Re: web frameworks–Eliom ( https://ocsigen.org/eliom/6.6/manual/intro https://ocsigen.org/eliom/6.6/manual/intro ) is one of the most powerful isomorphic web frameworks. Or do you want to spin up a quick JSON API server with Cohttp ( https://github.com/mirage/ocaml-cohttp https://github.com/mirage/ocaml-cohttp )? Or dig into a high-performance, lower-level server ( https://github.com/inhabitedtype/httpaf https://github.com/inhabitedtype/httpaf )? Or you want a Kafka client ( https://opam.ocaml.org/packages/kafka/ https://opam.ocaml.org/packages/kafka/ )? Or maybe you can just take advantage of BuckleScript's high-fidelity approach to transpiling OCaml to JavaScript, and write some bindings to take advantage of basically everything in the npm ecosystem? Sure, not every OCaml library is battle-tested, but I think that's not a good reason to immediately discount it. I didn't tell StavrosK to immediately commit to and rewrite everything in OCaml, I said he might find it interesting. Even with Go, Rust, and TypeScript as options, because: - Not everyone is satisfied with Go's type system or its model of error handling, or its low ceiling for abstraction. - Not everyone is satisfied with Rust's overall newness and potential compiler and library bugs, its lack of GC and the subsequent having to deal with borrow checking, or its slow compile times. - Not everyone is satisfied with trying to model the dynamic complexity of JavaScript in a new, explicitly unsound type system. And it's no secret that the BuckleScript compiler can run rings around tsc for compile speed (not even mentioning the more powerful and battle-tested OCaml language).
- coder543 8y ago
  Multicore is important because it allows as close to perfect resource utilization as you can get on each machine. When you spin up separate processes, you end up with separate connection pools to every other service (such as databases, mail providers, etc.) which is measurably wasteful, but more importantly, you never efficiently utilize your CPU. I've personally witnessed this with Ruby deployments. You can spin up a server per core, but then you always leave some small percent on the table. So then you could spin up more than one per core, but then you're introducing additional resource contention and scheduler overhead, not to mention even more connection pools. Each process also has its own separate garbage collector, which is less efficient than just having a single GC. These are only a few things, and only discussing IO bound tasks. Once you start doing CPU intensive stuff, the problems are just made worse, especially if you want to spin off background jobs to work on things after finishing a request. I know that a library of some kind has been written for each thing that I mentioned, but that doesn't make them ergonomic or reliable. The last time that I researched this, everyone discussing their experiences trying to use Postgres from OCaml had nothing good to say. The TechEmpower benchmarks don't even include a single entry with OCaml, simply because no one has submitted one, which speaks volumes about the size and maturity of the state of writing a web server in OCaml. For business critical functions like your database driver and your web server libraries, being battle tested is very important. The Rust compiler is plenty mature, it's built on LLVM, and has had years of real world use by a growing number of companies. The Rust community places more emphasis on stability than any other I've been part of. But, the async story and web server stories are not currently mature, which is why I'm happy to use Go for those things. Actix is as close to mature as those things get in Rust right now, and it's not up to my standards yet. For someone to be so upset with all three of those languages on those counts that they decide to shoulder the burdens OCaml brings... that would be surprising. I had already pointed out that OCaml on the web has become a niche thanks to ReasonML (where BuckleScript is the compiler), especially since the web is predominantly single core. "Explicitly unsound" is pretty funny to me. TypeScript has a really strong type system. To say otherwise as a negative thing at this point is to be purely pedantic in the most academic of ways, in my opinion.
  - yawaramin 8y ago
aldanor 8y ago
> I'm not sure why someone would pick OCaml in 2019 You definitely would if you already have millions of LoC in OCaml.. like Jane Street does. For a random person, I would agree. I tried it myself for a few personal projects (I know Rust/Python/C++/Haskell reasonably well) and couldn't get myself to like it, subjectively.

yawaramin 8y ago

Being 'single-core only' is not that much of a problem if you're coming from Python and immediately seeing a huge performance boost compiling to Go-style static native binaries, I think? People immediately jump on the 'single-core' thing with OCaml, but can you explain what exactly it is that you're trying to do with multicore that's not covered by a concurrency library like Lwt or a multi-processing library like Async Parallel? Re: database drivers–which one are you looking for? MSSQL ( https://discuss.ocaml.org/t/ann-first-release-of-mssql/3242 https://discuss.ocaml.org/t/ann-first-release-of-mssql/3242 )? Or Postgres ( http://mmottl.github.io/postgresql-ocaml/ http://mmottl.github.io/postgresql-ocaml/ )? Or SQLite ( https://github.com/mmottl/sqlite3-ocaml https://github.com/mmottl/sqlite3-ocaml )? Re: web frameworks–Eliom ( https://ocsigen.org/eliom/6.6/manual/intro https://ocsigen.org/eliom/6.6/manual/intro ) is one of the most powerful isomorphic web frameworks. Or do you want to spin up a quick JSON API server with Cohttp ( https://github.com/mirage/ocaml-cohttp https://github.com/mirage/ocaml-cohttp )? Or dig into a high-performance, lower-level server ( https://github.com/inhabitedtype/httpaf https://github.com/inhabitedtype/httpaf )? Or you want a Kafka client ( https://opam.ocaml.org/packages/kafka/ https://opam.ocaml.org/packages/kafka/ )? Or maybe you can just take advantage of BuckleScript's high-fidelity approach to transpiling OCaml to JavaScript, and write some bindings to take advantage of basically everything in the npm ecosystem? Sure, not every OCaml library is battle-tested, but I think that's not a good reason to immediately discount it. I didn't tell StavrosK to immediately commit to and rewrite everything in OCaml, I said he might find it interesting. Even with Go, Rust, and TypeScript as options, because: - Not everyone is satisfied with Go's type system or its model of error handling, or its low ceiling for abstraction. - Not everyone is satisfied with Rust's overall newness and potential compiler and library bugs, its lack of GC and the subsequent having to deal with borrow checking, or its slow compile times. - Not everyone is satisfied with trying to model the dynamic complexity of JavaScript in a new, explicitly unsound type system. And it's no secret that the BuckleScript compiler can run rings around tsc for compile speed (not even mentioning the more powerful and battle-tested OCaml language).

coder543 8y ago
Multicore is important because it allows as close to perfect resource utilization as you can get on each machine. When you spin up separate processes, you end up with separate connection pools to every other service (such as databases, mail providers, etc.) which is measurably wasteful, but more importantly, you never efficiently utilize your CPU. I've personally witnessed this with Ruby deployments. You can spin up a server per core, but then you always leave some small percent on the table. So then you could spin up more than one per core, but then you're introducing additional resource contention and scheduler overhead, not to mention even more connection pools. Each process also has its own separate garbage collector, which is less efficient than just having a single GC. These are only a few things, and only discussing IO bound tasks. Once you start doing CPU intensive stuff, the problems are just made worse, especially if you want to spin off background jobs to work on things after finishing a request. I know that a library of some kind has been written for each thing that I mentioned, but that doesn't make them ergonomic or reliable. The last time that I researched this, everyone discussing their experiences trying to use Postgres from OCaml had nothing good to say. The TechEmpower benchmarks don't even include a single entry with OCaml, simply because no one has submitted one, which speaks volumes about the size and maturity of the state of writing a web server in OCaml. For business critical functions like your database driver and your web server libraries, being battle tested is very important. The Rust compiler is plenty mature, it's built on LLVM, and has had years of real world use by a growing number of companies. The Rust community places more emphasis on stability than any other I've been part of. But, the async story and web server stories are not currently mature, which is why I'm happy to use Go for those things. Actix is as close to mature as those things get in Rust right now, and it's not up to my standards yet. For someone to be so upset with all three of those languages on those counts that they decide to shoulder the burdens OCaml brings... that would be surprising. I had already pointed out that OCaml on the web has become a niche thanks to ReasonML (where BuckleScript is the compiler), especially since the web is predominantly single core. "Explicitly unsound" is pretty funny to me. TypeScript has a really strong type system. To say otherwise as a negative thing at this point is to be purely pedantic in the most academic of ways, in my opinion.
- yawaramin 8y ago

aldanor 8y ago

> I'm not sure why someone would pick OCaml in 2019 You definitely would if you already have millions of LoC in OCaml.. like Jane Street does. For a random person, I would agree. I tried it myself for a few personal projects (I know Rust/Python/C++/Haskell reasonably well) and couldn't get myself to like it, subjectively.