pebers

IANAL either but I agree, that is a statement of copyright which is not unusual, but there is no licence and therefore we have no right to copy & use it.

When I mentioned speed, I obviously wasn't ruling out C++ on that basis - but I would rule out Python or Node. Java is fast enough when going but the awkwardness of needing a JVM plus abysmal runtime memory usage make it pretty unattractive to me, especially for the k8s agents where the resource needs have to be subtracted from total node size.

I've not found Go difficult to navigate because of repetition. Quite the reverse really - it's easy to reason about where everything comes from and (usually) easy to work out how everything connects together. I would take that any day over a large Java codebase with the usual obfuscations of dependency injection, or a Python or C++ codebase where somebody has tried to be "clever".

That's kind of my point; the code might not be as beautiful as we could ever imagine, but as a product it works extremely well, and would be worse if it carried around a lot of runtime baggage and poor performance which many of the alternatives would have given.

It isn't necessarily a bad idea to start with a minimal design and add features later once the implementation is more mature. Even if Go never gets generics, it's still a good solution for a number of problem domains (for example, it seems to have found something of a niche for infrastructure; Kubernetes, Prometheus, juju, etc.)

Specific lanes for citizens of the country have existed for a very long time, but the article calls the issue out as having mostly arisen in the last three years. Seems unlikely that a thing that had already been there for decades has caused the (apparently) sudden decline.

Yes, we have adopted Go for a lot of things at work and I have reviewed code of many of our devs who are more or less Go novices. It has indeed been pretty easy to understand - much easier than other languages (notably Java in this regard, but Python falls afoul of it a bit too) where people tend to write things in quite different styles and/or with excessive abstraction that made it much harder to understand what was going on.

On the bright side, your code will always be as easy to understand as a novice's code too, so it conserves other programmer's mental cycles as well.

The ATM network here is also not owned by the banks (similarly FASTER payments, they are members of the scheme but there's a third-party that administers the network). They pay for access, but don't pass that cost on.

And I did not miss that point, thank you. I just disagree with it. I don't think banks make their primary income from fees; current accounts are still basically a loss leader.

> Today banks uses fee for everything and everyone is ok with that

They actually don't. Most ATM fees and inter-bank payments (at least in the UK / Europe) are swallowed by the banks rather than exposed to customers.

> So yes, it is very possible to make a profit by not only having those things but having that without fees.

How? As far as I can tell you're describing a bank that runs deposit accounts but doesn't loan the money back - that is not obviously a profitable enterprise. Something in the whole scheme has to make some money to pay for the employees, the infrastructure, and all the other fixed costs.

Definitely some ambitious goals. There's nothing bad about that, but this has an awfully long way to go - e.g. searching for "hacker news" works fine, searching for almost anything else didn't find anything relevant. So while it's nice to say it can run in 1CPU / 1GB, I'm not sure it's very useful at that size (but I don't know how big it'd have to get to "break even" there).

Anyway, noted that it's a very early version, so good luck with it!

Not from those EU regulations - PSD2 is more recent than most of those challengers. They've popped up because the FCA (the UK regulator) deliberately tried to make it easier to start banks in order to get more competition in the space.

You need to do more than just #include it - it is implemented in one .c file but that is not a header, so you'd still need to compile that separately and link it in somehow.

It's not the reason the author gives, but one advantage is that you don't need LTO for some optimisations. Sqlite has a single-file distribution for that reason. On the downside, it is quite slow to compile and not readily parallelisable - but that probably is less of a concern here.

Yes, we do. I assume the cost of changing them all (and the resulting confusion and potential danger) was deemed too high.