HN user
"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=onelineI'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.
For those wondering how a spark plug would work: https://en.wikipedia.org/wiki/Ninja_rocks
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.
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.
we live in the reality of disparate functionality paired with an ever-changing technical landscape
It is the responsibility of tech leaders to minimize this (accurate) stereotype. Choose boring technology, and only build your own or choose something exotic when it gives you competitive advantage - because the reality I also see is that 99% of devs aren't working on anything new or unseen in the field. Even at the FAMANG companies, most people I know are working on boring problems.
So when your CTO or architect or whomever buys into the hype for X technology, make a good argument against it by proposing a better solution.
I've found the same. One of my favorite blog posts on getting FreeBSD working well on laptop is: https://www.c0ffee.net/blog/freebsd-on-a-laptop/
It's historically been a very similar proposition to Solaris: zfs, dtrace, containers, and higher performance.
For as much as I like both FreeBSD and Solaris, Brendan Gregg (mentioned elsewhere in the comments) has a very convincing argument as to why the scales have tipped in favor of Linux in the last few years:
http://www.brendangregg.com/blog/2017-09-05/solaris-to-linux...
If they read the article - probably nothing. At a really basic level, running a caloric deficit is a still a viable method of losing weight.
The article goes on to talk about how at a societal level we tend to fixate on calories only, and then outlines several problems with that. Namely that all calories are not created equal, because health is more than just body weight.
(number of uninfected that need to be infected to achieve herd immunity) * (case fatality rate) = future deaths
With the assumption that every vaccinated person counts towards herd immunity and isn't likely to die, you can plug in your own numbers to the equation above. Even with really conservative estimates, it's easy* to get into the millions when you consider the entire planet.
*Barring some highly effective treatments that may or may not surface.
We just renamed our use of whitelist and blacklist for two reasons, outside of any racial contexts.
The easy one is that we don't want to argue about it, much likes tabs vs spaces - the value for us is in having a standard, not necessarily what the standard is.
The other one is that I spend a ton of time convincing developers to be intentional and deliberate in their naming of variables and functions, and these terms just aren't very intentional. I've had to explain them to several ESL developers because it isn't intuitive.
The article simply misses the mark by trying to create sensation where there is none to be found.
As someone who is a tech lead for a large database install, I'd urge you to read the rest of the Jepsen reports. They aren't intended to be hit pieces on technology - they're deep dives into the claims and guarantees of each database. IIRC MDB has explicitly reached out to OP in the past (I doubt they'll continue to do so after this).
Why that matters to the rest of us: once I learn all those dials and knobs I'm left wondering why I would choose Mongo over another technology, and how much the design of the default behavior and complexity of said dials/knobs are influenced by their core business.
Mongo has been related to "perpetual irritation" up to "major production issue" at all three of my last companies.
For as easy as it is to use jsonb in Postgres, or Redis, or RocksDB/SQLite, or whatever else depending on your use case - I can't find any reason to advocate its use these days. In my anecdotal experience, the success stories never happen, and nearly developer I know has an unpleasant experience they can share.
Big thanks to aphyr and the Jepsen suite (and unrelated blog posts like Hexing the Interview) for inspiring me to do thorough engineering.
Kafka is one of those things where if you're new to it, especially if you're coming from Rabbit or similar, you might tend to assume the happy path - exactly once delivery. This is a bad mistake (whether that's possible and to what definition is not a debate I'd like to dive into now). What you should expect from Kafka is at least once delivery.
There will be times when you lose offsets or when you actually want to replay every message, so take an hour and figure out what that means to your app. It's usually only a few lines of code in your consumer that compares source timestamps, but it's by far the most beneficial thing you can do when working with Kafka in my experience.
It's also relatively easy to hit "tens of thousands" messages/second, especially in replay or bootstrapping scenarios, and that's when Kafka becomes useful to the non-FAANG companies.
I'm posting this as someone who runs and enjoys both FreeBSD/OpenBSD: there are good reasons for running *BSD these days, but the ones you listed have lost a lot of their value.
Regarding the Illumos/FreeBSD "trifecta" of zones/jails, ZFS, and DTrace - I prefer LXC, I treat laptops/workstations like cattle and only run FreeBSD+ZFS where its needed, and I don't need DTrace.
Brendan Gregg can elaborate on these topics much better than I can, and his words probably carry more weight, given his involvement with Illumos: http://www.brendangregg.com/blog/2017-09-05/solaris-to-linux...