1 it has nothing to do with 'improvement'. You can improve it to be a little less susceptible to injection attacks but that's not the same as solving it. If only 0.1% of the time it wires all your money to a scammer, are you going to be satisfied with that level of "improvement"?

> You can improve it to be a little less susceptible to injection attacks

That’s exactly the point the rapid rate of improvement is far form slow polish in 10 years it will be everywhere doing everything

I think you missed the other half of the sentence. It's not converging on 'immune' no matter how fast it improves.

Neat! I didn't know about this either.

Php has a similar feature called __halt_compiler() which I've used for a similar purpose. Or sometimes just to put documentation at the end of a file without needing a comment block.

I would guess one of his accounts is his corporate employee account and his other is personal.

Meanwhile streaming everyone's data, negating any benefit.

I'm not the parent but if you know you want to merge a PR "within a few seconds" then you're likely to be merging in bad changes.

If you had left it at know you want to reject a PR within a few seconds, that'd be fine.

Although with safety critical systems I'd probably want each contributor to have some experience in the field too.

Sounds like you misunderstood. They didn't say they are merging PRs after a few seconds. Just that the difference between a good one and a bad is often obvious after a few seconds. Edit: typos

Exactly, every PR starts with:

1. What’s the goal of this PR and how does it further our project’s goals?

2. Is this vaguely the correct implementation?

Evaluating those two takes a few seconds. Beyond that, yes it takes a while to review and merge even a few line diff.

I'm not sure there are many ways to interpret "I know whether I want to merge a PR within a few seconds".

Yet I also agree with GP.

"*WANT* to close or *WANT* to merge". Not WILL close or WILL merge.

You look at the PR and you know just by looking at it for a few seconds if it looks off or not.

Looks off -> "Want to close"

Write a polite response and close the issue.

Doesn't look off -> "Want to merge"

If we want to merge it, then of course you look at it more closely. Or label it and move on with the triage.

Yes but your house has to burn down and you have to simultaneously lose your memory.

If your house and PC burn, restore from online backup.

If your brain burns, spouse restores from vault.

This assumes having a spouse.

Sure... if you don't have a spouse, leave it with a sibling. I put my Bitcoin key in my brother's safe. And if you don't have a sibling or parent or best friend, you can usually rent a locker at a bank.

s/spouse/executor/

Is Gerrit the same as Critique?

It's a descendant of critique's predecessor (Mondrian)

https://www.gerritcodereview.com/about.html

I'm quite happy to NOT have exceptions. I think they're a mistake as a language feature. What we need is first -class support for returning errors and propagating them, like what zig does. The next best thing are those RETURN macros that Google uses.

Isn't that equivalent to exceptions but more verbose and slower?

"first-class support for returning errors and propagating them" certainly sounds like exceptions! In fact, the compiler can even emit special tables that let the runtime completely skip over stack frames that don't need to do any cleanup during that propagation step!

Some languages have even innovated new kinds of exceptions that you can throw but that you are admonished should almost certainly never be caught.

Unfortunately even this is also better for tool support, a problem that using a bunch of macros solves. It's cool and good when a variable gets declared inside the guts of some macro expansion (and--critically--escapes those guts).

Its not the same. You have to explicitly declare the errors and if you want to ignore/propagate them, you have to do so explicitly as well.

You cant invoke a function and pretend it'll never fail.

Also, try/catch with long try blocks and a the error handling at the very end is just bad. Which of the statements in the try is throwing? Even multiple perhaps? Each should be handled individually and immediately

Deliberately more verbose. Not sure how it'd be slower. And only a tiny bit more verbose if the language has nice keywords/syntax for you to use. The point is you want to be explicit when you're choosing to ignore an error.

Having to support legacy code is a bummer. /s

Zig remains to be seen how market relevant it turns out to be.

Ya, we don't know yet. Still sitting on zig but I like what I see so far.

Why would you need to change your address at all? That's part of the card details. No other payment system does that!

Not the address, but the phone number has a bug I run into it occasionally. Some merchants support the +1 country code, some are local US only and don’t expect it. Safari’s auto-fill figures this out when filling the form. But then I go to Apple Pay, an it replaces the phone number with a 1 at the beginning and drops the last number, then I get an error that something is wrong. Initially took me a while to realize what was happening and that you can edit the number in the Apple Pay overlay before it applies it to the order. Just a bit annoying

It changes the shipping address, not the billing address.

And yeah, I do tap it to change what card to use. "Every single time."

Better than the one that ships with Jetbrains?

I did buy their $100/yr AI but its about to run out.

Definitely better. Next edit makes a difference. But it is not free, I think I pay $10/month.

Oh, i thought you were talking about this self hosted 1.5B model. You must be talking about the full model as a service?