A bug-for-bug port to Rust is the first step to fixing that. Assuming the port is actually 1:1 without any behavioral changes, these bugs already exist in the Zig code. The difference is now it's known where effort can be dedicated in order to one day have a memory-safe release of Bun. People have absolutely lost their mind over this and completely forgotten the benefits Rust gives you. I feel like I've gone back 10 years reading threads about the Rust port of Bun these are the exact same arguments we see from people advocating continued use of C++.
> Assuming the port is actually 1:1 without any behavioral changes, these bugs already exist in the Zig code
The "1:1" assumption is a massive unjustified assumption. Rust and Zig have different memory models, so it's possible to do a "1:1" translation of Zig code to Rust and end up with undefined behavior in Rust.
For example, Zig code might make assumptions about lifetimes based on implicit knowledge of which allocator was used for some memory. That could cause problems in Rust if you erase the lifetime https://github.com/oven-sh/bun/blob/main/src/bun_core/string...
> Assuming the port is actually 1:1 without any behavioral changes
It's not, that's clear from this kind of bug popping up. Functionally this bug exists because `PathString` was converted into a "safe" Rust API but still works the same internally as the original Zig code did (via using `unsafe`), that introduces UB that wasn't there in the Zig code.
If it was attempting to be a 1:1 with no behavior changes (like c2Rust attempts to do) then this would not have been turned into a "safe" Rust API like this.
Quite to the contrary to what you write, many people pushing for Rust explicitly recommend to be very restrictive about touching existing, battle tested code and only rewrite it if you're substantially refactoring it anyways, or if it is a critical exposed piece of functionality - such as media codecs for example, which have a long history of being broken. The winning strategy that for example the google android team pursues is to not rewrite existing code, but write all new code in Rust, because real-world data shows that vulnerabilities in existing code follow a decay curve - most issues are detected in the early life of the code. That's the strategy that Firefox uses, too. (Though I'm curious about how LLMs change that equation because detecting errors in rarely used code path' seems to be what they're doing well)
And indeed, this is very much what Rust was designed to do with the ability to interface with existing C/C++ code in both directions. So this is the strategy that the designers of the language had in mind from the early days. It's a deliberate choice to offer this, and not an emergent property that was later discovered.
You have couched this correctly, because we all know there are people out there who do go around yelling "Rewrite it in X" without thought (where X is the flavour of the month)
I also wanted to say - your description of the /right/ way to align a project with tech X is a restatement of Martin Fowler's "Strangler pattern"
Can you edit your post - "equation because deteting errors" is ambiguous - deleting, or detecting - I cannot work out which you mean
And yet, all I ever see are attacks against these convenient bogeymen with artistic exaggerations like yours... but I never see the bogeymen themselves.
The only time I've ever seen anything that could be considered Rust evangelist is when someone with a chip on their shoulder shoves a github issue or random comment link in my face. I certainly don't encounter them in the wild.
I'm not saying they don't exist. I'm saying that I don't encounter them in the wild. Certainly nowhere near as often as I encounter people who have a loud and obnoxious dislike of Rust.
What I'm trying to say is that if you see Rust evangelists everywhere, your label is either so wide-ranging as to be useless or you need to rm your rust_evangelist_evidence.txt because it's likely taking up a disproportionate amount of headspace.
A quick scan of your comment history suggests that you see one every day ;)
And - the number of times I have been grossly downvoted for daring to utter a true word about Rust (or even Rust adjacent) will let you know your non-existent Rust evangelists are indeed the bullies - with one now screaming that he is a victim.
If you want definitive proof - look at this sub thread where you're so triggered that people talk about the mere existence of Rust evangelists (and evangelists exist for every tech - they always have and always will - which you would know given your [claimed] history in the field) that you want to argue they they aren't evangelists, they're just poor misunderstood victims.
Note: I say claimed not as a jab but because I don't know you and can only go on your claims in your profile.
My comment history? The very same one that keeps trying to extract out the location of those supposed Rust zealots and never even getting a single response except yesterday... and the linked comment was pretty mild? But I always get downvoted for having the gall to ask? That comment history?
Surely you mistyped that part of your comment with the one I wrote above, right? Understandable.
I guess we'll have to agree that we live in parallel realities though, reading your comment -- which I do find genuinely puzzling. Because I keep not seeing evangelists and the only one using troll-like language here is you, not me ("triggered", really?).
I am looking at the sub-thread. I guess I need new glasses. Still not seeing anyone fanatical / zealot or whatever. What I see are people who try to ground a discussion because a top comment happily tears down a straw man, and those comments are attempting to show that.
> Note: I say claimed not as a jab
Oh, I am sure. Your comment absolutely cannot be mistook for that.
Read the previous discussions on the topic. Your summary is a sensationalist lie, since their change was apparently a smoking pile of hot garbage, and Zig already had similar performance gains in a newer release.
And if you include women (well, all genders) directly in the war efforts you double the amount of soldiers you have, which would increase your chance of winning and not needing to repopulate.
The key here is to refuse fighting. Nobody becomes a hero by becoming a murderer whose goal is to defend the political power of Stalin, Napoleon, Bush, or whoever.
No, suggestion those caveats show that you are out of touch with what is at stake. This is about digital sovereignty, not saving money. It’s about not relying on the US. The US is literally forcing our hands here.
> Are you saying that Microsoft is more wealthy than all of “Europe”?
"In 2024, the EU spent €403 billion on research and development" [1]. In 2024, Microsoft spend $29.5bn on R&D [2]. So about 20 Microsofts makes up the entire EU's R&D expenditure.
Alphabet, meanwhile, spent $49.3bn on R&D in 2024 [3]. It earned $350bn that year. So it would be correct to say that Microsoft and Alphabet's revenues, alone, rival the total amount Europe spends on research and development. (Non-EU non-British spending is insignificant.)
Nah I'm just saying that Microsoft has more disposable money to throw at Teams than Europe has to throw at Matrix because Microsoft is a corporation that is choosing how to spend its money internally and Europe (or the EU, but why leave Switzerland, GB, etc. out of the fun?) would be funding an external entity in a (possibly?) new way.
I'm still learning how the EU applies grants to open source projects for specific feature sets, but I'm guessing that there's a lot of friction that could be removed.
And yeah, I agree that the money needed to improve Matrix is nothing. It's about getting organized and applying that money well.
To me Europe's push for digital sovereignty has the potential to reshape open source software's competitiveness around the world and in turn, Europe's.
> At Cloudflare's scale, I would not be surprised if they require three consecutive events to trigger an alert.
Sorry but that’s a method you use if you serve 100 requests per second, not when you are at Cloudflare scale. Cloudflare easily have big enough volume that this problem would trigger an instant change in a monitorable failure rate.
Let's say you have 10 million servers. No matter what you are deploying, some of those servers are going to be in a bad state. Some are going to be in hw ops/repair. Some are going to be mid-deployment for something else. A regional issue may be happening. You may have inconsistencies in network performance. Bad workloads somewhere/anywhere can be causing a constant level of error traffic.
At scale there's no such thing as "instant". There is distribution of progress over time.
The failure is an event. Collection of events takes times (at scale, going through store and forward layers). Your "monitorable failure rate" is over an interval. You must measure for that interval. And then you are going to emit another event.
Global config systems are a tradeoff. They're not inherently bad; they have both strengths and weaknesses. Really bad: non-zero possibility for system collapse. Bad: Can progress very quickly to towards global outages. Good: Faults are detected quickly, response decision making is easy, and mitigation is fast.
Hyperscale is not just "a very large number of small simple systems".
Denoising alerts is a fact of life for SRE...and is a survival skill.
You seem to insinuate that the correct pricing is using a 3 year commitment. That seems very much not logical to me considering the original promise of the cloud to be flexible, and to scale up and down on demand.
You're also getting pretty stale instances by the end of the 3 years.
At two difference companies, I've seen a big batch of committed instances finally go off contract, and we replaced them with more modern instances that improved performance significantly while not costing us anything more or even letting us shrink the pool, saving us money.
It's a pain, but auto scaling groups with a couple different spot instance types in it seems to be quasi necessary for getting an ok aws compute value.
Elasticity is very expensive, in practice people only use it for one-off jobs, preferably using the cheaper unreliable "spot" instances (meaning the job must support being partially re-run to recover, which implies a complex job splitting and batching platform).
For traditional, always-on servers, you should reserve them for 3 years. You still have the ability to scale up, just not down. You can always go hybrid if you don't know what your baseline usage is.
Should you be designing for a single server to exist for 3 years when you have such elastic compute? Why not design for living on spot instances and get savings lower than hetzner with better performance? What about floating savings plans? There’s a ton left on the table here just to say ‘aws bad’ for some views
The biggest cloud detractors are often the most ignorant about how to run things effectively in the cloud. They try to use the same patterns that they have used for the last 20 years on-prem and are all confused as to why it's more expensive. It's the exact same tired arguments over and over again. They don't want to learn how to do things in a new way.
