> Did DF ever allow comments on its own website?

Not that I'm aware. There's some discussion about it in this post from 2010:

https://daringfireball.net/2010/06/whats_fair

This is the one, thanks.

> You write on your site; I write on mine. That’s a response. I don’t use comments on Wilcox’s site to respond publicly to his pieces, but somehow it’s unfair that he can’t use comments on my site to respond to mine? What kind of sense is that even supposed to make?

In this case I agree with Gruber. Responding by blogging and citing is better for both websites.

Seems hypocritical to me. He admits wanting to see the comments here while not supporting them on his own site.

How is it hypocritical to hold the view that some places are intended to be open forums for comments from anyone, and others are not?

Also, by not hosting my own comments, all public commentary on my writing is thus out of my control. I don't get to block comments I don't like here, or on Mastodon, or Twitter/X, or Bluesky. I think that's actually for the better.

I see your take, but I disagree.

DF is a blog and was conceived that way. HN is a discussion site. The two forms (blogging and internet discussions) are different. They serve different purposes and require different management styles.

The discussions here do seem to be tamped down in some ways, and as a user, that takes something away from the experience.

Relatedly: in general, I think "hypocritical" is not a big gotcha that ends discussions. Different things serve different purposes.

Can you blame someone for not having any hateful comments on their website? Even if 98% were positive, that 2% could annoy the hell out of you.

Might be worth giving these posts a read when thinking about a lightweight Rust:

- https://without.boats/blog/notes-on-a-smaller-rust/ - https://without.boats/blog/revisiting-a-smaller-rust/

It's also niche, but https://gleam.run/ might be a candidate alternate language, depending on your use-case.

I haven't tried it in OpenBSD but this article claims that it's mapped to Super+LShift+F23: https://www.tomshardware.com/software/windows/windows-copilo...

Thanks for the pointer to the aarch64 build of rustup. Are there plans to update this bit of the website to point at that version in the future? https://files.wezm.net/forums/Screenshot%202024-07-16%20at%2...

The site's source code is already updated, but unfortunately the website itself is refreshed per Rustup release, so we might have to wait for a bit longer...

NVIDIA started publishing more of their driver as open-source in 2022, which while not hardware documentation probably helps a lot.

You may be wondering why Red Hat is bothering with this effort then? I assume it’s so that the code can be added to Linux directly as opposed to being out of tree.

https://developer.nvidia.com/blog/nvidia-releases-open-sourc...

Ahh whoops. Will fix in the morning, thanks.

Edit: fixed now (might take a few mins for the cache to expire).

> the Gleam aspect of this is inessential, TypeScript is quite good

TypeScript can be quite productive but I find its type system lacking. Specifically the use of structural typing/lack of nominal typing and lack of sum types. I find these extremely useful when writing reliable software, which is why Gleam appeals to me.

That's by all design.

Does this prevent you from writing reliable software?

It has sum types! Type unions with a discriminator.

It kinda does if https://www.typescriptlang.org/play#example/discriminate-typ... is what you're referring to but it appears to be missing one of the major benefits: an error/warning if you haven't handled all variants.

Edit: lots of replies showing how TypeScript can be made to do exhaustiveness checking. It's neat and all but it's a lot of gymnastics compared to languages that just have this built in, which again is part of the appeal of Gleam for me.

You can workaround the lack of exhaustive matching with the following pattern:

    type Variant = { kind: "value", value: string  } | { kind: "error", error: string } | { kind: "unexpected" };

    class Unreachable extends Error {
        constructor(unexpected: never) {
            super(`${unexpected}`);
        }
    }

    function useVariant(variant: Variant) {
        switch (variant.kind) {
            case "value":
                return variant.value;
            case "error":
                return variant.error;
            default:
                throw new Unreachable(variant);
        }
    }

The `new Unreachable(variant)` will fail the type check only when you have not exhaustively matched all variants.

For the most straightforward nominative pattern matching, I would write a small match function:

    type A = { kind: "kindA", a: "dataA" }
    type B = { kind: "kindB", b: "dataB" }
    type Sum = A | B

    const match = <
        const V extends { kind: string },
        const C extends { [ kind in V[ "kind" ] ]: ( value: V & { kind: kind } ) => unknown }
    >( value: V, cases: C ) => cases[ value.kind as V[ "kind" ] ]( value ) as ReturnType<C[ V[ "kind" ] ]>

    // You check the type of result, change the type of value to A or B, make the cases non-exhaustive...
    const howToUse = ( value: Sum ) => {
        const result = match( value, {
            kindA: _ => _.a,
            kindB: _ => _.b
        } )
    }

You can test it here: https://www.typescriptlang.org/play?#code/C4TwDgpgBAglC8UDeU...

I ran into this exact issue when I was working on a piece of typescript that interoperates with a rust server, here's how I was able to do exhaustiveness checking (the errors aren't the prettiest, but it works): https://github.com/wwtos/mjuo/blob/main/vpo-frontend/src/lib...

EDIT: and an example of usage: https://github.com/wwtos/mjuo/blob/ca8c514185c1b5bb22aec752a...

Yeah, that can be annoying. Until pattern matching makes it into JS, the main way people deal with this is to use a library. For example, ts-pattern lets you stick `.exhaustive()` at the end of a match call and I believe you get the error at typechecking time, not runtime.

https://github.com/gvergnaud/ts-pattern

Oh that’s easy to fake with type narrowing:

function expectType<A, B extends A>() {}

expectType<never, typeof yourUnion>();

The function call will fail at compile time if yourUnion is anything more than never, which you can use in your else case of if statements that narrow the discriminated union.

Oops, thanks for heads up, I had it set to private. Should be fixed now.

Also Celsius is the name of a guy, and you're misspelling it throughout the code base. :)

I think it would be good to include some examples in the README to show off what it can do. Also how to invoke it: can it find SQL embedded in other source file or does it need to be pointed at .sql files.

Nice. Looks a bit fancier than my version from a few years ago https://git.sr.ht/~wezm/lobsters

Looks really nice, I wasn't aware of it