Address verification only ever checks the numbers in the address, nothing else. You can pretty much skip all the words that don't spell numbers and it should be the same iirc.

I've not seen this in my experience tbh, the extra code that Go requires is ugly but not complex, the lack of ergonomics actively discourages "clever" solutions and, as a result of this, people tend to write the kind of straightforward code that doesn't end up needing lengthy programming or intense debugging.

At my workplace we've used many languages over the years (C#, Python, Go) and Go teams are the ones that by far do the least amount of yak shaving and have the most intelligible codebases.

I’ve always felt like the lack of many complex language features nudges teams to also keep their code simple.

There is always two aspects to a language works in practice: how it formally works, and how the community uses it.

Go is (was?) simple, and also (encouraged by the language and influence from its developers) the community mostly aims to keep the usage simple.

It’s the lack of parametric enums (sum types) which really gets me. I use sum types constantly. Nearly as often as I use structs.

For example, in typescript you can define a json value as something like:

    type JSON = null | bool | string | number | [JSON] | {[k:string]: JSON}

Go forces me to reach for interface {}, and use a nest of dynamic dispatch code. It’s horrible. Go code is harder to write, harder to read and it runs slower as a result.

The decision is baffling. Especially given go now has generics, which are waaay more complex than enums. And sum types in go could be used to fix the constant (result | error) boilerplate. And remove nullability. Sigh.

100% also our experience. We have an internal CLI which has grown to almost half a million lines of Go, mostly contributed to by first-time gophers (and agents nowadays), and with relatively little work spent on making sure the core entities and interfaces encourage doing the right thing, the entire codebase is still surprisingly readable and free of unexpected behaviors.

It's hard and annoying to read though. Constantly beating around the bush, circling the point but not stating it, not unlike LLM prose.

Yep. But with go 1.22/1.23 and later this is changing. It's becoming a hell of a mess like many other big languages. I think it was two consecutive releases back in 2024 where they added for ... range and generics? That was when I gave up.

Sad that the one language that managed to occupy that nice spot in language design space for an extended period of time, isn't doing so anymore.

Of course, you can actively restrict yourself to standard go, but not needing to do that was the whole point.

The support for iterators is relatively new, though being limited to data structures that an iterator makes sense on, they don't exactly get around in the language and pollute everything everywhere.

The support for generics is years old and I don't believe anyone who claims it has ruined the language. I've barely encountered them in the wild and I've never encountered the thing people were really worried about in the wild where something has 4 generic parameters that are themselves complicated generic parameters of other things. If you're encountering that, it is either some one-off library I've never encountered, or it's because you or your team are writing it, to which the solution is, stop that.

I'm not even sure I've yet seen a "generic" in a library in Go that isn't simply straight up a generic data structure, the core use case for generics. I've written a couple of such things but they're all internal code.

IMHO it's more: fix problems, or at least mitigate them, regardless whose problem it is.

I've been in this situation, a clientside bug meant that different requests arrived with the same idempotency key.

In my case, updating the client would have taken weeks, in the best case scenario. Updating the backend to check for a matching request body would have taken minutes, maybe hours.

It took me a surprising amount of arguing to convince people that, even if it was a clientside bug, we couldn't let users suffer for weeks in name of "correctness".

Yeah but don't let them reify it.

Ideally you already send client version in requests (or have an API version prefix). Add the workaround only for legacy clients.

Next client version must distinguish itself from predecessor and must not require the bodge to work.

Well.. it was ~6 years and ~10 billion payments ago, the clients have been fixed but the "hack" is still there, it has caused no harm as far as I can tell. Worst case scenario it's useless, best case scenario it prevents regressions.

The issue with things that client must not do is that they might still do them, and users don't care whose fault it is. It's important to have auxilliary mechanisms to mitigate these.

That it may be there or not doesn't mean it "caused no harm". It sounds like yet another carbuncle added in haste and then never fixed properly, leading to 6 years of fear of touching it.

If it's truly intended, it needs to be part of the official spec, with a robust justification of why it's there at all. Neither server nor client ought to have unnecessary and undocumented things "just in case", because that breeds a culture of uncertainty.

If you fear client regressions, make it a mandatory part of the client's test suite. You control the client, right?

> In my case, updating the client would have taken weeks, in the best case scenario. Updating the backend to check for a matching request body would have taken minutes, maybe hours.

Then at least admit you’re just hacking quickly fixes, creating technical debt, and not fixing the actual problem.

I agree with your point that business interest is most important, I disagree that it’s the technically most appropriate solution.

The whole article is proclaiming that this is a technical problem about idempotency being hard, while it’s not. The whole premise of client side bugs must be resolved backend side as the correct solution is incorrect.

Eh, idk, I wouldn't classify these fixes as hacks nor as technical debt. It's labels that only work from a partial perspective. IMHO a solution that expects perfect compliance is not really complete, it's not good enough to put all the burden on the client, idempotency keys are part of the solution, but not the solution. So, in this sense I would say it is a technical problem.

It kinda works both ways, just yesterday I tried to play the Linux native version of 8bit.runner and it didn't work, I had to install the Windows (beta) version and run it through proton.

Funny story: I use Anki (the flashcard program), and I run it on my NixOS laptop. There is a NixOS/nixpkgs package for Anki. It doesn't work. You know how I run Anki, which has a native GNU/Linux version and even an actual nixpkgs package, on my GNU/Linux NixOS laptop? Yeah, I run AnkiDroid, the Android version, through Waydroid. Because the Android version works.

Anki seems to be a habitual offender, I was never able to install it reproducibly and in an obvious way on several distros and always ended up building it from source.

Don't you find it excessive to imply the above regarding a G7 country?

When I upgraded my PC to the same CPU, I had the same problem of crackling/buzzing speakers on my USB DAC (externally powered, but from the same strip/outlet) when the system was under load.

I had a hunch it was power related because my PSU was nearly 10 years old and probably with just barely enough wattage. I bought a new one and all the buzzing went away.

IIRC when I was researching possible causes, beefy Ryzen CPUs were the most commonly mentioned in various forums and reddit threads.

This is also my experience, it's not necessarily Apple fans, people just get used to some garbage but necessary workflow/ritual and forget they are doing it. I witnessed multiple colleagues and friends, who are avid and experienced MacOS users, struggle with basic tasks like ..finding the window of an open application after it was minimised, fullscreening applications, screensharing. Yet, somehow, none of that registered for them and their experience was still reported as flawless.

It's being posted as a gotcha because he fought against firearm control and he was killed with a firearm. His death, like many firearm-related others, would have been significantly less likely to occur if firearm possession was properly regulated and curbed, like it is in many other countries.

I understand your point. But even if he said otherwise would still be posting this?

Point is it just seems like a giant gotcha and it’s not fair

>I understand your point. But even if he said otherwise would still be posting this?

>Point is it just seems like a giant gotcha and it’s not fair

Who says life is fair? Was life fair for those school kids in Minnesota? The kids murdered in Uvalde? And on and on and on. Where's the fairness for them?

And why is it more important for Kirk to be treated fairly than those children? That's not a rhetorical question.

I'm not condoning murder. Full stop.

Whoever killed Kirk -- for whatever reason(s) -- should be prosecuted to the full extent of the law by the state of Utah.

To be clear, I didn't know Kirk or anyone in his family. I don't celebrate his death either.

But while it's sad, and even tragic, why is his death more important or relevant than the thousands of other deaths by gun in the US just this year?

All that said, there is a certain irony here -- as he explicitly allowed for exactly this outcome as acceptable in support of the Second Amendment.

And if, as he explicitly said, a certain number of deaths are acceptable (I don't agree, BTW) in support of a broad interpretation of the Second Amendment, why isn't his death also an unfortunate, but necessary offshoot of that?

One could argue that advocating against firearm control and regulation has resulted in significantly increased societal harm, which could also be identified as not fair, if not even evil/hateful, especially from those who have directly suffered from it.

Of course two wrongs don't make one right, and people can be more classy than this, but it's a totally understandable sentiment and response.

He was a commentator and a right to articulate his views. He didn’t deserve to be murdered

None of my claims disagree with what you just said. People posting the "gotcha" also likely don't disagree with you.

In fact, I suspect that most hate firearm-related violence and have worked to stop/curb it, and were opposed by Kirk who undeniably unfairly got a taste of his own medicine.

IMHO the incentives are disproportionately in favour of everyone doing something that hurts consumers (= "something that I don't like"), thus regulation in favour of consumer rights is appropriate.

There isn't a scenario where, at scale, someone can offer a product that respects consumer rights and is successful, because it's too profitable to not respect consumer rights just like it wasn't in many other cases.

I would be very surprised if bit flipping and ML were really used here, do you have any source?

While for sure there's a lot of signal and value in monitoring auth rates per BIN per payload, flipping bits can be extremely disruptive and counterproductive. From doing the wrong operation to being fined by the schemes, it's a lot of risk for not a lot of gain when these fields can be tuned ad-hoc for the few card issuers that deviate from the standard/norm.