Thomas Leonard

They hate D&D on the systems you've seen them use. I've seen them use it for many years on an OS called RISC OS, written by Acorn, designers of the ARM chip. There, users loved it. Everything supported it on the desktop. You had `filer' windows, and to save an application would just pop up a little window with a file icon and a text box for the leafname. Enter `foo' and drop it on the filer window where you wanted it.

But better than that, you could drop it on another application. Consequently, you could create and edit a pixmap, and drop it into a vector drawing program where it would become an embedded object. Want to edit it again? Drag it from there back to the pixmap editing program's icon on the icon bar. Neither of these touched the disc; it was in memory transfers. And the program code didn't need to know the difference between saving to another app., or saving to disc through a filer window.

Other aspects of the desktop were also novel and worked well. It had a three button mouse. A proper one. No silly scroll wheel. The right button did what the left button did, but altered in some way. So you'd pop up a context sensitive menu with the middle button. Select an item with L and the menu would disappear. With R the menu would stay there. Great for when you want to do several menu items in a row, e.g. adjusting an object's attributes.

Scrollbars worked better. Firstly, the mouse cursor on the screen only moved in one dimension once a drag with L…

Off-hand, Mirage OS comes to mind - it completely upends how you would "build" and "run" back-end services, and it is written solely in a GC'ed language - OCaml. And all GC'ed languages are not equal; see https://roscidus.com/blog about a Linux package manager ported from Python to OCaml for performance reasons (followed by an OCaml reimplementation of a component in a virtualized OS).

Some infrastructure, e.g. database engines, is ubiquitous, but all instances are of the same few software products written in C/C++/Java. Those ubiquitous instances have banged most bugs out of those codebases, so it is an uphill battle there to convince incumbents and upstarts alike, of the value of a new implementation. But Rust & Pony are marvelously positioned to march up that hill, especially if you throw in multi-threading.

My impression is that only a minority of widely-programmed back-end infrastructure that suits Rust is written in C/C++ (say, map-reduce kernels). The code-base size & the data flow complexity inside those components is pretty limited, and Rust should be tractable at that scale.

Most widely-programmed infrastructure software - in the back-end and on cell phone OS'es - have been merrily using Java/Python/Ruby/Erlang. OCaml is quoted as being used in the management component of VMware. These are much larger applications; is there any evidence or hint that Rust isn't onerous to develop larger systems in? Without that evidence, I feel (not think) that a disciplined…

I think the important insight from these articles is not which language the author ends up using (OCaml[1]), but rather which languages he's managed to rule out by now. In particular, I think it's good advice to avoid both ATS (however much I like dependent types) and Go, both for completely different reasons. You probably wouldn't want to use Rust in the short term either.

[1]: http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/

ATS makes everything more difficult than it's worth except for some very specific use cases. Unlike some of the other languages like Haskell and OCaml, I don't think this is just because it's different; rather, it's because ATS is simply so much more demanding. It gives you extremely solid static guarantees and high performance, but it's a tool that really sacrifices expressiveness and programmability to get there. Haskell and OCaml may be difficult to learn, but ATS is actually difficult to use--a very different concept.

Go, on the other hand, is neither difficult to learn nor difficult to use. But, more generally, Go has very little to commend itself and--compared to the other options--quite a few shortcomings. If you're willing to put in a little bit of effort to learn something new, there are a whole bunch of options which are simply better. And you should be willing to put in the effort: your programming language is your single most important tool; it affects not only how you write your code and how you maintain it but even how you…

Over other languages in general? That's hard to say about any language :)

OCaml is a language in the ML family, is backed by INRIA and is the main language of Jane Street Capital (so it definitely has "real world" use!), which also contribute a lot to it. OCaml is pretty good for functional programming, and unlike Clojure, it's statically typed. If you like static typing -- which I personally think is the way to go -- that's a huge reason to prefer it over Clojure. You may also check out Haskell if you go that way.

An interesting case study about going to OCaml from another language (Python, in this case) was posted to HN many times already: http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/. I recommend you read it if you want to learn more about why would one choose this language.

Why not choose a language in the ML family? Well, if not having C-like syntax is a deal breaker for you, then OCaml is going to frustrate you. A real programmer shouldn't let syntax stop them from learning new languages, though :)

Ultimately one has to try doing something with this kind of language, even if it's just a toy project. Just reading about it won't enlighten you much, and you will end up focusing on its syntax instead and deciding it looks too unfamiliar.

If you read the original article[0] it did very well on the speed/size bench (5/5) but took a big hit on ease of writing (1/5) ending up with 48 between C# (47) and Haskell (49) and the following summary note:

> Everything would be incredibly fast, but getting new contributors would be very difficult due to the learning curve. There’s a risk of crashes as the library is not entirely memory safe, and there are likely to be changes ahead to the language. Probably writing the whole thing in ATS would be too much work for anyone.

ATS didn't make it to round 2[1] on grounds of use difficulty and difficulty of separating memory-safe and memory-unsafe code.

That seems prescient as the original ATS1 (ATS/Anairiats) was replaced by ATS2 (ATS/Postiats) a few months later, I don't know how compatible the two are but the FAQ puts ATS1 and ATS2 in different categories[2]

[0] http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/

[1] http://roscidus.com/blog/blog/2013/06/20/replacing-python-round-2/

[2] https://github.com/githwxi/ATS-Postiats/wiki/ATS-implementations#ats1

The list of publicly-known packages can be found on the default mirror site: http://roscidus.com/0mirror/

In general, though, if there's some package you want and you look for it there you're likely to be disappointed. 0install is probably more interesting to people wanting to publish software (and particularly, collections of related software).

Good use cases would be:

- Using it to build a package manager for a programming language (Rust would have been a good fit, I think, though like most languages they prefer to build their own language-specific system).

- Distributing applications for a desktop environment (the ROX desktop was the original motivation to create 0install).

- Managing plugins for a large application (Drupal, etc).

It might be best to think of it as a platform on which you can build a package manager or community.

Of course, people use it for individual applications too, but then you pay the cost of having to explain to your users what it is the first time. With a larger collection, the payoff is better.