Fast Thoughts on a Fast Language

I've spent the holiday weekend diving into Ada, a language I tried out many years ago but have since put on the backburner.

I figured that, since that time, I've become much more well-versed in C and Rust, and also you know graduated from college with a CS degree so maybe I can make more sense of Ada's idioms and whatnot.

In this post I'll collect some initial thoughts from this weekend project.

Thought 1: Ada is a beautiful language

Moreso than almost any language I think I've used since OCaml, Ada feels /designed/. Sometimes it feels like a giant list of syntactic structures defined orthogonally to each other, but once you start writing software of sufficient size you realize that all those structures fit into place besides each other. The result is that you can basically look at any stanza of Ada code and know exactly what it's doing at the line-by-line level once you have a minimum amount of experience.

This is the exact opposite type of "beauty" as I ascribe to something like Common Lisp, which hands you a world without rules and lets you build up your own preferred way of doing things. In terms of actually writing a program (as opposed to doing something useful through developing software, which is unrelated), Common Lisp basically lets you do anything, while Ada prods you to skip the writing a program part and get on with the doing something useful part.

The syntax is verbose, yes, but in the process it builds up a structured way to reason about the semantics of what everyone was already doing ad hoc in C, and that is really really awesome. The whole "in/out/in out" system of parameter declaration is really a breath of fresh air when coming from C, for example. I'm also a big fan of languages which divde program sections into ordered subsections for common operations; Ada's procedure/function header is reminiscient of Ruby's implicit-rescue syntax in that way, and it's enjoyable to read through.

By far what I like the most about Ada the language, though, is that it was designed from the ground up as a cohesive language for systems programming. It has features which allow you to do low-level stuff such as define the bit layout of types, use paradigms more familiar to C such as throw buffers around and assign to them willy-nilly, or deal with higher-level abstractions using logical container types, iterators, its very interesting abstraction over a threading API, etc. It does all of this as *one language*, not two or three like you'll find in C++ and Rust. In C++ especially you'll often find yourself "dropping down" from 'modern' high-level constructs into C-style paradigms from time to time; this style of semantic shift is entirely absent in Ada, and it's really awesome.

Thought 2: Ada is incredibly difficult to get started with

I've spent nearly as much time trying to compile some tool or toolchain or solve some obscure bug in a build system as I have actually writing code this weekend.

I use Arch Linux, btw. Arch packages the GCC front-end for Ada, GNAT, as the gcc-ada package in the usual repositories. This is fine. You can compile Ada software with this by passing some flags to gcc. Great!

Unfortunately, every other Ada program ever written uses something called gprbuild, which is not only not in the normal repos, but doesn't even really have an actual AUR package. It looks like it does, but trust me, it doesn't. gprbuild is very, very difficult to install correctly from the AUR, mainly because of how its pkgbuild is defined. I kept getting into a state where the ABS believed that I had installed a package but I actually hadn't, and Ada's tooling was not set up to handle this in a sane or obvious way. In fact as I type this, I still haven't managed to fully configure Emacs's ada-mode due to obscure, impossible to debug, non-deterministic build failures in some Ada dependency.

Thought 3: Ada is fast

I mean, it's as fast as C (it compiles to C object code and goes through all the optimization phases GCC puts your C code through), but I've spent much of the last year writing Ruby and Erlang... I had distanced myself somewhat from the raw throughput you get from languages that don't have garbage collectors or virtual machines.

But like, I mean, I'm writing naive algorithms in Ada which are beating optimized (yet still single-threaded) versions of the same system in Erlang. That's crazy to me! Of course Erlang will still win in any world where mass parallelism lends itself to total throughput.

Thought 4: Where I'm going next

I have a few ideas for projects to try out maybe next weekend. I do really like Ada so far and want to keep using it.

Erlang NIF or port in Ada

Port some more of my C programs into Ada to find new edge cases in the language, like my gemini client

Do something with Ada's built in signal handler system, maybe try getting it running on a microcontroller