There's a small nuance here that DNS spec also caches negative (NXDOMAIN) results, but the TTL of those is controllable by the SOA record on the domain that contains it.

exe.xyz has a fairly short 10 second negative TTL, so even if you tried to resolve it before it was set up in the authoritative DNS, it wouldn't stay negative-cached very long (though some DNS caches put a lower bound on the TTL and cache it for longer)

> dig +short soa exe.xyz

ns1.exe.dev. hostmaster.exe.dev. 1854440 86400 7200 1209600 10

It's really not incongruent to use LLMs and be in awe of their frankly incredible capabilities while at the same time recognize the risks and frankly real damage we are already seeing to junior training and hiring, open source communities and (in my opinion) very soon the entire fabric of our society.

I respect that people don't want to use agents themselves for whatever personal reason.

I respect maintainers not accepting AI-authored contributions. It's a tradeoff between progress, growing new contributors and maintainer sanity. Though I do feel that categoric opposition to anything AI will likely be futile in the mid-term.

I respect people pushing for regulation of AI or a global pause or whatever.

I don't particularly respect people dismissing everything AI authored as slop. Categorically refusing to read an article because it contains em-dashes or the term "load-bearing" is silly. While this is slowly changing now, many people are still in complete denial as to what the frontier AI is capable of.

Love it, hate it - I don't care, but at least respect it, goddamit.

I recently wanted to dabble in line art again and made a small browser app to make it easier. As agentic AI tools of 2026 are quite addictive, it rather quickly grew into something quite a bit more - an integrated browser CAD/CAM for pen plotters that covers everything from importing existing artwork, creating artwork from scratch, preparing for plotting and hardware integration. It includes some off-beat features like a Logo interpreter for turtle art and Graves RNN for handwriting synthesis and in addition to 3D printer pretending to be pen plotters it now also supports actual pen plotters based on EBB (AxiDraw) and GRBL firmwares through Web Serial.

If you own an AxiDraw or a GRBL plotter, I'd very much appreciate it you gave it a try and give feedback. As I don't own those, I did all the testing with a hardware mock on STM32, so I am not sure how well it works attached to an actual plotter.

Source code and docs are on GitHub: https://github.com/tibordp/kurvengefahr

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

Points: 20

# Comments: 6

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.