Many of these meanings seem to be captured in some modern solutions already:

• We plan to provide a value, but memory for this value hasn’t been allocated yet.
• The memory has been allocated, but we haven’t attempted to compute/retrieve the proper value yet
• We are in the process of computing/retrieving the value

Futures?

• There was a code-level problem computing/retrieving the value

Exception? Result monads? (Okay, yea, we try to avoid the m word, but bear with me there)

• We successfully got the value, and the value is “the abstract concept of nothingness”

An Option or Maybe monad?

• or the value is “please use the default”
• or the value is “please try again”

An enumeration of return types would seem to solve this problem. I can picture doing this in Rust.

Doesn’t mean the defaults shouldn’t be sane

I swear, these bad EULA updates that basically force users to “accept the agreement, or we’ll brick your device” needs to fucking stop and be made illegal. The price that’s set for a product, especially a damn physical product, should include the acceptance of an existing EULA, and it should be honoured even when new ones come out and the user chooses to not accept the new agreement. You’ve basically never owned the product if companies can just pull the rug underneath you, and render your hardware useless. And you can’t foresee such changes too; a predatory company can acquire one that you’ve trusted and pull this shit. It’s borderline daylight larceny.

2 things I like about golang is just 1) the ease of getting someone to start work, and 2) goroutines. I have no complains about goroutines cause I’ve barely used it, and when I do it’s been fine. The first point though, I’d say the simplicity of the language is a double-edged sword — it’s easy to learn with little surface to cover, but it forces you to implement a lot of basic machinery you find in other languages by yourself, and so your codebase can get clunky to read really quickly, especially as your project grows.

Not trying to dissuade you from learning golang tho. I think it’s a good language to learn and use, especially for small simple programs, but it’s not the great language many try to say it is. It’s… fine. There are many reasons why it grinds my gears, but I’m still fine with using it and maintaining it for prod.

Ehhh, golang’s pretty down there for me too. Sure, you have types, but the way you “implement” an interface is the sussiest thing I’ve seen in most well-known programming languages. Not to mention all the foot guns (pointers for nullables is a common one, and oh, if you forgot that a function returns an error, and you called it for its effects, you’ve just built a possibly very silent bomb) you end up building into your programs. I use in prod, and I get scared.

For those who’re interested: https://this-week-in-rust.org/

A washer beep is like a webhook: if the recipient fails to acknowledge it, it’s gone forever. A notification is like an /events endpoint: the recipient can catch up on events at their own pace, and be reminded of and see events they haven’t processed.

Reference

Half-jokes aside though, I think what we want here is a reminder, i.e. a todo with a timed alert. Beeps can be missed and timers can be stopped (e.g. when you’re occupied), so they aren’t the most fool-proof solution here. Reminders will at least sit in the notifications list until dismissed.