Beyond the questions of winter weather properties, there are adjacent tradeoffs between the tire types (outside of studded):

1. Fuel economy

2. Noise

3. Degree of particulate pollution emission

I'm sure that the all-season tires probably have some negative tradeoffs in these regards to, which yields a choose the most optimal product for the time of year. All-season tires to me seem like a convenience food for places where the weather can be legitimately bad.

One other difference that is hard to articulate to North American drivers with respect to understanding Scandinavia and roads: there are places where snow and ice will literally not be removed (maybe not even removeable) from the road when plowed (I presume until spring melt). It just becomes a thick ice pack over the course of weeks. I never encountered any roads in my life (including Northern Minnesota) that were this inclement. North American roads tend to be cleared (plowing or melting) to asphalt or pavement.

The reality of car dependency there means that there are people driving and owning cars who can't really afford to do it properly, nor do they know they need to do it properly (e.g., having a second set of tires for the winter). You can see this evidenced by the rust buckets on the road that look like they are one pothole away from losing part of the vehicle body. Deferred maintenance and investment everywhere and in everything …

I lived in the Oklahoma and in Minnesota, and the difference there is already stark:

* OK suffered from plenty of storm-induced winter power outages (massive freezing rain cycles were common in my life). My mother's cotton bath robe, which she kept using until late in her life, had burn marks from when she reached for something over a lit candle during a power outage when I was four years old.

* MN suffers some, but people knew to develop meaningful contingency plans.

Both states have variegated buried-power-to-the-premises usage. It's not really to be expected as the norm in either place, but MN has far more than OK (funnily enough I grew up in a place in OK with it). Either way, the infrastructure robustness in North America looks like it arose from a dismal cost-benefit analysis versus a societal welfare consideration.

I left North America about 14 years ago for Europe. The difference is stark. We've only had one significant power interruption in that time (not even in winter); whereas stochastic neighborhood outages were commonplace in North America. What really freaks me out about the situation in North America is just the poor insulation of the structures and their low thermal mass. They will get cold fast.

Aside: A lot of friends and family in North America balked at the idea of getting a heat pump due to performance during a power outage: "when the power goes out, I can still run my gas." When I asked them whether the house was heated with forced air or used an electronic thermostatic switches, the snarky smile turned to a grimace.

When you live in a cold place, you learn to do things differently. You're naive if you don't pack warm blankets and water in your vehicle, for instance. You never know when you might find yourself stranded somewhere due to vehicular breakdown …

If you are going to get into the business of introducing order dependence to test cases through global state (see my other reply on the parent), you will always want the cleanup to work correctly.

1. Using (testing.TB).Cleanup is a good defensive habit to have if you author test helpers, especially if the test helpers (see: (testing.TB).Helper) themselves do something (e.g., resource provisioning) that requires ordered teardown. Using (testing.TB).Cleanup is better than returning a cancellation or cleanup function from them.

2. (testing.TB).Cleanup has stronger guarantees about when it is called, especially when the test case itself crashes. Example: https://go.dev/play/p/a3j6O9RK_OK.

I am certain that I am forgetting another edge case or two here.

Generally nobody should be designing their APIs to be testable through mutable global state. That solves half the problem here.

The questions aren't unique to gRPC, however; gRPC forces you to confront them early and explicitly IMO, which is not a bad thing.

All of this makes it paramount for developers of Go tools to use a first-party package loading library like package packages (https://pkg.go.dev/golang.org/x/tools/go/packages), which can ameliorate over this problem through the specification of a GOPACKAGESDRIVER environment variable to support alternative build systems and import path layouts (the worst thing someone can do is attempt to reverse engineer how package loading works itself versus delegating it to a library like this).

When you do this in the wrong order, you end up with very poorly laid out concepts from a code organization standpoint, which is why vagaries like this needed to be written:

* https://google.github.io/styleguide/go/best-practices.html#p...

* https://matttproud.com/blog/posts/go-package-centricity.html

In languages that operate on a flat namespace of compilable units (e.g., C++ or Java), build target sizing and grouping in Bazel (and its relatives) largely doesn't matter (from a naming the namespace and namespace findability+ergonomics perspective). But the moment Bazel starts interfacing with a language that has strict organization and namespacing concepts, this can get rather hairy. The flat namespace practice with Bazel has (IMO) led to code organization brain-rot:

> Oh, I created another small feature; here, let me place it in another (microscopic) build target (without thinking about how my users will access the symbols, locate the namespace, or have an easy way of finding it).

— — —

Note: The above is not a critique of Bazel and such. More of a meta-comment on common mispractices I have seen in the wild. The build system can be very powerful for certain types of things (e.g., FFI dependency preparation and using Aspects as a form of meta-building and -programming).

I imagine FyneDesk is plenty fine for what it is doing in comparison.

Note: That link's (actual) photographs seem to suggest that the topic was not adequately researched or generatively produced.

Namely the photo with the caption "The Origin of Swiss Traditional Dress Photo by Cabinet Card Gallery" contains a sign within some words that indicate that even though these are Swiss people in the photo they are actually wearing costume to celebrate Austrian traditional costume of the region of Styria. The hints are "Steirisch" (Styrian) and "Buachstoana" (looks like a phonetic spelling of a Bavarian/Austrian dialect word as opposed to Swiss German and "Verein" (club/association). If someone could expand the "erh." abbreviation in a period-correct way, that would probably be definitively telling. This also doesn't resemble much of the Tracht I have seen worn at festivals in Switzerland either (regionalisms aside).

Latency is a deal-breaker for me, and this is where autocompletion engines generally introduce surprising user-interactive pauses. I've generally settled with using mksh (or OpenBSD's KSH depending on the environment) with little configuration outside of aliases, variables, and few local functions. I'm not left with this inkling feeling like accidentally running find(1) over an AutoFS file system backed by NFS that needs to authenticate, mount, and then run the operation.

When I need something more sophisticated, I lean on using Go or Elvish and potentially delegate some UI elements out to https://github.com/charmbracelet/gum.

I'd rather keep my shell simpler and delegate out any other complexity to these other programs. Autocompletion and these other features simply aren’t free.

We also know that in North America that the municipal services skimp on grade separation for bike lanes for budget and political reasons. I did bike in San Francisco when I lived there, and these non-shared colored lanes never ever felt safe.

I can guarantee that if you leave your North American context for a couple of years and come back to it you'll find CA Vehicle Code § 21453 unsatisfactory.

* Waymo vehicle creeping into the pedestrian crosswalk (while the pedestrians had right of way to cross), which caused someone to have to walk around the car into the intersection ahead of the Waymo.

* Waymo vehicle entering a dedicated bike lane and practically tailgating the bicyclist that was ahead of it.

These might be safer than human drivers in aggregate and normalized by kilometer driven, but they drive like humans — greedily and non-defensively. I wouldn't want one these anywhere near a high-pedestrian traffic area ever, and I feel the same about human-driven cars, too.