in_a_society

The best way I can explain it is that it's the same feeling when I upgraded from 56k dialup to cable broadband.

I don't see why it should be all that difficult. All you have to do is first find a library that implements a decent solution to the halting problem and you're off to the races.

Baking weights in makes a lot of sense for inference speed and power efficiency and has the added benefit of putting many end-users on the hardware refresh treadmill.

I'll echo this. They're very good at consistent support and never pulling the rug. The folks at Railway have nothing but the wildest praises to sing.

Google has a culture problem. This is not something that can change easily nor will it change when it’s not recognized as being an issue within their organization.

Between my peer c-suites, the conversation is that GCP cannot even be in the consideration set until such a time as a several-year period has elapsed without this kind of incident.

This comment reminds me of a joke where the punchline is that a person is so poor that burglars break in to their house and leave money.

Similarly, I could see ransomware groups hacking in and feeling bad for GH so they improve a few things to help them get to at leave nine fives of uptime.

Smells like an article from someone that didn’t really USE the XML ecosystem.

First, there is modeling ambiguity, too many ways to represent the same data structure. Which means you can’t parse into native structs but instead into a heavy DOM object and it sucks to interact with it.

Then, schemas sound great, until you run into DTD, XSD, and RelaxNG. Relax only exists because XSD is pretty much incomprehensible.

Then let’s talk about entity escaping and CDATA. And how you break entire parsers because CDATA is a separate incantation on the DOM.

And in practice, XML is always over engineered. It’s the AbstractFactoryProxyBuilder of data formats. SOAP and WSDL are great examples of this, vs looking at a JSON response and simply understanding what it is.

I worked with XML and all the tooling around it for a long time. Zero interest in going back. It’s not the angle brackets or the serialization efficiency. It’s all of the above brain damage.

Only to get in response: “INSUFFICIENT DATA FOR MEANINGFUL ANSWER”

GDPR for thee, but not for me.

This is a standard playbook at large organizations with finance departments. CFO 2 companies ago used to literally coach people on extending payments and delaying. Best case scenario for them, you never get aggressive enough to actually collect. Repeat that at scale across many vendors and suddenly their entire P&L looks substantially better.

I wonder if the cable could be enclosed in some sort of container whose shape would make an anchor glance off its surface.

Expecting AGI from Reddit training data is peak "pray Mr Babbage".

Quite disagree. Early mistakes cost me a lot of heartache later on. But you don't have to figure anything out by yourself. People like us get hired because we're experts in software development; we can absorb requirements, understand the business, and apply technology to get an optimal outcome. There are professionals in the accounting and legal fields who specialize in things we don't have experience in and they are worth it.

Just curious, what industry do you work in?

I'm not sure your conclusion is a fair take. In the app I work on, GIL acquisition would easily take 2-3x longer than the postgres queries which would subsequently be issued.