* Progressively introduce Rust instead of replacing entire applications (Rust really shines in this area)
* Leverage node's strong HTTP and routing story while waiting for this to stabilize in Rust
* Leverage existing tooling for APM, config management, etc.
For example, one middleware verifies the request body with a signature from a header. Another one parses the body from a `Buffer` to JSON, transforms, and serializes as protobuf.
The `miscreant` library also does this: https://github.com/miscreant/miscreant. It's really effective. For example, any method that requires a one time pad takes ownership. This allows the borrow checker to validate that you don't accidentally use an OTP more than once.
Interestingly, I was able to get an amazing speed improvement without going completely to Rust.
I didn't want to port APM code as well, so I kept node.js/express for routing. Very simple middleware that immediately passed the request and body buffer to Rust for handling. Rust returned a buffer back to express for sending the response.
It's easily able to hit 100k RPM on a single instance before hitting a CPU bottleneck in the Rust code (validating an RSA signature). It only needs to handle 90k RPM total.
In my opinion, one of the most important and most difficult parts of the job. Architecture and design shouldn't be limited to senior engineers--it won't be in practice, anyway. Doing so is a sure fire way to stilt the growth of your team.
But, reviewing designs is hard. It requires recapturing much of the context that the engineer gathered in a very short period of time. I also find it sometimes difficult to separate, "this is a fatal design flaw" from "this isn't how I would do it." I really like the suggestion of providing feedback via additional information.
Mistakes are a very important part of learning. I try to make sure everyone has the opportunity to make their own instead of making mine.
I like the use of "unsafe" for something that you don't want to reach for first. Those who are new get a very clear warning and those who aren't have had the opportunity to understand the nuances.
React uses the term "danger" to express a similar concept. You are trusting this value to already have been sanitized / escaped.
Unfortunately, PCI does not put very many restrictions on the parent website. If credit card elements are in an iFrame, the parent site is excluded from most requirements because the iFrame is "secure."
Of course, if you own the parent site you can replace the iFrame with anything you want.
They may also be uncertain what another driver will do. For example, turning right onto a two lane road may be safe if the right lane is open. However, despite it not being legal, a driver in the left lane may change lanes mid intersection. I'd prefer not to risk it to save myself a few seconds.
About as confident as I can be without having insight into their perspective. I'm mostly referring to right turn on red scenarios where I'm not comfortable with the risk. Although, the occasional honking immediately after a light turns green also occasionally happens.
Every single time someone honks at me for this, I'm tempted to stay in place longer than necessary. Fortunately--most of the time--I think better of being this petty and passive aggressive.
What I found most interesting about this write-up is that most of the speed-up in the CSS parsing came from parallelism and that parallelism was attempted many times on the C++ without success.
> "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
* Progressively introduce Rust instead of replacing entire applications (Rust really shines in this area)
* Leverage node's strong HTTP and routing story while waiting for this to stabilize in Rust
* Leverage existing tooling for APM, config management, etc.
For example, one middleware verifies the request body with a signature from a header. Another one parses the body from a `Buffer` to JSON, transforms, and serializes as protobuf.