
Unix system programming in OCaml - raphaelss
https://ocaml.github.io/ocamlunix/
======
murbard2
I took this course ten years ago with Didier Remy, I was very disappointed.

First of, the course was called "Operating Systems", and I was expecting
subsetting like the Tannenbaum, explaining the theory and practice behind
kernels. The course actually was about Unix system programming, and solely
about that. At least the page is properly named.

Second, I think OCaml is an amazing language, but frankly it's a terrible
choice for this course. One needs the right tool for the right job. No
particular " insight " is gained as the page alleges, beyond the insight that,
gee, C would probably be a better lanhuage to interface with the system it was
designed for!

Our project consisted in implementing the "ls" command in OCaml, which meant
mostly covering all the corner cases brought by different flags. It wasn't
interesting, it didn't teach valuable skills.

Functional programming languages shine when they deal with complex, recursive
data structures, not for simple tasks which are primarily IO and need to
handle many cases.

~~~
avsm
> Functional programming languages shine when they deal with complex,
> recursive data structures

While I obviously can't comment on the details of the course you took a decade
ago, I do have to disagree vehemently with this. OCaml is close to as ideal a
systems programming language as I've ever used since:

\- it has a simple, stable and predictable runtime with strict evaluation
semantics, so you can identify what statements allocate memory by inspecting
code.

\- the compilation to native code is fast and Unix-like, with standard object
files generated that can be linked to and from C programs easily.

\- the memory representation of values is uniform and native code debugging
with gdb/lldb works great, thanks to the DWARF symbols emitted.

\- OCaml's basic language features such as algebraic data types and exhaustive
pattern matching are fantastic for both building low-level programs, and
_refactoring_ them in the future as they inevitably get more complex.

> not for simple tasks which are primarily IO and need to handle many cases.

And this is exactly where libraries like Async or Lwt are so useful, since you
can juggle millions of concurrent threads and still do high-level programming
without getting lost in the noise. Error monads, failure monitors, function
wrappers to ensure resources get freed, can all be built directly within the
language itself using the usual ML abstractions, and the compiled code is
still lightweight and natively compiled.

For those interested in reading more about the runtime system in OCaml, the
entire third part of Real World OCaml is dedicated to this topic:
[https://realworldocaml.org/v1/en/html/pt03.html](https://realworldocaml.org/v1/en/html/pt03.html)

~~~
krenoten
What's the current state of parallel execution with OCaml? Historically, I've
been attracted to the type system and I think it's generally one of the most
beautiful languages out there, but I build things that need to take advantage
of many cores at once. Are there now at least nice wrappers around going
multi-process like python's multiprocessing library?

~~~
avsm
There are a few libraries out there; Async_parallel is one:
[https://blogs.janestreet.com/async-
parallel/](https://blogs.janestreet.com/async-parallel/)

Lwt also has the Release framework which does multiprocess:
[https://github.com/andrenth/release](https://github.com/andrenth/release)

and more if you search through OPAM.

~~~
krenoten
Thanks for the pointers! I'll definitely be playing with these :)

------
jlukecarlson
This sounds really cool. I currently TA a CS course that deals primarily with
OCaml so it is great to have real world applications/uses I can show to
students in the class.

