colatkinson

1. Built to last only 50 years to save on materials (as the other commenter noted).

2. Built over literally the widest possible part of the Hudson because the governor got in a pissing contest with the Port Authority and wanted all the tolls to go to the state, which wouldn't have been the case had it been built like 2 miles south where the river is narrower.

3. Designed with zero redundancy, such that a "critical fracture could make the bridge fail completely because its supports couldn’t transfer the structure’s load to other supports." [0]

So yeah if we're being real, 50 years was quite optimistic.

The new Tappan Zee is apparently supposed to last 100 years, though given the incidents with substandard materials being used, as well as ever-increasing traffic, who knows.

That said, driving over a bridge 10 years past its planned EOL and being able to look down directly to the water through gaps in the concrete was always a nice feature though -- who needs coffee when you've got that to get your heart rate up!

1. Because global objects are refcounted, CoW effectively isn't a thing on Linux. They did add a way to avoid this [0], but you have to manually call it once your main imports are done.

2. On Mac, turns out a lot of the system libs aren't actually fork-safe [1]. Since these get imported inadvertently all the time, Python on Mac actually uses `spawn` [2] -- so it's roughly as slow as on Windows.

I haven't worked in Python in a couple years, but handling concurrency while supporting the major OSes was a goddamn mess and a half.

And if you're on a 64-bit system, you'll want to make sure it finds the 32-bit libc and libm binaries (see [1]). On Arch, the following worked for me:

    ./build/movcc -L/usr/lib32 test.c

I think it's a fair assumption to say that the author is aware of what Arcs are and how they work. I believe their point is more so that because of how async works in Rust, users have to reach for Arc over normal RAII far more often than in sync code. So at a certain point, if you have a program where 90% of objects are refcounted, you might as well use a tracing GC and not have the overhead of many small heap allocations/frees plus atomic ops.

Perhaps there are in fact ways around Arc-ing things for the author's use cases. But in my (limited) experience with Rust async I've definitely run into things like this, and plenty of example code out there seems to do the same thing [1].

For what it's worth, I've definitely wondered whether a real tracing GC (e.g. [2]) could meaningfully speed up many common async applications like HTTP servers. I'd assume that other async use cases like embedded state machines would likely have pretty different performance characteristics, though.

The plant definitely had issues -- some due to age (construction started in 1956!), some due to mismanagement, and some due to dumb regulations [0]. My chem class went there on a field trip in high school, and the guy giving the tour definitely gave off "engineer who has been overruled by management in very dumb ways" vibes while explaining that their waste silos were almost full because they weren't allowed to transport the spent rods across state lines so that they could be recycled back into fissile materials.

As an aside, the control rooms had a real "retro-futurism" look. Lots of manual dials and brightly-colored plastics [1]. Gene Roddenberry eat your heart out, etc.