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.
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.
I agree, my vastly preferred option now is Python code and C code with cffi to glue them together. I find that much preferable to Cython which is basically a third language altogether (and IMO not an especially nice one, although that is a bit of a value judgement).
I've used this before - really nice library and an easy way of getting started without having to write so much custom code. Only down side is that of course it's still faster to hand-write a parser :)
That was the system they already had, spinning out a clone of the old one they were using was presumably seen as the easiest way to separate the two banks. And for all the negative press it got in that article, it did at least work...
If people have done architecture-specific things they may not compile (or worse, crash inexplicably at runtime).
I tried doing more or less that (compiling a C++ Windows app for 64-bit) a few jobs ago and eventually discovered that way down in a library somewhere a dev (who had long since departed) did some trickery in string processing routines that relied on arguments being lined up on the stack, which is no longer the case with the x86_64 calling convention. That remains the worst piece of code I've ever worked with - it's innocuous to look at, and any developer who understands why that works should also have known better than to do it.
More generally, integer size issues can arise - if `int` remains 32 bits it's no longer enough to capture the difference between two pointers (and obviously should never have been used for that, but often these things happen).