libguestfs

I think in this case it's definitely the last one. The C code is difficult to follow and harder to modify (see example link below). The new code may be easier to follow. Although I'm also aware that there's a fixed amount of complexity in the problem, and there may not be any silver bullet. https://github.com/libguestfs/libguestfs/blob/master/src/ins...

virt-v2v[1] -- written in OCaml -- had a bunch of contributions from people who mainly work on Java for their dayjobs. The main problem is that people are close-minded and refuse to learn anything new. If you can filter those people out with your hiring processes, then OCaml is not difficult. [1] https://github.com/libguestfs/libguestfs/tree/master/v2v

I'll tell you how we do these things in the libguestfs/virt-tools project [1]. The project is written in a mix of C, Perl and OCaml. Mainly C is used for the low-level/library bits, and OCaml is used for the higher-level tools. - QA: We have some unit tests, but mainly we use a huge test suite that does end to end testing of tools. It uses automake's test framework, so it works across all the languages in the project. - Builds and releases: We use autotools and tarballs. It's automated using a thing called 'goaljobs' which is like a generalized make. - The pain points for us all derive from autotools itself, which is both crap and better than all the other build systems[2]. It is at least well understood. I'd also say the killer advantages of OCaml for me are: Easy calling into C, and compiles to a native binary. [1] http://libguestf

Let's see: opam as you mention. Loads of new libraries[0]. Lots of small evolutions in the language in OCaml 4 [1] [2]. Lots of work on optimization in ocamlopt. Aarch64, POWER7 & POWER8, replacement ARMv7 backends. OCaml is totally a practical language for writing real world applications. As I usually point out in these threads, Red Hat pay me to write OCaml programs[3], that are used by thousands of customers and many more free software users worldwide. The advantages (over other languages, not C++) are: easy linking to C libraries, and builds a native binary with no extra dependencies, speed. Advantages over C++: safety, robustness, compact source code size. [0] https://opam.ocaml.org/packages/ [1] https://ocaml.org/meetings/ocaml/2014/OCaml2014-Leroy-slides... [2] https://ocaml.org/meetings/ocaml/2013/slides/leroy.pdf [3] https

OCaml is super-practical for writing simple command line tools. It interfaces easily with C and compiles to binaries with no dependencies. See: all the tools written in OCaml here: https://github.com/libguestfs/libguestfs

The project I've been involved with at Red Hat uses OCaml in a very procedural, imperative, workaday way. We purposely don't use fancy functional stuff, except in the very few cases where it makes sense. We also freely link to C code in the same programs. These are programs used by large numbers of generally unaware real world users. Why would they need to know - from the outside they look and behave like C binaries. Anyway, for some big open source projects written in OCaml, take a look: https://github.com/libguestfs/libguestfs/blob/master/v2v/v2v... https://github.com/libguestfs/libguestfs/tree/master/sparsif... https://github.com/libguestfs/libguestfs/tree/master/resize https://github.com/libguestfs/libguestfs/tree/master/builder https://github.com/libguestfs/libguestfs/tree/master/sysprep

Red Hat (the company) and RPM (the format) predate Debian, although only by a few months. Also RPM is a much better format than deb, and that's speaking as someone who regularly makes packages using both. I would also say that dnf and zypper are better package managers than apt, in as much as they are faster and easier to automate. Compare the code here: https://github.com/libguestfs/libguestfs/blob/1.29.43/custom...

I have a slightly more nuanced point of view. I pretty much write OCaml code for a living, and rarely use objects, but that's because they are rarely useful (as a general concept, nothing to do with OCaml). To give a concrete example of a program where I happened to use objects for the first time in ages[1], most of the program works by defining a set of types[2], and then using simple functions to work on those types. The program is essentially: transform the input structure to another structure to another structure. All the structures are publicly defined making it really easy to understand the program and debug when things go wrong. The flow of execution is simple and obvious, and the compiler picks up possible errors in that flow because of the strong typing. But there happened to be one place that I wanted the ability to hide dat

Firstly I don't expect to prove a whole program. However being able to prove the correctness of key functions or algorithms in a program could be useful. You mention glibc, and it would be great to prove that (for example) 'qsort' is correct. That wouldn't be entirely trivial: https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/msor... https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/qsor... For an example of a larger program, I'd like to prove various invariants of C programs, such as that 'reply_with_error' is called exactly once on every error path in this program: https://github.com/libguestfs/libguestfs/tree/master/daemon