I’d like to ask the OCaml developers and community a few basic questions about the evolution of the language and standard library.
I’m sorry if I’m asking such basic things, but I couldn’t find clear answers myself.
Is there an OCaml standard definition (like the ISO/IEC for C)? Wouldn’t such formalization help untie the language and the compiler?
Is there a roadmap regarding the future of the language? What are the next goals?
Is there a roadmap regarding the future of the standard library?
Currently the standard library is missing some features and there are multiple implementations that extend and replace it:
To answer questions 3 and 4: In the past, the standard library had been more minimal, but in recent versions of OCaml, it has acquired substantial additions. In particular, OCaml 4.08 was a release that added a lot of useful modules.
The problem with all the alternate standard libraries is sort of like XKCD 927, in my opinion. However, the actual standard library is privileged over the alternate standard libraries out of virtue of being shipped with the compiler rather than being a separate package. I think that people should focus on improving the real standard library.
An OCaml standard wouldn’t necessarily do much. When there are two or more strong contending implementations, then you need a standard. Until then, though, the implementation everyone uses creates the de facto standard, constrained only by their own judgement. Users will call for features; few will refuse to use those features once they appear, just because of some moth-eaten formality of a standard.
Better included libraries is always good, as long as they’re really better of course. Python might a good example of what not to do, in some respects - a lot of that is really quite handy, but here and there you may find toy batteries that are fundamentally unsuited to many purposes.
A small counter here is that with a standard a user can determine the expected behaviour of the compiler, which can be useful for understanding what a piece of code should do and if there is a bug. That may not be worth the effort, but competing implementations is not the only situation that benefits from a standard.
The history of the SML “standard” is interesting and somewhat-instructive, eh? The major ML implementors got together and came up with the specification, and called it a “standard”. But it was a standard only because they called it that. And behold, caml and caml-light differed from the standard in ways that were valuable – very valuable.
(1) caml-light enjoyed the principal type schemes property – that the inference algorithm would come up with the most general type, and you didn’t have to tell it any hints to get that to happen (which was not the case with SML)
(2) eventually Xavier Leroy came up with a better module system than SML’s.
(3) leaving execution order of applications and other things unspecified allowed for more-efficient runtime at a minuscule cost in programmer effort
And I’m sure I’m leaving stuff out.
The adoption of the “Standard ML” standard was an unmitigated disaster for those implementors, and the fact that almost nobody uses an SML implementation today, whereas many people use Ocaml implementations, is testament to that.
I have heard that the SML compiler produces very efficient binaries though.
Apparently, it can do some whole program optimizations that the ocaml compiler cannot do.
Is there a roadmap regarding the future of the language? What are the next goals?
The next major goal is the integration of OCaml multicore in the mainline compiler. Behind the scene, there is also an on-going work to refactorize the type checker and pattern matching compiler to make it easier to implement future prospective features (like modular implicits or algebraic effects). Similarly on the middle-front, there is a new optimizing middle-end called flambda2 in process. Beyond those long-term goals, we have RFCs under consideration at GitHub - ocaml/RFCs: Design discussions about the OCaml language .
is there a roadmap regarding the future of the standard library?
Updating the standard library is mostly done in a ad-hoc basis. I am not aware of any systematic work on the on-going library.
Currently the standard library is missing some features
If there are some features that are obviously missing, and there is an implementation that is guarantee to stand the test of time, it is a good idea to open a PR against the standard library. Note that the review is often a lengthy process. Personally, I don’t see an issue with having multiple standard library replacement or complement in competition that are freer to evolve than the standard library which is subject to strict backward-compatibility requirements.
Note also that container is more of a complement to the standard library than a replacement. If you don’t want to switch to the base ecosystem (base is quite opinionated), container is probably a good start.
I’m considering OCaml for some of my projects, but I have the feeling of moving on a shaky and fragmented ground.
Why do you feel that OCaml would be a shaky ground? The language is stable, and backward compatibility is taken seriously. There might be more choices than usual in term of standard libraries, but this is a choice that can be postponed by starting with the standard library and containers.
Maybe I’m wrong but I think by standard library OP meant something like this https://golang.org/pkg/#stdlib
What always frustrates me during learning OCaml ecosystem that to make a simple http request or http server, without reinventing the wheel, I need to download a lot of dependencies. Go stdlib is not big and has everything to build web services or json parser or cli utility without reinveting the wheel. Would be great to have the same out of the box in OCaml.
OCaml has historically been focused on algorithms, parsers, compilers, provers, etc. For these things, json or http is pretty irrelevant. Json didn’t even exist when OCaml was created. Go was designed for networking services, and its stdlib reflects that (it also doesn’t contain much in the way of writing things OCaml is good for, by the way.)
I’d chalk this up to different focuses for the languages. Maybe when we have effects and lightweight concurrency directly in the language there will be more room for more standard networking libraries, although lwt is basically the standard for concurrency and IO now.
(1) You might not be aware of just how (ahem) “prescriptive” Golang is about libraries. So for instance, I once had reason to go digging around in golang’s networking stack. I wanted to do two things:
(a) put in my own encryption (NaCl instead of SSL)
(b) use GRPC over socketpair, instead of over sockets created via accept/connect [for instance, so you could use GRPC to communicate between parent and child processes after fork]
It turned out to be well-nigh impossible to do this. The Golang designers had not merely not foreseen this possibility but had sufficiently closed-down all the hatches, that I couldn’t find a way to do it.
One of the great strengths of Ocaml is that outside the compiler itself, it isn’t a monoculture, and while, sure, you’re not arguing for a monoculture, it’s something to be worried about, that the example you cite -is- a monoculture.
(2) when people install ocaml, they install the compiler&runtime first, I guess. When you install golang, you get an entire “platform” which includes the equivalent of opam. And let me assure you, most people don’t compile golang (I’ve done it many times, and it’s a big task, groan). So if instead, we imagine that people download/install opam as a binary, then from there to having all the many libraries available is … well, it’s not very hard, is it?
I don’t really see how that’s worse than what you get with golang.
Yes, but we are in 2020 already. I was watching presentations about OCaml platform and others and I think OCaml is not anymore considered only for academic research and a compiler implementation but for web development as well or am I wrong? Rust and Cargo already has stolen some OCaml thunder. I think multicore OCaml and solid stdlib can be a good selling point for OCaml.
I’m not a big fan of Go but I think Go stdlib and compile time were a huge selling point. OCaml was always fast even when Go didn’t exist. But each time during opam install the number of installing dependencies reminds me an npm and node_modules folder from JS world.
My point is Python and Go have an stdlib and user has a choice.
The problem you describe is one of opam and binary packages. The reason golang is faster to install is solely because it comes in binary form. Two things might improve the situation:
(1) I’ve read that opam is getting binary packages; once this works well, the advantage you cite goes away
(2) even before them, if it were possible to install opam switches and packages in the same manner as one installs native packages (e.g. DEB/RPM), then again, the advantage you cite goes away. Note that many other languages provide the functionality: python/perl/ruby all allow you to install packages/modules via dpkg/apt/rpm, and those packages get installed and are accessible in the same manner as packages that you download and compile yourself, or install using the language-builtin-installer.
By faster I have meant compile time. Anyway in Go I can built cli tool which makes http request to elasticsearch does some math on data and dumps result to csv without any third party dependencies. I don’t need to install anything.