Competition is fierce and there's only so much innovation you can do as a payment service provider

For starters, they could have made at least every website related to customer-facing payment flow as fast as stripe managed to deliver pretty much right from the start.

I am so so glad to not be at either PayPal or IBM right now.

Everyone knows someone who has a story like this. Not a good look for a major PSP.

Braintree also is and isn't compatible with the legacy PayPal stack, of which there are 3 layers, depending on whom you ask.

It's the wrong abstraction though and I am kind of not surprised the Bun maintainers went way. The correct abstraction would be to translate into Rust while using `clone` and `copy` liberally and then iteratively converting to a borrowing model. Nowhere at all was an introduction of the `unsafe` keyword needed.

That's only the correct abstraction if you intended to hold off on releasing the rewrite until you were completely finished, because there's no universe where Bun of all projects releases a production version that uses clone and copy liberally.

Unsafe in theory in a transliteration is only as unsafe as the original Zig was, which makes it a perfectly reasonable place to land as a transition point in a way that introducing large numbers of allocations simply isn't.

This isn't propaganda, the Rust compiler's rules when using the unsafe keyword are difficult to uphold, which is why the community wrote Miri.

Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block?

And how does Miri help solve this issue?

> Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block?

By the engineer's wit of course!

> And how does Miri help solve this issue?

By detecting undefined behavior caused by violation these rules

> By the engineer's wit of course!

Seeing how the Rust compiler isn't an LLM, it can't really work on wit.

From the POV of a programmer, how would you implement an unsafe block? What is disabled vs what's enabled?

> By detecting undefined behavior

Say you are tasked with making Miri; how do you detect violations of these rules?

It's true and I write Rust and love it dearly. There is an entire book about working with the unsafe keyword and its aliasing rules: https://doc.rust-lang.org/nomicon/working-with-unsafe.html

There is almost zero reason for a public facing, non-embedded project like Bun to use unsafe anywhere.

You do have to inevitably use unsafe because of FFI (Bun uses existing C++ modules like JavascriptCore for most functionality). Optionally also for performance (at least if you want to win Deno on that front)

This is untrue. You can do a file by file translation by using clone and copy liberally. After you're done, you can incrementally introduce borrowing.

You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did). But either way, you're still stuck with a code base that's going to need extensive refactoring if you want to actually take advantage of rust.

Which is still a step ahead of Zig, which requires an entire rewrite to have the tiniest shred of RAII or borrow checking. What's your point, that if we can't do everything perfectly in one step we can't do it at all?

> Which is still a step ahead of Zig

First off, you seem to be under the impression I'm a rust hater. Noting could be further from the truth. Rust is easily my favorite language at this point, I reach for it for basically everything (except quick scripts). While I do like a lot of zig's philosophy, I think at the end of the day the empirical evidence is overwhelming that manual memory management isn't sufficient.

> What's your point, that if we can't do everything perfectly in one step we can't do it at all?

My point is exactly what I initially said: you typically aren't much closer to a (mostly) safe rust codebase if you've done a line by line port to (partially unsafe) rust than you were to start with. Getting to safe rust is very likely to require substantial refactors either way. This doesn't mean you shouldn't do it (on it's own), but it does mean that the bun team's strategy/assumptions are more questionable than they appear to realize.

> You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did

As in, they did not, which I can prove by using Miri and seeing hundreds of errors.

I didn't say they made a good, safe port. I literally said the opposite ("especially if you're flexible about actually upholding rust's rules"). You can get a line by line port to compile by just wrapping the parts that violate rust's ownership rules in `unsafe`. You won't have fixed the problem, and it won't be memory safe, but you can do it.

Well, only if Clone/Copy is compatible with the semantics of the API. I.e., the called function doesn't need to modify anything. No &mut params (or data members) except perhaps `&mut self` (which would refer to definitions the same file).

That's usually the case for Rust programs because the language encourages it. Are Zig programs like that?

To be fair, you can throw an Arc<Mutex<_>> or Rc<RefCell<_>> at it if you're starting from something that has multiple "mutable borrows", but that adds runtime cost and complexity.

The industry isn't biting @ Zig because it's unstable, notoriously difficult to integrate new changes into an existing codebase and because the compiler is a bitch to develop with (hard error on unused variables with no way to turn it off).

Go has that same problem/feature

Yes, sadly.

Not sure that last one rings true. There are entire languages with no allowed unused variables (some without prepending a _ to the names) that people love to develop with.

In the industry, how often is it that a tool/language is picked up for the ease of developing that tool, vs ease of using that tool?