Comment by leo_e

Comment by leo_e 6 days 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.

bearjaws 6 days ago

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.

Reply View 1 reply

cyanydeez 6 days ago

Tesla, Grok, etc.
You would be just as stupid when people are in the private-public market. Dont lie.

Reply View | 0 replies

teleforce 6 days ago

> 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)

Reply View 2 replies

Spivak 5 days ago

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.

Reply View | 0 replies
busssard 4 days ago

i thought everything is being rewritten in rust nowadays?

Reply View | 0 replies

harrall 6 days ago

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.

Reply View 1 reply

exomonk 6 days ago

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.

Reply View | 0 replies

nick238 6 days ago

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.

Reply View 1 reply

sillyfluke 5 days ago

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.

Reply View | 0 replies

conradev 6 days ago

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.

Reply View 0 replies

liampulles 5 days ago

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.

Reply View 0 replies

arealaccount 6 days ago

I mean entirely different use cases, right?

Borking a space mission vs someone’s breakfast status update can be optimized differently

Reply View 0 replies