Comment by leo_e
1 day ago
It really puts our current definition of "latency" into a painful perspective.
We have a machine running on 1970s hardware, a light-day away, that arguably maintains a more reliable command-response loop relative to its constraints than many modern microservices sitting in the same availability zone.
It’s a testament to engineering when "performance" meant physics and strict resource budgeting, not just throwing more vCPUs at an unoptimized Python loop. If Voyager had been built with today's "move fast and break things" mindset, it would have bricked itself at the heliopause pending a firmware update that required a stronger handshake.
I am certain if I had the estimated $4,000,000,000 it took to get Voyager 1 launched, I could get some microservices to function regardless of all scenarios.
The reality is, its only worth it to build to 99.9999% uptime for very specific missions... There is no take-backsies in space. Your company will survive a microservice outage.
Tesla, Grok, etc.
You would be just as stupid when people are in the private-public market. Dont lie.
> not just throwing more vCPUs at an unoptimized Python loop.
I've got the strong feeling that most of the Python frameworks, stacks and codes in operation of our generation will be the technical debts of the future computer world.
The fact that Python was meant primarily as both learning language (ABC legacy) and glue language (akin of scripting but not for building) make the Python based systems and solutions the duct tapes of the 21st century computing [2].
[1] ABC (programming language):
https://en.wikipedia.org/wiki/ABC_(programming_language)
Do you feel the same about Python's contemporaries—Ruby, JS, Perl, PHP?
More generally it seems a condemnation of any language that runs in either an interpreter or a VM which might even include Erlang and Java as well.
You're breezing past the labor cost quite deftly. I'm reasonably sure that developing the Voyager probes required a few more people and hours than your average microservice.
Not that it would change your point, but as a separate matter I'm curious what the ratio of government employees to private contractors was back then when they were building the thing compared to now.
It’s a testament to product planning. It has nothing to do with engineering.
If it’s Photoshop and formally verified and can’t crash but it has only 5 tools, I would be pissed.
If it’s a remote monitoring station with a cool GUI but crashes daily I would be pissed.
Know the product that you are building.
That sounds like a product manager's perspective, but I think the falls apart in deep space. When the feedback loop is 2 light-days long and hardware is irreplaceable. The original planned lifespan of Voyager was just 5 years.
The domains are totally different and lead to different tradeoffs. An internal marketing data platform can justifiably be optimised for iteration speed and quick scalability over availability.
Spacecraft require more 9s of reliability than microservices. Their engineering processes are very different, even today. We still build new spacecraft today, even though we don’t launch them into interstellar space.
I mean entirely different use cases, right?
Borking a space mission vs someone’s breakfast status update can be optimized differently