Empowering everyone to build reliable and efficient software.
The official GitHub mirror of the Chromium source
I am more paranoid and cautious than, say, 95% of the programmers I've known. Maybe more. I still don't trust myself to write safe C.
Specifically, I do not think I'm smart enough to violate the Chrome team's Rule of 2: https://chromium.googlesource.com/chromium/src/+/master/docs...
> The Rule Of 2 is: Pick no more than 2 of untrustworthy inputs; unsafe implementation language; and high privilege.
I do know of a few C programmers I'd trust: DJB, many of the OpenBSD team, the Dovecot maintainers, and a few others with long track records of security.
But I don't trust myself because I've used fuzzers on my Rust code, trying billions of inputs. And I've found DDOS bugs that would have been crashing bugs in C.
What's more damning, the most careful C code I ever wrote has an enormous, sneaky test suite. It was tested with every sanitizer I could find. It used carefully designed error handling conventions. Still, in the last 20 years, it has been the subject of several CVEs. You see, I relied on a high-quality 3rd party XML parser, and that parser had a handful of bugs.
Out of 7 billion people on this planet, the number that I'd personally trust to reliaby write CVE-free C code is in the low triple digits. I'm not one of them.
Understanding Rust is a cakewalk compared to understanding "undefined behavior" in the C standard, or to making sure a large C program never overflows an addition, or accesses memory out of bounds. But Rust is not the only option.
As an industry, we need to stop making the same endless security mistakes. It's not OK.
Learn 300+ open source libraries for free using AI. LearnThisRepo lets you learn 300+ open source repos including Postgres, Langchain, VS Code, and more by chatting with them using AI!
Python bindings for the simdjson project.
Its magic function wrapping comes at a cost, trading ease of use for runtime performance. When you have a single C++ function to call that will run for a "long" time, pybind all the way. But pysimdjson tends to call a single function very quickly, and the overhead of a single function call is orders of magnitude slower than with cython when being explit with types and signatures. Wrap a class in pybind11 and cython and compare the stack trace between the two, and the difference is startling.
Or even, uh... shell out to perl
Modern embedded framework, using Rust and async.
> others are just batshit-crazy from my pov (the macro system for instance)
Ah yes, I won't disagree here; macros get very complex very fast. It's one of the more undercooked parts of Rust.
> e.g. I don't really see the usefulness of async-await in a systems programming language
This really depends on the task, but honestly it is genuinely useful. Even in places you wouldn't expect, e.g. in embedded: https://github.com/embassy-rs/embassy
And AFAIK there are plans to use async Rust in the Linux kernel.
The modern API for authentication & user identity. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Robyn – Innovator Friendly, and Community Driven Python Web Framework
1 project | news.ycombinator.com | 4 Jan 2024
Introducing Dependency Injections in Robyn with a Twist!
1 project | /r/Python | 4 Dec 2023
Robyn: A Fast, Innovator Friendly, and Community Driven Python Web Framework
1 project | news.ycombinator.com | 4 Dec 2023
Robyn – Web Framework in Rust
1 project | news.ycombinator.com | 27 Nov 2023
Robyn: High-Performance and Community-Driven Python Web Framework
1 project | news.ycombinator.com | 6 Nov 2023