The thing they were gesturing at, correctly, is the naming. This is of course a convention and not a promise, but by convention Goose::as_crow would be a function that is cheap and gets you say &Crow instead of the &Goose you might have now, whereas Goose::to_donkey suggests that although we can have a Donkey instead of this Goose it's expensive to do that.
Commonly as... conversions are actually no-ops at runtime (the type changes but the data does not, no CPU instructions are emitted) whereas to... conversions might do quite a lot, especially if they bring into existence an actual thing at runtime -- maybe Goose::to_donkey actually needs to go allocate memory for a Donkey and destroy the Goose.
Yes it's unsafe because the Vec doesn't enforce the promise we made about this being UTF-8 text whereas String did, so now that promise is ours to keep and `unsafe` is how we signify that you the programmer took on the responsibility for safety here.
Yes, naming does play a role here, but the biggest hint is `as_vec_mut` returning a reference. For that to work a `Vec<u8>` needs to exist somewhere, and continue to exist after this function returns. For comparison, `to_` conversions generally just return the new data, so this reasoning doesn't apply to them.
You can definitely have a race condition in JS. Being single-threaded means you don't have parallelism, but you still have concurrency, and that's enough to have race conditions. For example you might have some code that behaves differently depending on which promise resolves first.
Preferences don't form in a vacuum though. There's a perception that GNOME is the "good environment" which means its decisions get treated as more important than other DEs' when things change: and that's somewhat self-reinforcing.
Distro: "The most used DE needs first class support, we should probably bend to it" → Distro: "We should probably make this DE the default since it's so widely used and supported" → User: "I choose the default" → Distro: "The most used DE…"
So yes, people have different preferences; but if your preference is GNOME today, it might not be GNOME tomorrow, and "I picked the default" isn't quite the neutral signal it looks like.
where exactly did I say anything contrary to what you said.
Are you implying that GNOME is the only thing that should be considered graphical? That everything else has to be an alternative? That GNOME, by virtue of existing has infinite reprieve to change the definition of user interfaces at their leisure; even if it means breaking muscle memory hundreds of thousands of times over decades.
Since GNOME is the default Ubuntu DE, they have a certain responsibily to listen to the users/devs and leave the system open (to an extent). But their direction is the opposite:
They've been doing massive reduction in functionalities, really insane like limiting copy/past of terminals just to the current screen (which hurts any sysadmin), generally without any way to enable them back.
I haven't heard of any other OSS organization trying so hard to limit freedom of their users/devs, and this is an explicit goal - they don't want to weaken their brand.
GNOME is nothing short of the Oracle of open source.
I fundamentally agree with you. I don't think responsibility is quite the right word. But if they don't seem to care about a massive portion of their users, why are they building gnome at all?
I agree that responsibility is the wrong word, but I've also noticed there's certainly some form of expectation, social responsibility, or care that other projects have and gnome has always lacked. When I started using Linux it was the desktop I liked the most, but some of the choices seem almost hostile or intentionally designed to drive current users away, and unlike most other projects I've used, I've never seen them listen or make improvements based on any feedback from users.
Stripe's fees are well above interchange fees (especially in Europe). On top of that Stripe's pricing for other features (e.g. invoicing and subscriptions) is also a percentage, so you end up paying a ton for those features.
If you use them for subscriptions you are effectively locked with them. The cost of migrating to a different provider (including existing subscriptions AND payment methods) plus the risk of something breaking the renewals is too high for most companies.
Expanding the logic to union of intervals looks cool, but what is the complexity of that? Since you introduce the the possibility of an operation on an interval producing two intervals I suspect executing N operations might have an exponential complexity, which unfortunately makes this unfeasible to use for some common intervals applciations like abstract interpretation, unless you start introducing approximations once you have enough intervals.
Yes, this is well-known (eg. in abstract interpretation). As you said, usually you can set a "cap" to the size of these objects, and start merging intervals when you hit the cap. But at least in abstract interpretation it seems that they simply consider more sophisticated domains than intervals.
I damn near have a stroke every time I try to reason about IPv4 addresses as an integer. But hey, I guess four bytes is four bytes no matter how you read them.
I think it’s one of many that indicates the underlying issues for its adoption. It’s a 90s technology, not as much thought was given about how it would be used.
If you're using managed services that are so complex you need certified people then you're doing it wrong
reply