3 ms·

I'm looking at Ocaml again because of the existence (and quality) of the Bucklescript backend for Javscript. That makes Ocaml sound pretty attractive on the po

I'm looking at Ocaml again because of the existence (and quality) of the Bucklescript backend for Javscript. That makes Ocaml sound pretty attractive on the portability front. A question for anybody here regarding portability: Is it viable to maintain a portable core using a subset of Ocaml (something like Standard ML maybe - no objects) and compile that in F# using Ocaml portability mode? For context, I've read this question on SO from 2010 [0] but I'm looking for some more 2018 perspectives from HN people. [0] https://stackoverflow.com/questions/4239121/code-compatibility-between-ocaml-and-f https://stackoverflow.com/questions/4239121/code-compatibili...

nv-vn 8y ago
Most likely not. You could get away writing a lot of utility type functions between the two, but the libraries, async scene, module system, object system, etc. vary enough that it would be practically impossible to share any non-trivial piece of code. Which isn't to say that porting anything would be hard, most of the core code would stay there and you'd only really adjust the edges of your code so to speak--if you separate out access to libraries or try to port the APIs from one language to another (which would be easy in OCaml with it's module system) it would certainly be possible to share 90% or more of your core code. But for example, you'd have to avoid using async/await in F# and instead opt for some library that has surface-level compatibility with OCaml's Async or LWT and working with .NET libs would require you writing wrappers for the OCaml standard library.
- delhanty 8y ago
  Thank you. >it would certainly be possible to share 90% or more of your core code. It sounds like maintaining parallel code bases in Ocaml and F# with the same basic design and file layout might work quite well for the core.
yawaramin 8y ago
That answer hasn't changed, in fact as of today OCaml and F# have diverged more than they had back then. BuckleScript and ReasonML are solid for the frontend, though. I would recommend them without hesitation. For the backend, F# could be nice but as I mentioned, you would share almost nothing between them. If you're looking for a universal (i.e. same language on BE/FE) stack there are many options today, but a classic one is https://ocsigen.org/eliom/ https://ocsigen.org/eliom/
- delhanty 8y ago
  Thanks very much for that perspective and the link. It certainly sounds more attractive than writing everything in Javascript and using Node! I'm interested in writing a portable, commercial 3D CAD modeling library. F# has already been used commercially for some years for 3D CAD on Windows. So F#, when compared with Ocaml, is a relatively easy sell into that market as it doesn't add another dependency.
- kbd 8y ago
  > but a classic one is https://ocsigen.org/eliom/ https://ocsigen.org/eliom/ I didn't know there were any other attempts at a "universal" platform since Meteor. Thanks for sharing! Please let me know if there are others that you think are worth learning.
  - Bogdanp 8y ago
    You may want to check out Ur/Web as well.
  - yawaramin 8y ago
    Sure :-) Another one I admire is http://opalang.org/ http://opalang.org/ . It too is based on OCaml, funnily enough. The last commit is from last year, though, so this is not a project on the rise. Here's one for Scala (and Scala.js): https://udash.io/ https://udash.io/ . It has a lot of cool concepts, like out-of-the-box push notification support with WebSockets. And I am more familiar with Scala than anything else so it is attractive. The only thing that gives me pause is that I've used Scala.js in the past, and its compile times are not something I want to deal with again after using faster transpilers like BuckleScript. Finally, the one I'm keeping my eye on is https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera... . The idea here is to serve static HTML with a minimal bit of JavaScript needed to maintain a live connection to the server, over a WebSocket, and drive dynamism that way. Think React+Redux, but driven from the server side. The client can be mostly a dumb client again. This one has a promising future, with lots of optimizations and benefits falling out of using the Erlang runtime properly.
ernst_klim 8y ago
>A question for anybody here regarding portability: Is it viable to maintain a portable core using a subset of Ocaml (something like Standard ML maybe - no objects) and compile that in F# using Ocaml portability mode? Both F# and OCaml have a lot of great features and peculiarities, and it's not worth of ignoring them for the sake of portability unless you use F# and OCaml as an intermediate language, as F* people do. Just choose a more suitable language for your needs and use it.

nv-vn 8y ago

Most likely not. You could get away writing a lot of utility type functions between the two, but the libraries, async scene, module system, object system, etc. vary enough that it would be practically impossible to share any non-trivial piece of code. Which isn't to say that porting anything would be hard, most of the core code would stay there and you'd only really adjust the edges of your code so to speak--if you separate out access to libraries or try to port the APIs from one language to another (which would be easy in OCaml with it's module system) it would certainly be possible to share 90% or more of your core code. But for example, you'd have to avoid using async/await in F# and instead opt for some library that has surface-level compatibility with OCaml's Async or LWT and working with .NET libs would require you writing wrappers for the OCaml standard library.

delhanty 8y ago
Thank you. >it would certainly be possible to share 90% or more of your core code. It sounds like maintaining parallel code bases in Ocaml and F# with the same basic design and file layout might work quite well for the core.

yawaramin 8y ago

That answer hasn't changed, in fact as of today OCaml and F# have diverged more than they had back then. BuckleScript and ReasonML are solid for the frontend, though. I would recommend them without hesitation. For the backend, F# could be nice but as I mentioned, you would share almost nothing between them. If you're looking for a universal (i.e. same language on BE/FE) stack there are many options today, but a classic one is https://ocsigen.org/eliom/ https://ocsigen.org/eliom/

delhanty 8y ago
Thanks very much for that perspective and the link. It certainly sounds more attractive than writing everything in Javascript and using Node! I'm interested in writing a portable, commercial 3D CAD modeling library. F# has already been used commercially for some years for 3D CAD on Windows. So F#, when compared with Ocaml, is a relatively easy sell into that market as it doesn't add another dependency.
kbd 8y ago
> but a classic one is https://ocsigen.org/eliom/ https://ocsigen.org/eliom/ I didn't know there were any other attempts at a "universal" platform since Meteor. Thanks for sharing! Please let me know if there are others that you think are worth learning.
- Bogdanp 8y ago
  You may want to check out Ur/Web as well.
- yawaramin 8y ago
  Sure :-) Another one I admire is http://opalang.org/ http://opalang.org/ . It too is based on OCaml, funnily enough. The last commit is from last year, though, so this is not a project on the rise. Here's one for Scala (and Scala.js): https://udash.io/ https://udash.io/ . It has a lot of cool concepts, like out-of-the-box push notification support with WebSockets. And I am more familiar with Scala than anything else so it is attractive. The only thing that gives me pause is that I've used Scala.js in the past, and its compile times are not something I want to deal with again after using faster transpilers like BuckleScript. Finally, the one I'm keeping my eye on is https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera... . The idea here is to serve static HTML with a minimal bit of JavaScript needed to maintain a live connection to the server, over a WebSocket, and drive dynamism that way. Think React+Redux, but driven from the server side. The client can be mostly a dumb client again. This one has a promising future, with lots of optimizations and benefits falling out of using the Erlang runtime properly.

ernst_klim 8y ago

>A question for anybody here regarding portability: Is it viable to maintain a portable core using a subset of Ocaml (something like Standard ML maybe - no objects) and compile that in F# using Ocaml portability mode? Both F# and OCaml have a lot of great features and peculiarities, and it's not worth of ignoring them for the sake of portability unless you use F# and OCaml as an intermediate language, as F* people do. Just choose a more suitable language for your needs and use it.