There isn't many, as stupid as it may sound, I keep burning CD/DVD/BluRay and piling up external drives.
Yes, it is a pain versus having a NAS, but at least I don't have to deal with this kind of stuff.
I’m a fan of optical storage and its durability (with reasonable care.)
But the problem is when you need to recover and have 20 Blu-ray Discs with important data scattered about, it takes days.
Or when there is a specific piece of data you want/need and only have a vague idea of where it is/was in history. Maybe if those ultra capacity discs took hold but it looks like the era of optical is ending
Async Python is practically a new language. I think for most devs, it's a larger than than 2 to 3 was. One of the things that made python uptake easy was the vast number of libraries and bindings to C libraries. With async you need new versions of that stuff, you can definitely use synchronous libraries but then you get to debug why your stuff blocks.
Async Python is a different debugging experience for most python engineers. I support a small handful of async python services and think it would be an accellerator for our team to rewrite them on Go.
When you hire python engineers, most don't know async that well, if at all.
If you have a mix of synchronous and asynchronous code in your org, you can't easily intermix it. Well you can, but it won't behave as you usually desire it to, it's probably more desirable to treat them as different code bases.
Not to be too controversial, but depending upon your vintage and they was you've learned to write software I think you can come to python and think async is divine manna. I think there are many more devs that come to python from datascience or scripting or maybe as a first language and I think they have a harder time accepting the value and need of async. Like I said above, it's almost an entirely different language.