singingboyo

There's some space for improvement, but really... not a lot? Result is a pretty basic type, sure, but needing to choose a dependency to get a nicer abstraction is not generally considered a problem for Rust. The stdlib is not really batteries included.

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.

Physical thank you cards are pretty dead. I don't even keep track of mailing addresses for a number of my friends (and a couple siblings, come to think of it) - how would I send them a physical card?

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.

There are legitimate criticisms that AI is harming creative endeavours. AI output is sort of by definition not particularly innovative. By flooding spaces with repetitive AI work, it may be drowning out the basis for truly innovative creation. And maybe it does suppress development of skills it tries to replace.

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.

There's a difference between contempt (i.e. "users are stupid") and realism, though. And realism can range from "users don't want to troubleshoot" to "some users are near-violently anti-tech and won't read errors", depending on context.

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.

Also, as a Vancouverite... 5-6 stories, cheaper to live there, AND more comfortable? Dunno about that.

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?)

> You can see plenty of other skyscapers, some looking similar height or nearly as tall. Just not any on the side of the river the Squamish are planning on building.

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.

More importantly, knowing and caring are two different things.

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.)

Eh. Military aircraft would also have a transponder, they just wouldn't necessarily have active broadcasts.

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.

This still doesn't explain why the language of the compiler matters. I could write a C compiler in Pony-lang targeting a 30-year-old MCU were I so inclined.

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.

The point is that you limit where you're doing that.

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.

Sometimes the reviews are about the game, but they're being left because that's the thing to do according to the internet that day. So a legitimate grievance but blown of proportion due to factors outside the game.

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

You can see the sun? All I see is grey smoke slowly settling down on us.

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

I mean, I'd love to just for the space savings alone. Multiple monitors take up quite a bit of space. If I could repurpose the space for other things without losing functionality that'd be great.

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.

It's not an artificial distinction at all, but it is subtle.

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.