Doing error handling properly is hard, but it's a lot harder when error types lose information (integer/bool returns) or you can't really tell what errors you might get (exceptions, except for checked exceptions which have their own issues).

Sometimes error handling comes down to "tell the user", where all that info is not ideal. It's too verbose, and that's when you need anyhow.

In other cases where you need details, anyhow is terrible. Instead you want something like thiserror, or just roll your own error type. Then you keep a lot more information, which might allow for better handling. (HttpError or IoError - try a different server? ParseError - maybe a different parse format? etc.)

So I'm not sure it's that Result is clumsy, so much that there are a lot of ways to handle errors. So you have to pick a library to match your use case. That seems acceptable to me?

FWIW, errors not propagating via `?` is entirely a problem on the error type being propagated to. And `?` in closures does work, occasionally with some type annotating required.

Even older relatives - we sent a physical gift a bit ago, but the response/thanks was by text. It just doesn't make sense to send a letter, have it take a week, never know whether it got lost, etc.

The appropriation argument is somewhat unsound. Creative endeavors, by definition, build on what's come before. This isn't any different between code, creative writing, drawing, painting, photography, fashion design, music, or anything else creative. Creation builds on what came before, that's how it works. No one accuses playwrights of appropriating Shakespeare just because they write a tragic romance set in Europe.

The hyperbolic way you've made whatever arguments you had, though, is actively working against you.

The unfortunate truth is that if you're doing B2C or even B2B outside of tech companies, the second one will often come up...

Bad devs exist. Bad users do too. Thing is, you can't usually fire the bad users.

I've got doubts about cheaper, and 5-6 story buildings in Vancouver always seem less comfortable than a skyscraper (for whatever reason - maybe just that the 5-6 story buildings are mostly old?)

That's kind of the entire point of Vancouver NIMBYism, at least around Kits/Point Grey. The "backyard" for them is basically "anywhere except the downtown peninsula" (the other side of the inlet in the picture).

They won't care too much if someone builds a 20-40 story building on the West End/peninsula. Do the same thing on the west side ([1], off the peninsula) and they'll throw an absolute fit.

[1] The West End neighbourhood and the colloquial west side are a solid 10-20 minutes apart from each other, driving time. Geographically - West End is on the peninsula, and the west side is basically the various neighbourhoods across the inlet (False Creek) from it.

I know that Velcro/Kleenex/Google are specific brands, but I don't really care - the common usage is so far gone that there's rarely a reason to use hook & loop fastener/tissue paper/internet search instead.

Hell, for some people, "iPad" is a semi-generic term for a tablet. (Though I don't get that one, personally.)

Civilian aircraft do broadcast actively (ADS-B). But they also respond to secondary radar for Mode A/C, which are basically cases of IFF Mode III (okay, maybe not exact term, but the idea applies.) So it's still a challenge-response/IFF, just in this case always responding.

Military aircraft use different modes and presumably don't respond unless interrogated with an appropriate challenge, but the principles are the same.

The available compilers targeting your microcontroller certainly matter, though. You certainly still find lots of options that aren't Rust-compatible, but a non-trivial number microcontrollers are ARM or RISC-V based now, and can be targeted by LLVM/Rust.

Like just as an example - I can write an allocator and toggle register bits etc. All of that requires unsafe code, raw pointers, etc.

But I can then build on top of that in safe Rust, with all the guarantees that brings. I still have to check that the unsafe allocator or whatever work soundly, but Rust checks the stuff on top of it.

I don't think it's unreasonable to flag that.

That "protection" seems pretty worthless to me, since a non-trivial number of the use-after-free bugs I've seen are triggered only in rare cases, which means you're still crashing in prod.

Overall, Rust's lifetimes are sometimes hard, but generally only when memory safety is also hard. Inko's docs claim it makes it easier to implement self-referential data structures without unsafe/raw pointers, but to be honest the references here don't seem significantly safer than raw pointers.

[1] https://docs.inko-lang.org/manual/latest/getting-started/mem...

It's going to suck for a couple days, I think.

I don't think this is there yet. I'd need to see performance data, and I'd really prefer SteamVR integration (though I could probably reduce a PC+headset to a pretty small if necessary). But it's a step in that direction, and even if it's not necessarily Apple that gets there I think we will see that kind of device in the future.

2, 4, even 256 sockets exchanging data can be worked with concurrently on a single thread and gain performance vs blocking and waiting for the first socket to finish. There's no parallelism, since they're never actively reading/writing at the same time, but they're concurrent because they exist and operate in overlapping timeframes.

Running two independent algorithms could mimic this - run part of algo A, then part of B, then A, etc. It's not useful for performance, though. To be useful you require parallelism - you have to have the algorithms executing at the same time, using multiple threads.

On async itself - it's not perfect, but honestly, there are contexts where it makes a lot of sense. I work on a lot of non-blocking C code - the entire programs are basically epoll and timer driven. As a result, the high level coordination is just callback hell. Async is very nice in comparison.

Yes, you can spin up threads to do everything with blocking, but non-blocking I/O came around specifically because the threads add overhead and kind of suck. It's worth noting that having threads can also infect the codebase. You either have to carefully manage mutexes, or you only communicate with channels and have to worry about keeping things updated and in sync. Sometimes this works great with minimal communication between threads. However, if you have one socket per thread and the sockets are all triggering actions that mess with the same data... it's not so great.

Meanwhile growing up you're basically taught "look, don't touch" and "back away slowly" with regards to anything the size of a goose or bigger. This comes with lessons like don't mess with big/wild cats, and however large you expect the moose to be, it will inevitably be bigger.

Of course, I'm sure there are areas of the world where that knowledge will completely miss the actual relevant risk(s). Probably something to do with spiders/snakes, as they're just generally harmless here.

Possibly time of year dependent, I guess, but seriously, one weekend of nightly midnight drives out in the Shuswap area of BC was all it took. I now/still respect the effects of the deer, but marvel at their unmitigated stupidity.

I also think hue has a wider variety of bulb and plug-in options, which is nice since you have to stick with a single brand to get consistent colors. I don't think IKEA has an RGB bulb for GU10 fixtures, or pot lighting options, for example.

Other than the actual lights, though, I don't bother going with Hue products. They're generally overpriced, at least as far as I can tell.

With Godot 4, 2D tilemaps are incredibly awkward to use alongside random generation. You have (had?) to reset neighbor tiles yourself to get it to pick the correct sprite. Setting large numbers of tiles at once is/was terribly slow. The APIs are just a bit awkward, too. Godot 3 didn't have any of these issues.

Basically, once you get off the beaten path, things become noticeably janky in a lot of places. I'm sure some of the obvious bugs will or have already been fixed for the beta, but some, like tilemaps, seemed to simply have a response of "it's working as intended", and others (like GDScript scalability or native DLL hot reload) are simply not fixable without another redesign.

For best results, you'd want to use a single charger, and to always put the alternate on immediately.

That said, the watch can notify when charged, which might be a better first step. The settings for that live in the sleep settings, of all places, but might be worth a shot?