lllr_finger

"When was the last time you could tell someone the difference between version 1.2.1 and 1.2.3 quickly?"

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

    git log <tag 1>..<tag 2> --pretty=oneline

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.

It's really cool that you experimented with 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.

> they each have a profile

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.

Look up "nanomsg is not dead" and nanomsg's replacement nng for even further confusion.

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