Hacker News Reader

Comment by tieTYT | Hacker News Reader

What made me give up on Haskell was all the libraries had native linux bindings. It was hell reusing code if you're developing on windows (and I've heard this is true on macs, too). Does OCaml have this issue?

View on HN

Unix support is definitely better than Windows. That said, the core language and base libraries are pretty portable. Here's one nice retrospective on a move from Python to OCaml for a program that needed portability to Windows as a fundamental concern.

http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

Probably the biggest problem on Windows is that OPAM, the package manager, doesn't work there. That will come eventually, though.

> Probably the biggest problem on Windows is that OPAM, the package manager, doesn't work there. That will come eventually, though

Wodi [1] is a reasonable choice until OPAM starts supporting Windows. It includes many of the interesting/useful libraries (including, importantly, batteries [2] and core [3])

[1] http://wodi.forge.ocamlcore.org/ [2] http://batteries.forge.ocamlcore.org/ [3] https://github.com/janestreet/core_kernel

> Probably the biggest problem on Windows is that OPAM, the package manager, doesn't work there. That will come eventually, though.

Any ETA on it? If I knew about it before buying the book, I would not have done it.

The book is great, but as it is I have better luck with F# at work.

I think it really depends on the application domain. A lot of Haskell (for example most of the web frameworks) doesn't have the problem you mentioned - but GUIs and numerics systems probably do. I would guess the same may be true for OCaml. If I were developing on Windows though I would probably lean towards F# over OCaml though...Visual Studio is an amazing IDE.

I want the "write once, run anywhere" that Java gives me. I guess I'm just spoiled, but it's what I've come to expect.

Java's "write once, run anywhere" comes with a lot of costs that many programming language designers aren't willing to pay. It's not just about the JVM (which by itself prevents Java from running on some devices), it requires Java to adopt a "lowest-common-denominator" approach when it comes to supporting platform-specific features, and often go to great lengths to appear to support features that are easy on one platform but hard on others. As an example, look how long it took Java to even support something as basic as PIDs thanks to cross-platform compatibility concerns. Given that .NET has plenty of excellent languages in its own right, I suspect it will be a long time before we see another language willing to restrict itself as heavily as Java has in order to attain this utopic ideal.

(Personally, I don't really think it's worth it--many libraries that need to get stuff done in Java end up using JNA anyway, negating this supposed advantage. But it's certainly much better about it than ostensibly cross-platform languages like Ruby are).

Ocaml has a bytecode compiler and a native code compiler; any library written in OCaml can be compiled to run-anywhere bytecode, though I'm not sure how many libraries are really just wrappers around native GNU/Linux libraries.

Reply on news.ycombinator.com