vkjv

We are using it to write Express (node.js) middleware via Neon (https://github.com/neon-bindings/neon). This has a few key benefits:

* 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.

It's a play on "The Twelve-Factor App" https://12factor.net.

https://3factor.app/#comparison-to-12factornet

This. I'll also add that in the world of things like Docker and [Insert]CI you don't need to mock most external dependencies like databases.

It's interesting that this went _beyond_ a prank. Almost the definition of "fake it until you make it."

"...review design docs"

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.

https://reactjs.org/docs/dom-elements.html#dangerouslysetinn...

¯\_(ツ)_/¯ I don't actually feel that strongly about a keyword that is used sparingly.

Aside: Thanks for everything you do for Rust and the community!

FWIW, I just checked and they don't use an iFrame approach. This means their entire checkout page must be in scope for SAQ-D.

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.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...

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.

A blog discussing the handling of this. https://news.ycombinator.com/item?id=17786791

I recommend using a threshold of at least 2 stars. It's fairly common to star your own repo to improve visibility.

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.

I've heard this called "bunny code." It doesn't matter if it's good or bad, it'll reproduce.

"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."

-Robert A. Heinlein

Despite earning marginally more than minimum wage, being a lifeguard is still the happiest I've ever been at a job.

You can wrap up the build and the copy with a multi-stage docker build. Something like the following.

    FROM rust:latest

    RUN rustup target install x86_64-unknown-linux-musl
    COPY . /src
    WORKDIR /src
    RUN cargo build --release --target=x86_64-unknown-linux-musl

    FROM scratch

    COPY --from=0 /src/target/x86_64-unknown-linux-musl/release/rust_docker_barebones /rust_docker_barebones
    ENTRYPOINT ["/rust_docker_barebones"]

Also, packaging up rust to be static like this can take some extra steps. For example, loading in root certificates.

I highly recommend using multi-stage builds to move the rust binary to a clean container. The rust build tool chain is fairly heavy and is unnecessary at runtime.

It can be as simple as adding something like this at the end of your Dockerfile.

    FROM debian:jessie-slim

    COPY --from=0 /src/target/release/my-bin /usr/bin/my-bin

    ENTRYPOINT ["my-bin"]

There are safe places to have a business located, and on the corner of a neighborhood street where bad drivers are cutting corners, texting, and going too fast is NOT one of those places.

As a parent, this is something that I care deeply about. If this is a consistent issue in your neighborhood, I strongly encourage you to contact your local police department. This type of driving in a residential area is significantly more dangerous to the community than a lemonade stand could ever possibly be.

I can think of a few benefits, even if it takes longer: you may need to do something similar again and now you have the script, you've gained experience and you might right the next script faster, correctness.

I think correctness is the most important one. Even if a manual task is quick, ensuring that you do it correctly and exactly the same way for all 30-50 things is extremely tedious. If one out of those 50 subdomains was behaving differently and you needed to investigate exactly why, that could quickly erode any time savings.

I agree, but I think this also supports the parent argument. CS and EE are not very different at the undergraduate level.

What were the reasons you decided to go with a child_process model instead of wrapping you Rust in a Node native module?

I've never used teams, but speaking as a user of questions, half the price and third the usability.

+1 for Neon! The best part about Rust is that it changes this question to "what language AND Rust?" Node + Rust is a great experience.

Race conditions, deadlock, data corruption can cause bugs that are complex to debug.

Rust can address all these problems, and more.

Rust does not prevent deadlocks.

I love electron and I've never built one and don't have any immediate plans to do so. I'm a Linux user and because of how easy electron has made cross platform, I am enjoying far more applications that support Linux because barrier is so incredibly low.

Are they resource hungry? Yes. Are they as smooth as a well polished native app? No. But, for many of these apps, the alternative is having nothing at all.

"Requiring a Mac." This most often bites me for testing Apple Pay. This assumes that writing an iOS is my primary responsibility. For some folks, that's not the case. This isn't a huge deal because I can just use a test device, but it is annoying.