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.
Apparently it's just moving that to runtime, which is kind of terrifying and misses the point. "If the owned value is dropped but references to it still exist, a panic is produced and the program is aborted; protecting you against use-after-free errors." [1]
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.
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.
Semi-relevant, I've recently realised that fear of wildlife is actually cultural - large parts of the world are taught to fear/avoid smaller wildlife like snakes or insects, for poison/disease reasons. It works great in those places, but if they come to Canada they can see bobcats/mountain lions and think house cat, or other large mammals (moose, bison, elk) and just think they're cute and should be petted.
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.
You don't even have to go north, really. Just driving a few nights on a quiet, dark road outside the big cities late at night will convince you that deer 1) basically teleport 2) are stupid 3) can be absolutely terrifying when they show up out of nowhere, despite 2. (And yes, 2 only really applies w.r.t. cars and roads.)
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 can't recall for certain, but I think the Hue lights are brighter than IKEA's Tradfri lights. Certainly the newer 1100 lumen (max) ones should be. There's also the issue that the Tradfri lights have absolutely abysmal color replication, where green is some kind of weird lime color, blues are oddly cyan, etc. Hue is much better on that front.
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.
I think 2D tilemaps is a great example of how quickly Godot can fall over terribly, though. And that's (as has been mentioned elsewhere) mostly an issue of polish. Godot can do the basic version of a lot of things, but if you need more you often get very deep into the weeds, very quickly.
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.
I usually charge my watch while sleeping and grab it in the morning along with my phone, but I'd assume a second watch would work? It's an expensive route with the watch, but it's a solution in many other spaces. My wireless headset, for example, has a replaceable, rechargeable battery.
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?
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.