jtdowney

> - Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language.

I'd disagree with both of these. They may not be to your style but that doesn't make them rushed. Both features had long debates around their adoption.

> - Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.

That is irrelevant to this project. You should read the rust kernel docs to see why.

> - Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with.

Also irrelevant. This may be a criticism of Rust but it in no way affects how rust may be adopted into linux.

> - Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making.

Linus is famous for doing fashionable things and forgoing technical decision making.

Dan went into a little more of the backstory last year during the first awarding of the Levchin prizes. If I recall correctly, he and Max had been long time acquaintances and Dan even advised Max while he was working on some of the early PayPal technology. Max told a story about Dan leaving his own birthday party to help Max debug a CSPRNG.

I've spent time with lawyers on specifically this topic. It is about who is distributing the crypto code. There is also an exemption for open source crypto code. On iOS you definitely do not need to register your app if it is just using the built in HTTPS functionality. Hire your own lawyers if you're really worried about it though.

I'm the Security Lead at Braintree. I am not sure what you're hearing in these circles. If someone could send details to [email protected] we'd be happy to take a look.

Both Stripe and Braintree require you to use SSL (really TLS) on your checkout pages. They also both require you maintain PCI compliance (although you likely qualify for a reduce set of requirements).

To be fair, Cloudflare has no concept of how much reputation you have on HN.

I agree! I submitted it as separate item because this conversation was about rewriting iframes. Although hosted fields doesn't directly address the rewriting for now, we're looking at it closely.

At Braintree, we have been working on the approach you mentioned. We’ll soon update our iframe products to allow a merchant to opt-in to only ever receiving cardholder data via the Braintree iframe. With this change, we could actively block malicious JavaScript from rewriting the merchant form by rejecting data not from the Braintree iframe. Things like this aren't a panacea though which is why it’s important for merchants to use technologies like Content Security Policy and leverage as much of the browser security model as possible.