Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
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.
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.
Ex: https://github.com/TkTech/pysimdjson/issues/73
Or even, uh... shell out to perl
https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae7464771...
> 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.
Related posts
- Pylyzer – A fast static code analyzer and language server for Python
- Asynchronous Clean-Up (in Rust)
- Robyn – Innovator Friendly, and Community Driven Python Web Framework
- Introducing Dependency Injections in Robyn with a Twist!
- Robyn: A Fast, Innovator Friendly, and Community Driven Python Web Framework