tibordp

Presumably these are new subdomains, if a caching DNS resolvers never saw the domain yet, it would simply query the authoritative server.

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

Good article! This matches how I feel about the situation.

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.

Yes! We played Achtung a lot on library computers in high school during breaks and I remembered it when I needed to pick a name for the app.

Given that we are talking about A4 papers and grams, I'd bet this wasn't in the US.

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.

That's only true for information theoretically secure algorithms like one-time pad. It's not true for algorithms that are more practical to use like AES.

Similar - I learned HTML by tweaking ReadMe.htm that was included with Dweep videogame from (now defunct) Dexterity Software.

Not sure I'd agree about it being esoteric. Understanding or at least knowing about ARP is still very much essential for people in networking. arping is a very useful tool for seeing if machines on the same network segment are up and just not responding to ICMP pings. Anyone looking at tcpdump/Wireshark dumps will run into it sooner or latter.

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.

That's interesting, I don't find VSCode slow at all, even when working on large workspaces via SSH over a high latency link.

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.

It's not that it's hard, it's just that it is not inline, so it requires a context switch because the CM is defined outside, even when it's doing something specific.

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.

That's a good point and also one of the things I kinda like about Alumina. You can do thing like this and the file will only be closed at the end of the function rather than the end of the if block.

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

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

I wouldn't say it was very difficult, but it did take quite a bit of time. Apart from some basic principles (no GC, no RAII, "everything is an expression"), I basically kept adding features whenever I hit some pain point trying to write actual programs in Alumina. If I were to do it again, I'd probably be more methodical, but anyway, here we are :)

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.

No native compilation to WASM yet, but since the compiler outputs self-contained C, it should be fairly easy to do it with Emscripten.

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.