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.

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.

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

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.

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?

I'm not sure wind and weather are solved. Planes, ships, and to a lesser extent cars/trains are still lost to weather quite frequently. Yes, we can track it better, but people still have to go about their lives in inclement weather. Knowing where it is does not mean we never have to deal with it.

Also, as others have noted elsewhere, hydrogen is still an absolute pain to work with. It's better than it was, but that doesn't make it safe. In-flight fires are still a nightmare on planes - it'd be much worse if the only thing keeping you in the air is a massive hydrogen balloon.

All this is apart from airships being slow, unwieldy, relatively low altitude, etc.

You're technically correct (the best kind!) but in practice one can largely ignore server state in some applications.

I've got a side project where the data is stored server side. In practice, that server side data might as well be a saved file on the clients hard drive.

Is it "all in" on client state? Not really. Do I ever need to worry much about synchronization? Also no. The synchronization is just "send it to the server when it changes, put an error bar up if that fails". Pretty simple.

It's a bit network heavy, but in this case there are other, heavier parts of the app. There are options if data size ever does become an issue - for now it's not.

Incidentally, I feel like this is where something like MongoDB really is a decent choice. The client would probably just preload the data anyway if it were normalized and in Postgres somewhere. API serves out JSON. Why not just... load the JSON out of the DB?

Looks like standard machines and not really servers, but there's nothing wrong there. Fairly clean wiring, no random cables, etc etc. HDD testing is a little sketchy, but they need to be quick-swapped, so it makes sense.

Ever been in a firewall/router manufacturers R&D/QA lab room? Those are so, so much worse. This is heaven by comparison.

For some ratio of cost to weight, with consideration as to where on the ship it is... if you have time to calculate such things. In this case they probably do, if they really care to.

At the scale of these ships, though, if you have to jettison cargo you're probably looking at hundreds of containers or more. At that point it probably doesn't make that much difference which containers you jettison, it'll mostly average out.

In my case, at least, GH actions is the only place with all the secrets necessary to deploy my (small) webapp. Sure, I can generate alternative tokens and pull some things out of 1password, but it'd be time consuming. (Also, changing things like JWT secrets is less than ideal.)

There's also just the number of things it checks. jest runs, lint/build, e2e and acceptance tests, 2 docker builds pushed into ghcr, and then ansible to deploy. It's mildly error-prone to do myself, especially the docker and ansible steps because that's where the secrets come in.

So sure, it CAN be done manually, but the entire point of CI/CD is to do everything consistently, repeatedly, and without the risk of manual error. It took me hours to figure things out the first time. Why would I want to risk doing things manually now?

That's just like, literally your opinion, man.

I get it, sort of. In that case I just tell myself "it's hyperbole for lazy people" and move on. "Could care less", though, that one I cannot reconcile.

I almost feel like that specific usage should come with the 'archaic' tag, but it's reasonably common in slightly older novels, I think? Things like "He still cleaves to the imagined ideals of his forefathers".

It definitely tends to be used in a more philosophical sense than the very physical "cleave a block of wood in two", though.

I generally agree, though I don't think the "saintliness" even matters. The queen as seen by the public is probably a persona, sure, but so long as the persona stays put, she's a symbol of stability, and that is the whole point of the monarchy.

This even shows up in tech - Bill Gates isn't exactly known for widespread political opinions, and while we all know he was probably not a great person early on, he's now generally contributing to universally approved causes, and otherwise just there, so to some extent he's a symbol of the possibilities available through tech.

Meanwhile, you've got Elon, who I think would be reasonably similar - if he could stay the hell off Twitter and stop overpromising so goddamn often. He could have ended up as a symbol for the commercial space revolution and the surge of EV popularity, but instead he's polarising and often hated.

Generally, polarisation isn't great for authority figures. Even in politics this is sort of true - relatively centrist parties often have broader appeal than extreme views. (Though because politicians are our means of changing things, there's also an aversion to politicians with no opinions at all.)

> some brand called Insignia

Isn't that just Best Buy's store brand?

Arguably, the problem is conflating programming as a job with CS degrees. CS degrees cover very little of what day-to-day programming looks like. They're a useful theoretical underpinning, but as the saying goes, "In theory, theory and practice are the same. In practice, they are not."

So, if you go through SICP as an intro to learning those theoretical underpinnings, it's probably pretty good, but you'll also want some more 'real-life' programming experience. If you read SICP expecting some deep insights into programming as a job, then it's probably not going to help.