Hacker News Reader

Comment by sammorrowdrums | Hacker News Reader

I was wondering in the P0, P1 issue, why the auther didn't use an Enum, Enums are the easiest way to handle that sort of mixed type.

On my phone something like:

    enum Pin {
       Pin0(P0, usize)
       Pin1(P1, usize)
    }

Assuming that would work in the embedded device which I don't know.

I know the above doesn't affect the general point, but I have found lots of people struggling with Rust haven't yet discovered that you can easily combine types in Enums.

View on HN

And the author's actual rust solution using the 0, 1 as a proxy for the port with a match to resolve it, has effectively implemented the enum solution but without leveraging the language to do it, which means incorrect programs could use any integer value and the compiler wouldn't know, and the author has to handle that case, which they hack with empty block for that case. (relying on knowing they haven't in their own code, basically undoing the whole point of Rust compiler strictness)

     _ => {}

Author here. I considered the enum "solution" but found the match on usize tuples to be clearer because it requires less code. Introducing an enum doesn't help because it neither:

+ helps better model the domain: P0 and P1 are already device ports, wrapping doesn't clarify anything,

+ nor does it buy you safety; arguably I'd say it makes it less safe, since the real risk with this sort of code is that you fat finger when copy/pasting between the electrical schematic and the firmware, so by adding extra wrapping you further obscure the pin assignments.

Ah, sorry I added further comment to above before seeing this. I can see why you would say that, but does the arbitrary integer risk of the 0, 1, _ match not create even greater risk? Compiler cannot help at all.

    _ => {}

First, we should be clear that this is my goofy hobby keyboard project --- if I was concerned about safety, I'd have written it in MISRA C or something =D

There are many things about this project that a compiler can't help me with. I had to read about all of the pinouts from a PDF, draw them on a circuit board, and then map those pins in the firmware.

The code only deals with that last part, and in this particular example I decided that it was safer on the whole for the code to be obvious (easy to read + compare with hardware schematic) than to go through contortions with types to make some things more checkable by computer but less-checkable by human inspection.

The main risk here is not passing the wrong value to this match, it's fat fingering the transcription from the schematic.

Makes sense, and I guess given the above your conclusion not to use Rust seems like the correct call for your situation. Thanks for explaining further. It's true you say much of this in the article.

Yeah I think people like to match the values of a programming language to ourselves as people. (And by values I mean, correctness, speed, expressiveness, velocity, etc). Like, I’ll pick the values which I like the most and find languages which match the values I aspire towards. Eg maybe I like the idea of my programs being strongly typechecked without sacrificing speed - so I program in rust. Then I write clean rust code even when I’m doing a quick and dirty prototype.

The better & harder approach matches a language’s virtues to the problem at hand. Strict correctness doesn’t matter much for a hobby program like this - moving fast and having fun are probably more important here. Expressing that with your tools might mean using Zig, or using rust but being sloppy with allocations and .clone() because it’s fine. Or treating rust like C and using unsafe everywhere. “Making invalid states inexpressible” isn’t that important in a fun side project - unless maybe that’s fun for you!

The right question isn’t “What is my favourite tool?”. It’s “If this project had a soul, how would it want to express itself through code?”

I like that last sentence; is it something you came up with yourself or is it a quote?

Thanks - that’s all me.

> The right question isn’t “What is my favourite tool?”. It’s “If this project had a soul, how would it want to express itself through code?”

I somewhat disagree. What you're saying is basically "pick the right tool for the job", but more poetically (not a criticism, BTW, I like your phrasing).

But what I think this is missing is that the "right" tool is at least in part based on your favorite tools are.

Or to put it differently, using a tool that may be suboptimal for the job, but which you know extremely well, may be better than using a tool you don't know which is optimal for the job.

Of course, this is much less of an issue for hobby projects, and if one of your goals for a project is "learn new stuff" (a goal I often have for my own hobby projects), then picking the optimal language may be exactly the right choice. You get to learn a new thing while not fighting with the language.

I had a think about this and I agree. There’s some tension here - you want breadth, but you don’t have enough time to get good at every language and framework. Maybe the right approach is to have familiar ground in each domain you find yourself. Pick enough languages and frameworks so you have trails in any terrain you want to tread with your work. You don’t need to be an expert in both php and rails, in both Java and C#, or both unity and unreal. But you want enough scope that if you want to throw together a quick and dirty UI prototype, you have familiar tooling you can call your own.

For me, when I want to make a quick UI prototype I reach for JS and Svelte. Because I’m comfortable there, its not worth it to also be an expert at rails, and Php and SwiftUI and C#/WPF. But if the only tool in my toolbox was Rust, or C, or Unity or something, I’d be much worse at prototyping user interfaces. The inverse is also true - if I wanted to write a database but only knew JS, I’d be in for a rough time. You want a home base in each domain.

Oh and also, if the whole separate types for each mapping thing is so annoying and wrapping the tuples is unhelpful, which is understandable, then perhaps safer to wrap just the pins in emums and then always access them via the enum?

Then it would be (enum type, usize)

Then also at times where all Pins need handling, the.exhaustive matching can reduce risks of not doing so?

Reply on news.ycombinator.com