Is this not how four way stops work everywhere? I live in Kansas and have previously lived in Chicago, and I feel like both places follow this custom. Only thing that’s different is the laws are followed slightly more rigorously in low traffic areas, but the customary rules are definitely still in play.
That's how any relatively busy 4-way stop works in Ohio, too. The law says to do it one way (first to arrive, yield-to-the-right, wait for intersection to clear before entering).
But in practice what happens is an unscripted ballet where other things happen instead, like: Like, 4 cars can turn right simultaneously, and this works fine.
People know it's "wrong," but they also know it works. It's normal, expected, and a bit weird.
The weird part is something I've only ever really observed when I've driven cop cars around the block and had to traverse a 4-way stop. Other drivers stop the ballet immediately and get all timid and stuff -- like they're waiting for me (just someone being a lowly radio tech today, not a cop at all) to give them direction or something. It's bizarre.
I had a classmate in the military whose old car got t-boned and so he went and bought a used white Ford Crown Victoria (for the non-US folks, used to be the most common US police car ~10-15 years ago).
He had funny stories about people slowing down to the speed limit and pulling over to the right lane on the freeway.
> Other drivers stop the ballet immediately and get all timid and stuff
I can personally attest as to why I suddenly get weird when at a 4-way with a cop: I don’t remember exactly what the rules are, what’s “ok” as in not technically illegal (ie 2 cars crossing at the same time?), etc, and the panic of getting pulled over because of some minor detail makes me just wait however long I need to to get a clear turn. It’s silly, I know how it works, and when that authority figure is present I just want to avoid any and all interaction.
I’ve never really understood the issue with this. I find it quite useful to know what functions may do something async vs which ones are guaranteed to run without stopping.
In my current job, I mostly write (non-async) python, and I find it to be a performance footgun that you cannot trivially tell when a method call will trigger I/O, which makes it incredibly easy for our devs to end up with N+1-style queries without realizing it.
With async/await, devs are always forced into awareness of where these operations do and don’t occur, and are much more likely to manage them effectively.
FWIW: The zig approach also seems great here, as the explicit Io function argument seems likely to force a similar acknowledgement from the developer. And without introducing new syntax at that! Am excited to see how well it works in practice.
In my (Rust-colored) opinion, the async keyword has two main problems:
1) It tracks code property which is usually omitted in sync code (i.e. most languages do not mark functions with "does IO"). Why IO is more important than "may panic", "uses bounded stack", "may perform allocations", etc.?
2) It implements an ad-hoc problem-specific effect system with various warts. And working around those warts requires re-implementation of half of the language.
No, it's not. `async` is just syntax sugar, the "effect" gets emulated in the type system using `Future`. This is one of the reasons why the `async` system feels so foreign and requires so many language changes to make it remotely usable. `const` is much closer to a "true" effect (well, to be precise it's an anti-effect, but it's not important right now).
Also, I think it's useful to distinguish between effect and type systems, instead of lumping them into just "type system". The former applies to code and the latter to data.
>That feels dense.
Yes. But why `async` is more important than `alloc`? For some applications it's as important to know about potential allocations, as for other applications to know about whether code potentially yields or not.
Explicitly listing all effects would the most straightforward approach, but I think a more practical approach would be to have a list of "default effects", which can be overwritten on the crate (or maybe even module) level. And on the function level you will be able to opt-in or opt-out from effects if needed.
>I think ideally it would be something readers could spot at first glance
Well, you either can have "dense" or explicit "at first glance" signatures.
Is this Django? I could maybe see that argument there. Some frameworks and ORMs can muddy that distinction. But most the code ive written its really clear if something will lead to io or not.
I've watched many changes over time where the non async function uses an async call, then the function eventually becomes marked as async. Once majority of functions get marked as async, what was the point of that boilerplate?
Quick correction: The mac mini does have a fan. Studio is definitely more capable due to bigger, better chips, but my understanding is the mini is generally not at risk of thermal throttling with the chips you can buy it with. The decision for desktop macs really just comes down to how much chip you want to pay for.
My heuristic is that quality is largely a function of human attention during creation. The transition to digital layouting etc meant less human attention could be spent on it while still achieving “acceptable” results, and so market dynamics ensured that less attention was spent on those tasks, lowering quality.
Whether or not you personally would make this cost/quality tradeoff comes down to the individual, but to me it is also quite clear that something was lost in the transition.
I think another thing is a lot of modern stuff is under thought, either in trying to be overly broad or just misunderstanding the user.
Google Shopping is an example. It has enforced opinions about what a product looks like, so you have to force a square peg through a round hole.
They’ve got a lot of stuff about pricing and loyalty and quantities, but if you dig into tons of categories they have almost nothing that represents the real categories sellers and buyers care about.
Look at the collectibles category. If you sell Pokémon cards and collectibles there is zero merchandising info that actually matches your products or how they’re sold.
That means your analytics, automatic listings, ads, etc. are too generic for your customers. All your automated stuff is going to come through wrong.
Meanwhile niche and deep sellers who avoid that forced genericisation, like McMaster-Carr[1] can have these incredibly valuable, useful, and compelling catalogs.
I’d say that deep user knowledge is why Aperture had such a strong fan base too.
I struggle with this buying from Lee Valley. Their caralogs are fantastic, but I have trouble finding things on their website.
This turned into a rant, but maybe a TL;DR is a lot of modern software has no skin in the game of specialization, and so they inadvertently limit these experiences.
This is great. I’ve had many side projects with Cloudflare where I’ve wanted a way to send emails as a part of it, and it’s slightly annoying having to go find another service to use to get that done. Having this baked-in will he sweet!
This is sort of a strange reply. You don’t have to spend any time on art at all really. For many people, the more they can spend time enjoying the art they like, the better. If you don’t like the art, that’s one thing, but if you do like it, why must it be shorter?
The video game community is often pretty explicit about this. They want their favorite games to be longer, not shorter, because they want to spend more time enjoying it. I don’t think it’s so strange that people may apply the same mentality, to books, movies, etc as well.
I agree, although there’s a lot of selection bias at work here: companies usually don’t get bought by private equity unless they’re already in distress, so whatever they were doing before the acquisition clearly wasn’t working.
C.f. Private equity entrance to the veterinary market. Were they all really distressed? The issue is valuation of company vs underlying assets, isn’t it? Distress is one way, but a solid company not squeezing all of the value out of its customers / capital is another.
I mean, these things aren’t static. Python may be the second most popular language (behind JS/TS) today, but what if elixir takes over 10 years from now? There is no need for browsers to implement every language-of-the-day.
Additionally, browser JS adheres to a quite strict backwards compatibility requirements. Python can and does deprecate and remove APIs, and I would imagine the community would not like to lose that flexibility.
WASM is probably the best bet here, in that it provides a well-specified low-level target, such that the door is open for other languages for anyone who is allergic to learning/using javascript.
