I'm sure we'll start hearing "I AI-posted on HN for 4 years, got X karma, and no one suspected" type stories pretty soon. Eventually people could start asking for badges or flair that verify users as not being AI. It's simultaneously exciting and daunting standing at the dawn of this.
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 article isn't related to repo structure, however repo structure can relate to the core issue of how to share code and maintain domain boundaries - search for the "umbrella" thread elsewhere in these comments.
This is what I do in several of my backend Kotlin code bases and it's worked very well. I've also heard it called "distributed monorepo". There are a handful of ways to share code, and the tradeoffs of this approach are very manageable.
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.
At a more agile org, getting 2-3 stories done in one day isn't too extraordinary. A PR that follows some of the rules from the OP (especially 5/6/7) might only take 5-10 minutes to review completely.
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.
This is great! Many of these things are slowly learned over time, but explicitly listing them out will be helpful when refreshing or teaching others.
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).
Tufte would disagree, and at least some consider his thoughts on design to be very solid.
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 didn't downvote, but I'm assuming that suggesting an equivalence between concerns with GMO and being antimask/antivaxx comes off as hyperbolic.
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.
It sounds like your position makes use of those data structures and algorithms - and the author's didn't. I think the key here is that you memorize the important aspects of your role while knowing how to get the answers for anything else.
I believe that zeromsg does not support true zero-copy messaging which might be a reason to look at nanomsg or nng if you need every last ounce of performance.
The only times I've ever reached for zeromq are when I needed sockets and didn't want to deal with the hassle of programming sockets - it worked great then.
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.
As a follow-up, if you're wondering why, 500mb is roughly 5700m/18kft above ground level in the US - not quite jet stream level (200-300mb) - but high enough to give insight into large scale patterns that drive surface patterns.
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.
Not OP, but I routinely call a specific HTTP API for millions of entities or pull down entire Kafka topics - all in JSON format. For various reasons those are the canonical sources of data and/or the most performant, so I end up ripping through GBs and GBs of JSON when troubleshooting/reporting on things.
In the midwest it's "lead". I've also been on teams where nearly every developer is a lead, which sounds strange, but it's really just a confluence of "could this person lead a team" and pay band.
I've seen the following structure at several orgs:
engineer -> senior -> lead -> staff/principal -> distinguished
My emails/handles are almost always just first initial, last name but that's short enough (6 chars) these days to get weird things as well - most notable was a few months of communications from JSOC (https://en.wikipedia.org/wiki/Joint_Special_Operations_Comma...).
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.
The good news is this is already happening - lots of Java orgs in my market (not SV, but still a large US market) started working on new server-side things in Kotlin a year or two ago. This includes several Fortune 100 companies, so not just startups or smaller, more "nimble" companies.
Especially if you're using something like fzf that can easily search your command history, "every time someone has asked":