I'd argue that it is completely useless. They have the actual parser that runs in production and then a separate "test parser" that doesn't actually reflect reality? Why?
Maybe they have the same parser in the validator and the real driver, but the vagaries of the C language mean that when undefined behavior is encountered, it may crash or it may work just by chance.
I understand what you're saying. But ~8.5 million machines in 78 minutes isn't a fluke caused by undefined behavior. All signs so far indicate that they would have caught this if they'd had even a modest test fleet. Setting aside the ways they could have prevented it before it reaching that point.
That's besides the point. Of course they need a test fleet. But in the absence of that, there's a very real chance that the existing bug triggered on customer machines but not their validator. This thread is speculating on the reason why their existing validation didn't catch this issue.
I read that they pushed a new configuration file, so possibly they don't consider that a "software update" and pushed it to everyone. Which is obviously insane. If I am publishing software, it doesn't matter if I've changed a .py file or a .yaml file. A change is a change and it's going to be tagged with a new version.
So how do people handle this in practice if the users table in this example has a ton of traffic? It might not ever succeed even with exponential backoff. It also seems strange that Postgres would need to lock the entire table just to add a new column.
I'm in a really similar position to you. I'm currently engineer #1 at a seed stage startup making $155k with 1.5% equity. But a year in I'm realizing I've built their entire product from scratch while they do sales and outreach. Obviously those things are important but I'm a leg of a tripod holding the whole thing up and yet I have a fraction of the equity they have. Makes no sense.
Oracle Park is kind of uniquely great, though. Amazing views and right next to public transportation. The more typical experience is something like Kauffman Stadium, where the only way to get there is by car and there is nothing to look at other than the game itself.
I use the same technique to maintain a json file mapping Slack channel names to channel IDs, as Slack for some reason doesn't have an API endpoint for getting a channel ID from its name.
It has some of the same problems. It doesn't have the problem of being unable to read obj[key] because typescript doesn't realize it's the same object.
And according to the article, the issue isn't that TS doesn't realize it's the same object, it's that the object might have more keys than what is declared in your interface.
Perhaps what you meant to say is that you can directly use `val` instead of `obj[key]`.
> And according to the article, the issue isn't that TS doesn't realize it's the same object, it's that the object might have more keys than what is declared in your interface.
The main issue at hand was inability to use `options[key]`.
"the object might have more keys" was a possible issue, and was the reason typescript was blocking access to `options[key]`, but it wasn't the main problem.
> It has that same problem actually:
> Perhaps what you meant to say is that you can directly use `val` instead of `obj[key]`.
How is that different from what I said?
Because you can directly use `val`, and because that's better than `obj[key]` anyway, you "don't have the problem of being unable to read obj[key]".
Did they just now discover abstract base classes?