I’m a little confused. Outside of being developed in Rust what makes gluon “embedded in Rust” vs a “standalone language”? It appears that while gluon is heavily influenced by Rust it can, and does, function as a standalone language as well if you wanted it to. Which, as they point out, is similar to lua.

I feel like embedded in the context of gluon only applies to their goal of being easy to embed as opposed to being embedded itself.

That’s really great to hear, that things will be moving along in such short order. Do you have any good introductions to the topic of algebraic effects, beyond what I could get by searching on my own?

He did a somewhat superficial research on what libraries or crates could be used though.

It is the same with ocaml/reason actually: he complains about the lack of a build system but the vast majority of packages are now using dune/jbuilder that is trivial to learn and use, well documented and extremely powerful, and he does not even mention it. He picks Containers as standard library replacement but it seems unclear to me if he has even evaluated base or core for example (even if I like containers myself). He also mention the introduction of multicore as something present even though it is nit yet part of the runtime yet

Your question confused me for quite a while, as I was unable to find this Rust solution in the article, despite multiple reloads. The page looks like this to me: https://leotindall.com/static/noRustVersion.png

Eventually, I looked at it on my mobile phone where, mysteriously, there is a code snippet. I was baffled until I realized that, indeed, the only difference between my mobile device and my laptop is… I have JavaScript disabled in my browser on my laptop.

So, my apologies to OP on this one. I was unfair. On the other hand, this serves as a great cautionary tale: make sure your site works without JavaScript.

Is the Reason flavour any better in those areas?

The situation is still not perfect in OCaml world, but the new dune (former jbuilder) build system is becoming the de-facto standard and tooling in the last couple of years has been improving a lot. The example of cargo, among other things, has been driving a lot of changes

I’m not sure it is worth pushing yet another build system that seemingly nobody uses (at least I haven’t yet run across a package which uses it) when jbuilder seems to be gaining so much momentum in the OCaml world lately.

It bothers me because it makes the language more difficult to learn. It also wasn’t always clear to me that an alternative was in use because, IIRC, they’re not (always) clearly namespaced. I have run into this in Haskell as well, FWIW.

You can’t have two standards, that’s a double standard!

Which languages?

I haven’t tried OP’s setup, but honestly it seems even worse than what I had. I pretty much followed this: https://ocaml.org/learn/tutorials/get_up_and_running.html. I ended up using Oasis, which was just awful, every time I added a file or dependency I had to fiddle with the config until everything would build again, but at least there wasn’t an entirely separate language.

From OP:

(jbuild_version 1)

(executable
  ((name main)                 ; The name of your entry file, minus the .ml
   (public_name OcamlTestProj) ; Whatever you like, as far as I can tell
   (libraries (lib))))         ; Express a dependency on the "lib" module

Note the comment, “as far as I can tell”. To me, that’s a terrible sign. A person who has gone to a reasonable amount of effort to explain how to set up a project can’t even figure out the tooling completely.

Xen has seen an unfortunate number of issues recently. So has Qemu though; those would apply to us whether we’re on Xen or KVM. KVM’s architecture is better suited for the present day realities of virtualization, but Xen still solves a real problem–we do host PVM guests that aren’t ready to move to HVM.

We do discuss moving to KVM: I recall a lunch conversation recently where we discussed what we’d do with a greenfield VPS project, and ‘starting with KVM’ held down one side of the table. I’d rather focus on live migration, as it reduces the impact of security disclosures and also gives me more operational flexibility. With less churn in my stack.

Xen is among the only PV virtualizers, so it’s hard to compare.

Windows 10 is much better at this than Windows has been in the past. They finally added full screen key chorded zoom which is a huge, huge requirement for me. Keyboard control of system services is still very spotty - for instance, there’s no clean way to control the sound volume from the keyboard.

Elementary doesn’t have any specific usability/accessibility features compared to Linux on the whole and more specifically Gnome, making it no different from any other distro on that front.

The accessibility features aren’t the same thing as UI, they’re things like an onscreen keyboard, magnification features, text to speech.

How is it better/on par in terms of accessibility options?

I found Gnome to be particularly inaccessible actually. In terms of LInux desktops, KDE was much better, but still markedly lacking, mostly because I still had to layer in various Gnome apps to actually get the job done.

Particular issues with Gnome: In many places you can’t easily resize the fonts. At all. Keyboard control of the desktop is mostly OK but keyboard control of apps is almost non existent.

Also, no full screen key chorded zoom. You can maybe kinda sorta do this with Compiz or whatever, but then you have to figure out how to run Compiz with Gnome.

I think these are somewhat separate issues. MTBF for a single engine failure on a P-38 was at least days, if not months or years.

Modern airliners have to reboot software such as weather radar, but generally this does not interrupt the flight itself. A modern fighter jet relies much more on its software for survival, from radar to IFF detection, to the fly-by-wire system (generally more complicated than an airliner’s). The reliability of these components could be the difference between life and death.

They are re-shooting it at higher quality: https://twitter.com/tqbf/status/716409446096744449

On the other hand, a safe® implementation of DNS was made for Mirage: https://github.com/mirage/ocaml-dns Also a good TLS stack that already passed some tests and is being checked more carefully…

Well, specifically in the case of browsers–don’t you think it would be wise to wait until we as a civilization had learned how to develop at least one rendering engine that doesn’t leave a steaming trail of CVEs in its wake before recklessly proceeding to build more and more technologies that depend on such engines?

Webkit, Gecko, and Chromium all have so many critical security flaws reported on a regular basis that the Debian packagers had to special-case their update policies just for them; they are essentially DOSing the distribution with bugs.

The standard response to this would probably be Ada. The price tag of the early compilers was indeed an important impediment to its adoption, but I am very annoyed when people dismiss it for being verbose or B&M: verbose is not necessarily a bad thing (all things in moderation I suppose) and being B&M (a term I’m not a big fan of) is preferable to the free-for-all chaos of C.

I’m actually thinking more of the PLT community than applications developesr. But now that I think of it, there have been many attempts at replacing C with something that would be a very practical, genuine improvement; they just haven’t gone anywhere. I suspect this is due mostly to the fact that the improvements over C have been gradual and not dramatic enough to make a splash or mired in kitchen-sinkism (paradigms–gotta catch ‘em all!), though I suspect a big part of it also is that as far as I know no one has had the backing of an org as big as Mozilla.

This is a good point, although it’s worth saying that Rust hit 1.0 in May of last year, so it’s been more than a few months now.

i think a lot of the userspace stuff could quite productively have been done in any ML/Haskell dialect (see mythryl and mirageos for proofs of concept). you don’t really need the raw speed and bare-metal access of C for much of it.

“The best time to plant a tree is 20 years ago, the next best time is today.”

glibc is under a half a million LOC. A large undertaking, but not totally impossible. The Rust compiler itself is larger. That said, I am not sure who, if anyone is going to truly give it a go.

By far most of the bugs in the history of things built on top of libc were NOT memory safety bugs.

So yes, languages like Rust and D will save us from a large and pernicious source of bugs, but not from all bugs, and certainly not even most of the bugs that have occurred in the history of these projects.

That said, I would support moving to saner safer languages as soon as possible. Rust addresses certain largish classes of bugs, but ultimately the fewest bugs are in the application built out of the best safest / least buggy frameworks. I’m betting on D for that future.

That’s exciting. Protocol buffers really did bring something new to the self-describing-data table, with the ability to generate code targeting a variety of languages. I have a strong personal interest in the problem area, and I’m happy to see the codegen part getting played with more broadly.

I too hope to see an epub at a certain point.

We’ve tested an epub render, it mangled the content horribly. I’d rather just fix the PDF via the LaTeX.

Glad you’re liking it so far :)

The first time I realised the difference was when I happened to read man pages in OpenBSD and FreeBSD. I was impressed by being able to live without googling everything and actually find the informations I needed carefully explained. If only I could use docker or rocket on *BSD I would finalise the jump

I am going to have to start living on Linux full time in the not too distant future and the idea fills me with terror. I wonder if I can still get by with ion (or even twm) + emacs.