In Europe, the typical flat rate is up to 100g for standard letters. And that's 20 sheets, which is not a particularly unusual letter to send.

It is true that software engineers may sooner run into it when debugging their home network than their application though as cloud and traditional networks are very different.

C is very easy to get started with if you don't already know LLVM. You don't have to flatten everything to SSA + basic blocks and can keep expressions as trees. The downside is that once your compiler is reasonably complete, you may spend quite a bit of time working around quirks of C (e.g. int promotion is very annoying when you already have full type information, so your compiler either has to understand C semantics fairly well or defensively cast every subexpression).

I have a C backend in my compiler (https://github.com/alumina-lang/alumina) and it works really well, though the generated C is really ugly and assembly-like. With #line directives, you can also get source-level debugging (gdb/lldb) that just works out of the box.

There are a few goodies that LLVM gives you that you don't get with C, like coverage (https://clang.llvm.org/docs/SourceBasedCodeCoverage.html). It works when done through clang, but cannot easily be made to track the original sources.

https://code.visualstudio.com/docs/remote/ssh

Sure, there are native editors that are snappier, but not to the point that affect my productivity in any way.

The one thing that VSCode does not handle well is large files (e.g. DB dumps, large JSONs, logfiles), but for coding, it really is not an issue.

The most common problem that defer is trying to solve is cleanup when the function returns early (ususally because of an error). Writing the cleanup code inline before the early return results in code duplication.

C#/Java/Javascript have try/finally for this, C has the "goto cleanup" idiom, and C++ and Rust have the guard objects. Go and Alumina have defer.

    let stream: &dyn Writable = if output_filename.is_some() {
        let file = File::create(output_filename.unwrap())?
        defer file.close();

        file
    } else {
        &StdioStream::stdout()
    };

Protocols were probably the trickiest feature of the language to figure out. As for the compiler itself, surprisingly, the biggest hurdle to get over was the name resolution. It's a tiny part of the compiler today, but everything else was much more straightforward.

I don't have formal CS background, but I have been coding for a long time. I read the Dragon Book and would recommend it to anyone writing a compiler, even though it's a bit dated.

I don't know Racket or LISP myself so I cannot comment on that part.

The sandbox is running the code server-side in a nsjail container.

As for unwrap, I feel you! the try expression (expr?) is supported, which makes it look a bit nicer, but I'm still trying to figure out a good idiom for when you actually want to do specific things based on whether the result is ok or err.

Alumina does not have Rust-style enums (tagged unions) or the match construct, which makes it a bit tricky.

What I meant was something like this (could also be done with `contextlib`, but it's also verbose)

    seen_names = {}

    class EnsureUnique:
        def __init__(self, name: str):
            self.name = name
        
        def __enter__(self):
            if self.name in seen_names:
                raise ValueError(f"Duplicate name: {self.name}")
            seen_names.add(self.name)

        def __exit__(self, exc_type, exc_value, traceback):
            seen_names.remove(self.name)


    def bar():
        with EnsureUnique("foo"):
            do_something()
            ...

    static seen_names: HashSet<&[u8]> = HashSet::new();

    fn bar() {
        if !seen_names.insert("foo") {
            panic!("Duplicate name: foo")
        }
        defer seen_names.remove("foo");

        do_something();
    }

I think one case where defer might be nicer is for things that are not strictly memory, e.g. inserting some element into a container and removing it after the function finishes (or setting a flag and restoring it).

This can be done with a guard object in RAII languages, but it's a bit unintuitive. Defer makes it very clear what is going on.

The only two pain point I had is that the `node-types.json` that's generated only contains the names of the nodes, not the numerical IDs. This means that if you have some codegen generating Rust enums is difficult if you want to avoid matching nodes by string.

I wrote https://github.com/tibordp/tree-sitter-visitor for generating visitor traits in Rust for a given grammar. I actually did it a bit differently in the end for Alumina, but it might come useful.

The only potential problem I see that with the current C backend, the debugging information is very hard to trace back to the original Alumina source code, so it might be hard to see where the leaks are coming from. This is something I plan to address in the self-hosted compiler, once it is functional.

The overarching theme is to see how far you can go making a language that feels high level without having a garbage collector or RAII. I used to use Deplhi/Pascal a lot when I was younger and it was this kind of language.

Check for example the language bindings to LLVM's C API (fairly low level) and Tree-Sitter which is used internally (a bit higher level bindings)

https://github.com/tibordp/alumina/tree/master/libraries/llv...

https://github.com/tibordp/alumina/blob/master/libraries/tre...

I think UFCS makes it quite nice for bindings, since external C functions can be used as if they were methods if the object is passed as the first parameter. So in many cases there might not even be a need to write wrapper structs for bindings that feel native.

Of course, it's still a manual process and since Alumina is just a compiler and stdlib for now (no llibrary ecosystem, no compiler driver), it's a bit cumbersome. But I like the approach Rust has with bindgen and cc crates, to automatically create bindings for C and C++ code.

It is mostly for fun and exercise in language design, I don't have any grand aspirations for it. It is however, by this time, a usable general-purpose language.

Alumina borrows (zing) heavily from Rust, except for its raison d'être (memory safety). Syntax is a blatant rip-off of Rust, but so is the standard library scope and structure.

Alumina bootstrap compiler currently compiles to ugly C, but a self-hosted compiler is early stages that will target LLVM as backend.

If that sounds interesting, give it a try. I appreciate any feedback!

Standard library documentation: https://docs.alumina-lang.net/

Online compiler playground: https://play.alumina-lang.net/

Comments URL: https://news.ycombinator.com/item?id=32702812

Points: 107

# Comments: 87