Well, to go off-topic with you, the idea that Go "ignores decades of language theory" is just an opinion that you hold. A factual statement would be to say that the Go designers omitted a great many features other languages have included.
The idea that they did so out of ignorance is ridiculous, given the background of the Go design team. They made considered decisions about what to include in Go.
A fixed-gear bicycle is not "ignoring" decades of bicycle design theory.
Creating a programming language is an engineering task not a theoretical task. Which means there are major trade-offs to be made. And they chose their trade-offs. The wild success of Go should at least make you consider whether or not they're better at making these trade-offs than you, and most language designers, are.
Maybe they were wrong about some choices, which is why Go is still evolving, but they were self-evidently mostly correct.
This is an unnecessary ad hominem attack. He wrote this over a decade ago, in the midst of doing his best work creating Go itself.
gob was his opinionated way of doing a Go-specific encoding, while also supporting any number of other encodings in the language. Go has incredibly good support for almost every popular encoding there is.
gob has also been used successfully by a number of projects. In many cases, it's a perfectly good way to encode a piece of data that is completely local to a Go program.
What exactly do you think requires cycling millions of hosts to take 45 days? That's a couple hundred hosts every five minutes across a large number of datacenters?
I wouldn't expect it to be halved by optimization. I'd expect it to be an order of magnitude faster and take more like 4.5 days.
I wouldn't be surprised (but I would be impressed) if they tried and got it down to a full cycle requiring one working day. That's around 1% of hosts cycling every five minutes.
I'd stop right there and fix that, because that's a bullshit reason. Cycling hosts in and out of service is easy unless you're not doing things properly.
The Linux kernel is simply not designed to be live patched and it's a total hack to try to do it, it will never work 100% of the time, always be a source of uncertainty, and always be expensive in terms of engineering work. Disaster will always be looming.
By contrast, fixing their system for taking hosts in and out of service, so that it's extremely robust and reliable would likely pay big dividends in reliability.
My guess would be that this approach is papering over organizational dysfunction. One team can patch all the kernels but one team can't make all the hosts support proper cycling in and out of service. And no one cares to fix it because there's no real incentive to do so. Only cool hacks and new projects are properly rewarded.
Not sure where you're getting that from. NVIDIA has supported professional desktop Linux usage since before anyone was doing AI on their GPUs. All of their GPUs worked well.
I've been running NVIDIA GPUs on Linux workstations in personal and professional settings for almost 20 years. It's been always been an extremely functional and high performance experience.
It's annoying that the drivers are proprietary, and have to be rebuilt during kernel upgrades, but they have worked very well for a long time.
As a user, Ramp's web interface is absolute trash. I've submitted reimbursement requests only to get an error message and then have them go through later, creating duplicates.
CC transactions queue up, requiring a response and there's no way to go through them efficiently. The UI pops up a weird modal and is horrible to use.
It feels like a legacy enterprise application and it's basically a new product. I wish my company didn't use it.