Closed ELLIOTTCABLE closed 6 years ago
rgrinberg
commented
6 years ago The future for opium is to move to httpaf rather than cohttp. I don't see a good use case for running OCaml on top of node for webservers so I'm not convinced that we need to make things more generic than that. Do you have any reasons to run ocaml on node on the server?
As for ppx, the bucklescript's team regarding ppx is quite reasonable given their lack of a working ppx stack.
ELLIOTTCABLE
commented
6 years ago Library usage! I'd like to be able to safely write idiomatic OCaml code, and expect to be able to release it as widely-cross-platform as can be done.
For instance, if some user wants to use bindings to an existing webservice, those are much more likely to be ‘already done’ effort in the wider JS ecosystem. I'm sure compiling whatever tiny microservice via the asmcomp may lead to a faster resulting binary; but depending on how many things the end-user is integrating, there's a strong chance they'll save human time by targeting the JS ecosystem (which, server-side, means Node.) With BuckleScript, for better or for worse, there's more and more JavaScript users looking to take advantage of existing OCaml work; and it's pretty clear to me that, moving forward, it can only be a good thing to abstract popular OCaml libraries across C-FFI backends and JS-FFI backends.
I only asked because it seemed to already be on your roadmap, though — I'm not even an httpaf user, yet, so don't bother wasting development time on this just yet. Like I said, if you're already considering a backend that can be swapped out, well — maybe consider Node's APIs as one possible backend, when designing the rearward-facing expectations thereof!
Re: PPXes, from everything I've seen, the causal relationship is the other way around. I think they're a bit “wait and see why we should bother with this” re: improving the working-experience of applying ppx across BuckleScript codebases. I could be wrong. ¯\_(ツ)_/¯
rgrinberg
commented
6 years ago Thanks for your interest, but I'm closing this. Not because I think that targeting the JS ecosystem as bad, it's just that I'm not sure that Opium should be the lib that should be doing these compromises. For example, one of the problems that would need to be solved is a framework independent set of http types. Given that opium doesn't even define its own types for this, I don't really think it's in the position to solve issues such as this.
ELLIOTTCABLE
commented
6 years ago Strong decisions are strong leadership! You do you, 'tainer! <3
So, this is more of a tracking topic than an immediately-relevant feature-request; but I'm curious what would be required to abstract opium away from cohttp, and make it eventually compileable to JavaScript via BuckleScript.
It sounds like this is on your mind already, based on your choice of LWT / this comment, so that's exciting!
Aside from splitting out the cohttp requirement so it can run on top of JavaScript / Node.js APIs, the biggest blocker right now seems to be the heavy dependence on PPX extensions. I'm assuming this is an inflexible requirement? If so, maybe an explicit ‘I'd love to support BuckleScript and Reason, but we need support for idiomatic OCaml code, which means we need PPXes.’ from you is something I can take back to the BuckleScript team, and start to convince them to relax their position against PPX.
(=Let me know if this is on the roadmap!