Especially if you're using something like fzf that can easily search your command history, "every time someone has asked":

    git log .. --pretty=oneline

My experience is that choosing Rust just for performance gains usually doesn't pay off. In your case, node already uses C/C++ under the hood, so some of what you're replacing could just be switching that for Rust.

The primary reason I reach for it is when I want the stability provided by the type system and runtime, and to prevent a litany of problems that impact other languages. If those problems aren't something I'm looking to solve, I'll usually reach for a different language.

The biggest downside I've encountered is that you need to figure out the deployment abstraction and then figure out how that impacts CI/CD. You'll probably do some form of templating YAML, and things like canaries and hotfixes can be a bit trickier than normal.

Absolutely true that languages are built to fulfill specific roles and have associated trade-offs. I think you answered your own question - JavaScript's strengths are being very widespread in current software development and having a minimal syntax/type system. IMO it can be a good language for MVPs/POCs and serve as a higher form of pseudocode. Perhaps the author's choice of JS as a way of reaching the widest possible audience and focusing on the concepts more than the implementation details.

A relatively recent personal example: in working through some DSL and parser combinator examples in Rust, sometimes I get too distracted with lifetimes, annotations to deal with deeply recursive functions, etc. and just search for examples in a different language that allow me to focus on the concepts I'm trying to learn.

If you can't slow down enough to do that, or your stories are so large they require more attention, that might be a red flag situation? Writing code faster than you can review it will eventually catch up to the team/org.

The three that have been most helpful on our team are: #1 (review your own code first), #2 (write a changelist description), and #5/#6 (narrowly scope changes/separate functional/non-functional changes).

Would you be amenable to "A well-designed web page does not need to rely on custom fonts, provided their impact on page load is absolutely minimal"?

You can unobtrusively serve up a single font embedded as base64 on a static site - a world of difference from some of these sites that load up 5MB of a UX person's vision off some remote CDN.

I sometimes have a difficult time separating legit benefits of GMO with shilling or astroturfing, which is unfortunate when trying to have a reasoned discussion.

My takeaway is that even though these newer libs seem to be simpler and avoid some issues, they've just never caught on.

I'd happily use it as the glue between two processes that I control, but would grab one of the other tech you mentioned for anything exposed on the boundaries of my app.

Where surface features are more localized and near-term, 500mb analysis gives you insight into whether there is broad zonal flow, a deepening upper trough, and all sorts of important information about how things on a larger scale can play out in the longer term. They're sometimes called "steering winds", because they're the primary component that dictates direction and speed of storms.

I've seen the following structure at several orgs:

engineer -> senior -> lead -> staff/principal -> distinguished

Thankfully nothing seemed super secretive, but I got a lot of PowerPoint presentations and other things that I definitely should not have been seeing.

Not to mention the countless password reset requests, 1₽ added to accounts from kiosks, etc.