
OCaml in Operations - dwc
https://michipili.github.io/essay/2016/04/11/ocaml-on-operations.html
======
seliopou
One clarification. As of a couple weeks ago, OCaml does have native support
for many of the services AWS provides, via code generation:

[https://github.com/inhabitedtype/ocaml-
aws](https://github.com/inhabitedtype/ocaml-aws)

I've been using these bindings internally for about a year, so the kinks have
been worked out. A few more data types need to be supported by the code
generator (in particular, the map type), and then it should have full service
coverage.

~~~
eatonphil
Why the GCC requirement on FreeBSD? And that definitely shouldn't require
actually creating a static link.

Edit: whoops, replied to the wrong parent.

~~~
seliopou
The reason for each step is documented in the bash snippet. At the time of
development, zarith (a transitive dependency) hard coded the GCC dependency in
its build process. Perhaps it shouldn't, but it definitely did and continues
to require the symlink on systems without GCC. I submitted a patch to fix this
in zarith, but it has not made it to opam yet. See The patch here:

[https://forge.ocamlcore.org/tracker/index.php?func=detail&ai...](https://forge.ocamlcore.org/tracker/index.php?func=detail&aid=1451&group_id=243&atid=1096)

------
StreamBright
I can see why people start to use OCaml more and more for things like CLI
tools, metrics collection and other things like http proxying (most of the
stuff came up HN in the last few weeks). I am hoping that OCaml finally gets
its momentum and gets more widely accepted. It is a pretty sweet language with
amazing features and type class.

~~~
LeonidasXIV
> It is a pretty sweet language with amazing features and type class

Type classes is the one thing that OCaml does not have. It might get a sort of
similar to use mechanism called modular implicits, but we will see about that
in the future.

~~~
mercurial
Yeah, that's the OCaml version of "the year of Linux on the desktop" :(

~~~
StreamBright
You can still be hopeful. :)

------
eggy
I always wanted to learn OCaml because I thought ML was a very nice language.
Great how a rewrite of the JS code cleared up a lot blurry implementations. I
wonder if F# could be applied here as easily. Funscript and Websharper compile
to JS from F#. F# is opensource, and always suffered in published benchmarks,
because the slower Mono platform was used due to MS licensing restrictions on
using the faster .NET platform. Now that MS is opensourcing so much, and
recreating bash in Windows, F# is going to be more applicable I think in
operations too.

~~~
mercurial
Last time I checked, js_of_ocaml looked a lot more mature than Funscript
(whose repo doesn't seem to suffer from an excess of activity).

I think the big thing missing for OCaml right now is a solid persistence
system (preferably something lightweight).

~~~
ZenoArrow
> "a lot more mature than Funscript (whose repo doesn't seem to suffer from an
> excess of activity)."

That's because development work has moved to Fable:

[https://github.com/fsprojects/Fable](https://github.com/fsprojects/Fable)

------
vog
_> ... or the release by Bloomberg of an OCaml to JavaScript compiler_

I have never heard of bloomberg/bucklescript.

How does it compare to js-of-ocaml? (which is what the author actually uses,
according to the article)

~~~
FraaJad
see [http://bloomberg.github.io/bucklescript/#README#A-naive-
benc...](http://bloomberg.github.io/bucklescript/#README#A-naive-benchmark-
comparing-to-the-Immutable-map-from-Facebook)

~~~
vog
Okay, so Bucklescript is intended to become the next generation of js-of-
ocaml, right?

~~~
hongboz
Hi, there is a link here:
[https://github.com/bloomberg/bucklescript/wiki/Difference-
fr...](https://github.com/bloomberg/bucklescript/wiki/Difference-from-
js_of_ocaml)

