One thing that’s interesting to me about this is the possibility of using OCaml for more serious network services work. That’s not to say that OCaml isn’t used for serious work already, just that something like Go, with builtin multicore and concurrency support is more likely to be adopted at this point in time.
So, anyway, with OCaml being a great language to begin with, having loads of benefits, and a (seemingly) growing community, how will it compete with Rust / Go? Can it compete with Rust and Go?
It can compete with Go (both are high-level, managed languages), however Rust has its sights on targets that are ill-suited to OCaml or Go.
Rust has its sights on targets that are ill-suited to OCaml or Go.
With network based services (the target of my comment, my bad if it wasn’t clear), I/O is typically the biggest bottle neck, so, fairly efficient machine code compilation (which both OCaml, and Go have), should put them in the same “ballpark”, I’d guess for things like web applications and other similar workloads. This of course assumes a similar I/O model, which I believe can be the case. Rust uses libuv, right?
I’m just wondering if we’ll see an increasing number of “How my startup went from 50 Node.js servers to 2 OCaml Servers” anytime soon, cause if so, sign me up for hopping on the bandwagon first! :-)
Rust uses libuv, right?
No, Rust has abandoned its libuv-based runtime. The code for the old runtime library now lives here. It has largely gone unmaintained, though there is some ongoing effort to restore at least some parts of it.
Ah! Thanks for the pointer!
Does it still utilize event driven i/o, or have they moved on from that idea as well?
allow me to apologize. I should have answered my own question by actually reading through all of the pointed to document
Long ago, Rust was a very different language. It had a big runtime, and had language support for things like channels. This is because it was thought that language support was needed to make such things safe.
As the language matured, more and more things could be expressed safely by the type system. And so language features got pulled out.
One thing that did remain, however, was N:M threading. It was pointed out that a systems language without 1:1 threads isn’t much of a systems language, and so, support for 1:1 was added. Like any good programmer, if you have two things that differed just by interface, you make an abstraction. So we did. You could sort of start Rust in N:M mode, or 1:1 mode.
… but it turns out that interface isn’t the only thing. To make this work, we had to slow down N:M threading, to the point where they weren’t really that lightweight, all things considered. Plus, things like segmented stacks really affect your ability to FFI into C, as switching stacks is a cost you now have to pay.
So, the choice was made: 1:1 threads made the most sense for the stdlib, as you should always have the ability to use your OS’s features in a systems language. On top of that, it would let us kill our runtime, which has a huge benefit, and sped up our FFI.
Because Rust is such a low-level language, this kind of thing is really ultimately a library concern, too. There’s nothing stopping green threading from being added to Rust later, even as a library. So we doubled down on making 1:1 as great as we can, and green threads will come back whenever someone motivated enough to do so takes it on. Which may even be the team at some point, we’ll see.
It’s basically the same with evented IO: IO is a library concern, which means it doesn’t really block the language development at all. So we’ve focused on non-blocking IO at first. OSes complicate things: IOCP is a very different API than epoll or kqueue. There’s already a great Rust library, mio, which people are using for this kind of thing. It’ll grow just like any other Rust library.
Woah! Thanks so much for the great reply!
Any time. I think history is really, really important, and often explains a lot of things. I’ve been considering trying to write some sort of “History of Rust” thing, but never enough time…
I suspect it will not compete with Go for the popularity of Go appears to be nearly completely disconnected from the quality of the language (people like it because it is simple, not expressive). Ocaml, minus the O, has no built in subtyping in the sense most people are acustomed to, which is a strength but a big hurdle for many people.
But it might be able to compete on performance, which I am looking forward to seeing more on.
Simplicity is a strength, to be fair.
people like it because it is simple, not expressive
Le sigh – I have high hopes for those who like things like Scala but want something closer to the metal. But, you’re right. And, as Rob Pike has (allegedly – I don’t have a real citation) said, “[Googlers] … They’re not capable of understanding a brilliant language but we want to use them to build good software. …”
I mean, I guess, if Googlers can’t understand a brilliant language, then who can? /sarcasm.