You get to choose between UB, a crash, or handling the error — same as most other languages.
It’s not a reliability issue of the language if as an author of software you choose to crash in your failure handling cases. Claiming otherwise is either disingenuous or a failure to understand what actually happened.
No, it's not the "same as most other languages". C and C++ are actually the only mainstream languages that suffer from UB to this extent.
The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt. And blaming the crash on the author, saying they "chose to crash", is exactly the same as blaming UB on the author of C code, saying they "chose to double-free".
> The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt.
This is totally false. It's not in the least hard to avoid crashing.
match some_result {
Ok(value) => { // handle the value },
Err(e) => { // handle the error condition }
}
The fact that Cloudflare chose to handle a result with the "panic if this result is an error" function is 100% on them, not on the language. Blaming the language is like claiming that any language which has assert is a problem because the assert can crash your program. Yes, that's what it's there for, so don't use it if that isn't what you want.
And don't give me the "the method name isn't obvious enough" argument you used elsewhere. That holds no water. It's basic Rust knowledge to know that "unwrap" will panic if the value is an error (or None if it's optional). If the engineers writing the code didn't know that, then the problem is they didn't bother to learn how their tools work, which again is not the language's fault.
What UB? This has nothing to do with UB; it'd be well-defined in any language. It's equivalent to this python snippet:
config = load_config()
if !config.valid():
sys.exit(1) # config is corrupt. restart pod
Did Python do something wrong by letting users call `sys.exit`? No. This is a deliberate crash. Under other circumstances, crashing might have been a valid strategy, but here it turned out to be a bad choice, since Cloudflare's infrastructure was restarting the service with the same bad config every time.
Sys exit does not crash. It raises a SystemExit exception, which can be caught on any layer above it. Given that python uses exceptions for trivial things like loop termination this can be considered normal flow control.
Yeah, and in Rust you can catch the panic from `unwrap()` with panic::catch_unwind. You just don't, for the same reason you don't catch SystemExits. If a SystemExit is being thrown, it's because you want to crash; if you don't wan to crash, don't throw a SystemExit.
If I could choose between UB and a crash I will chose the crash every time. The sooner the better, preferably in test. And that's where CF's real failure was.
It really won't. The only reason I could think of is if there were a Sphere(Sphere*) constructor, which would be weird, and is also not the case [1]. There is also no reason to use a vector<Sphere*> since Sphere is not part of an inheritance tree; a vector<Sphere> would've done just fine removing the calls to 'new' in that blog post.
Overall, I think this post is on the low end of the quality spectrum. I think the author is a bit confused about things, like they've been doing JS and picked up C++ only recently. Nothing bad about it, but I would do some more reading before posting much of anything.
I've done it before to integrate rust into polyglot build systems. There's a surprisingly long history of build systems trying and failing to implement rust builds without the "happy path" of simply wrapping cargo. As far as I know no one's ever succeeded.
The problem with giving each team a repo and an API surface is that you create API boundaries where your organizational boundaries are, not necessary where your service boundaries are. And as your organizational structure evolves over time, your repo and API boundaries lag behind since it’s so difficult to make large scale shifts to the code.
I don't see that as a bad thing. By creating granules you constrain that evolution such that nobody ends up with half of a thing. Without those boundaries, people who don't understand the code may motivate organizational structures which don't make sense.
That's where I've been for a few months: The work of prior gatekeepers now run through the middle of what we're responsible for. It feels like we bought a house online and when we showed up the kitchen is in one country and the bathroom is in another so we have to clear customs several times a day and we have to hold a summit with the friends of the previous owner if we want to change anything--even things in the interior. The architect of the reorg would never have done this if the natural boundaries had been a bit more apparent, i.e. as a list of repos to be assigned to the new teams.
I'd prefer large scale shifts to come by replacing an old repo with a new one (or one with two, or two with one, or by open sourcing one which you no longer care to maintain). Maybe that slows down the organizational rate of change, but if the alternative is pretending to have changed in a way which isn't actually sustainable, then maybe slowing down is better.
More recent commentators have noted a corollary - for software projects with a long lifetime of code reuse, such as Microsoft Windows, the structure of the code mirrors not only the communication structure of the organization which created the most recent release, but also the communication structures of every previous team which worked on that code.
Arc is an atomic (not automatic) reference counter which can be used across threads. Reference counting in general can still be tricky to use when you need cyclical references though, which is what it sounds like the spec has.
Would forcing disclosure of non-authorized parts not address that? If you were willing to pay the premium for authorized parts then you’d have the information to choose the right repair shop.
the problem is, will unregulated report shops be able to do the repair from knockoff parts? I know the last time a fingerprint sensor broke for a phone, i had to replaced for US$1. had to pay $3 for labour but the part cost just $1. its working for the past 3 years so yeah.
I live in Switzerland and I get why repairs are expensive. Because the labour is really expensive. I did multiple repairs (not on phones) where the labour was more expensive than just buying a new device (cheap printers).
>Under the Magnuson-Moss Warranty Act (MMWA), it is illegal for a manufacturer to void a warranty or deny coverage if a customer has a repair or maintenance performed by an independent repair shop or using a third-party replacement part (unless the original manufacturer provides the service or part for free).
Wait, so if a third party repairer puts in a dud part that fries the rest of the system, they still have to provide a warranty replacement of the whole thing?
But it's not illegal to require a licensed "authorized" repair shop use the OEM part, nor is it illegal (unfortunately) to decline to sell OEM parts to unlicensed repair shops.
car manufacturers market "genuine OEM spare parts" as if we have a moral and social obligation to pay for their parts 4X than the same part from cheap chinese knockoff brands.
They too are buying from the same chinese OEM, just their "brand sticker" gives them the power to charge a high premium
> They too are buying from the same chinese OEM, just their "brand sticker" gives them the power to charge a high premium
This is actually incredibly false. I have several collages that came from the automotive industry, for automotive chips. The automotive industry is not using the same Chinese OEM parts, for any of the safety critical ICs, which come in some of those expensive OEM parts.
In fact, they have incredibly complicated processes, with full supply chain lockdown/inspections, to keep cheap Chinese knockoffs out of the supply chain, in direct response to human death from Chinese knockoffs making it into the supply chain. When a knockoff is used, and it makes it into a car, that vendor is blamed, when someone dies. Vendors put extreme pressure on these companies to make sure they don't make the news for killing people/recalls.
All of that, obviously, adds a premium over the unqualified knock offs.
I'm not sure about structural parts, but I suspect it's similar.
Doesnt have to be Chinese vendor. https://www.youtube.com/@M539Restorations prides himself on using OEM parts, but he often goes directly for actual manufacturer because that source tends to be much cheaper than BMW dealer. The only difference is marker/machining over BMW logo on the part.
Personally, I do not want anymore cheap Chinese knockoff parts anymore. I don’t want screens that have off colors, batteries that last 1/3 of their rated power, toner cartridges that last half as long as the OEM ones, etc.
I really am willing to pay 4X the price for something that’s twice as good. Half as good isn’t good enough for me anymore.
Please read this carefully: Apple will NOT _sell_ you a battery cheaper than their inhouse genius bar battery service fee. Apple can barter a battery for ~$10 cheaper than that fee if you:
- tell them detailed information about the device in need of a new battery, wait up to a week for that bespoke battery to arrive, then send old battery back.
- agree to share all of your accounting with Apple, now and I think up to 5 years from termination of the contract.
- agree to share all of your client details with Apple.
- agree to audits checking if you dont posses any third party parts that could be used in Apple products.
- agree to never repair Apple product beyond strict list of services approved by Apple.
There are union types, which despite being untagged might be enough in a lot of situations, and I believe has language support in things like switch statements.
But eh, that is not the case in crystal. You are not on your own - the language knows what a variable is during runtime and you have plenty of ways to dispatch between the types.
It’s hard to fault SpaceX for realizing a market opportunity here. If they can bring decent Internet to rural areas who don’t currently have broadband access, that’s just mutually beneficial for SpaceX and those customers.
When (if) those customers ever get broadband access by additional infrastructure investment, SpaceX will need to find a way to provide better value. I’m not sure I understand how this is a bad thing.
I’m always surprised to hear folks having such negative opinions of beyond and impossible burgers. I quite like the taste despite it not being an exact beef flavour, and I think the texture is more or less spot on.
It’s not a reliability issue of the language if as an author of software you choose to crash in your failure handling cases. Claiming otherwise is either disingenuous or a failure to understand what actually happened.