I'm in the "Pro-Rust" camp (not fanboy level "everything must be rewritten in rust", but "the world would be a better place if more stuff used Rust"), and I love this post.
They saw some benefits to Rust, tried it, and continued to measure. They identified the Typescript/Rust language boundary was slow, and noticed an effect on their contributions. After further research, they realized there was a faster way that didn't need the Rust dependency.
I'm not sure your characterization is all that accurate.
Originally, they thought they could build a product that worked across many languages. That necessitated a "lowest common denominator" language, which is a void that has always been strangely lacking in choice, to provide an integratabtle core. Zig had only been announced a few months earlier, so it wasn't really ready to be a contender. For all intents and purposes, C, C++, and Rust were the only options.
Once the product made it to market, it became clear that the Typescript ecosystem was the only one buying in. Upon recognizing the business failure, the "multi-language" core didn't make sense anymore. It was a flawed business model that forced them into using Rust (could have been C or C++ instead, but yeah) and once they gave up on that business model they understood that it would have been better to have been written it in Typescript in the first place — and it no doubt would have been if it weren't for the lofty pie in the sky dreams of trying to make it more than the market was willing to accept. Now they got the opportunity to actually do it.
> I'm in the "Pro-Rust" camp (not fanboy level "everything must be rewritten in rust", but "the world would be a better place if more stuff used Rust")
While techno-religiosity is irrational and unprofessional, but that's some weak, eye-rolling both-sidesism.
The world would be a better place™ if more stuff used better and more formal tools and methods to prove that code is correct and bug-free. This is easier in some languages than others, but still, there's a lot of formal verification tools that aren't used enough and methodology patterns and attitudes that are missing from crucial projects and regular use. Effective safety and security assurance of software creation takes effort and understanding that a huge fraction of programmer non-software engineers don't want to undertake or know anything about. This needs to change and is defensible, marketable expertise that needs to be appreciated and cannot be replaced by AI anytime soon. There's no "easy" button, but there are a lot of "lazy" "buttons" that don't function as intended.
> I am also wondering if Meta still uses PHP or Hack
Meta’s WWW codebase is its oldest, and still written in Hacklang. Lots of internal tooling is also written in Hack.
I wouldn’t be surprised if there are more committed lines of Hacklang than any other language (although, a good chunk of that is codegen, vs other core languages where codegen is part of the build process).
Even otherwise, at the scale the company operates it's much better to run codegen once at commit time rather than recreate the entire codebase on every deploy (several times a day) which would take forever.
Coming from a Meta background (not speaking on behalf of Meta):
"package/dependency management" - Everything is checked into a monorepo, and built with [Buck2](https://buck2.build/). There's tooling to import/update packages, but no need to reinvent pip or other package managers. Btw, Buck2 is pretty awesome and supports a ton of languages beyond python, but hasn't gotten a ton of traction outside of Meta.
"linting, formatting" - [Black](https://github.com/psf/black) and other public ecosystem tooling is great, no need to develop internally.
"why is type checking the exception" - Don't know about Astral, but for Meta / Google, most everyone else doesn't design for the scale of their monorepos. Meta moved from SVN to Git to Mercurial, then forked Mercurial into [Sapling](https://sapling-scm.com/) because simple operations were too slow for the number of files in their repo, and how frequently they receive diffs.
There are obvious safety benefits to type checking, but with how much Python code Meta has, mypy is not an option - it would take far too much time / memory to provide any value.
The "Memory Safety" of Rust is not that memory leaks are not possible, rather its how memory is accessed. Specifically, using "safe" Rust, it should be impossible to:
1. Access memory that hasn't been explicitly allocated to your program
2. Access memory that was was previously allocated and freed by your program
3. Access memory that could be modified by a separate thread / function of your program, outside of some locking mechanism.
I'm sure there's a more academic definition, and stronger guarantees, but those are the basics.
Now, these guarantees impose restrictions on how code is written, and runtime overhead to enforce. There are many cases where a human can write optimizations and ensure those guarantees in a way the compiler cannot verify. This is why Rust has an "escape" of writing "unsafe Rust", where the compiler does validate those guarantees. Unsafe Rust includes expanded primitives, such as "Box::leak()", that enable writing these optimizations, and may explicitly leak memory without maintaining a reference
If a program is written using purely safe Rust, it should not be possible for a malicious input / request to corrupt internal data structures, read memory that shouldn't be read, or all the other "interesting" things that get highlighted by Heartbleed and other big security vulnerabilities.
Note that I say "should not be possible" - the Rust compiler can and has had bugs that break those memory safety guarantees under certain conditions. They aren't common, but it's unfair to say "Rust is perfect and 100% safe"
I strongly recommend everyone learn Rust, at least to the point where you "grok" the borrow checker and what it's trying to enforce, even if you have no intention with regularly using Rust. After learning Rust, I found the patterns the borrow checker enforces incredibly useful when writing C++, and ensuring I don't make silly memory mistakes that may result in a crash or vulnerability.
> the legitimate ones I’d initially generated still worked
This spooks me. I take this to mean either:
- They are still using the compromised key for validation, meaning if you have access to any old token, you can still mutate that, maybe needing to play around with the issuing times
- They built an allowlist of all permitted tokens, and check that list first. In which case, might as well use random session ids instead of JWTs, and at the same point where the allowlist is being checked, mutate the request to inject a JWT that the backend can use.
Also, kind of curious why the switch to RSA4096 instead of elliptic curves, since they are generally faster / smaller.
Ah that makes sense. For sufficiently small values of N, a hardcoded allowlist isn't a problem.
You're probably right that RSA 4096 "just worked", and some library in their stack doesn't have elliptic curve support. And again, if N is small, the verification performance doesn't matter that much.
+1 to this. I run Ubuntu 22.04 with microk8s. Keep all my yaml files in a local git repo, figured out how to hook up my NAS to provide storage via nfs.
It's definitely gone down a few times, but I've learned a TON tinkering with it. super easy to spin up a new hobby project, a nice web UI for seeing what the heck is going on.
I've completely borked it a couple times and survived one micro pc migration. Can't recommend it more
I was on the jury of a federal fraud trial with 2 defendants with 15 charges, ~30 million in losses.
We were thorough and went through each count separately, including reviewing some of the evidence, and were done in maybe 8 hours spread across 2 days.
We ended up with a mixed verdict: one count not guilty for both, another not guilty for one. I fully believe they were aware and committed fraud for the not guilty counts, but the prosecutor wasn’t able to cross the “reasonable doubt” threshold in our minds for those specific instances.
Only thing we weren’t super careful about was the first requirement for Mail/Wire fraud, which is “Mail and wires” were used.
It was amusing that the prosecutors brought in a bank IT guy to explain that “the internet uses wires”, but not really something we questioned.
And are modern fiber optic cables wires in any sense of the word? Does the relevant statute in USC18 actually define "wire" for the purpose of the crime?
Part of me thinks that wireless communications must be included, but one might make the case that even then, information/communication is transmitted over wire at some point.
"having devised or intending to devise any scheme or artifice to defraud, or for obtaining money or property by means of false or fraudulent pretenses, representations, or promises, transmits or causes to be transmitted by means of wire, radio, or television communication in interstate or foreign commerce, any writings, signs, signals, pictures, or sounds for the purpose of executing such scheme or artifice"
UPDATE: Various court decisions have expanded the interpretation so that "wire fraud" also involves the use of the internet, phone calls, emails, social media messages, faxes, telegrams, fiber optic, cable or SMS messaging and data systems.
I am not a lawyer, though. I could be mistaken on this.
“So, contrary to popular belief, the internet is not some big truck that you can just dump something on a la Ted Stevens; it’s more of a … series of tubes?”
Is there any way to tie an expectation of long term security support with legal protection of the product against competitors/reverse engineers/other parties that manufacturers may not want looking too closely?
I’m not suggesting granting additional protections to manufacturers, but codify an expectation of “if you abandon it, other people can come in and potentially salvage it”
They saw some benefits to Rust, tried it, and continued to measure. They identified the Typescript/Rust language boundary was slow, and noticed an effect on their contributions. After further research, they realized there was a faster way that didn't need the Rust dependency.
Good stuff, good explanation!