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.
> If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking).
We are granted a license to use it on GitHub by the GitHub ToS.
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.)
Kubernetes has enormous masses of repetitive code that is essentially a workaround for the absence of generics or other kinds of improved types. The reliance on "union types" -- really, exclusive arcs -- gives me the heebies and also guarantees that there is a bottleneck for new features: PRs to core. And then there's the whole TypeMeta thing. An entire dynamic type system because Golang can't express what Kubernetes needs.
And no, I don't see code generation as a good thing. It's fragile and difficult to safely upgrade.
Kubernetes has more or less invented their own type system. I agree that much of it is horrible to deal with, but I don't know how you could easily express it in any language.
Of course someone could always prove me wrong by doing just that.
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.
This is not about beauty. It is about reliability, simplicity and safety, all of which contribute to development velocity.
Golang is simple only for toy examples.
At scale Golang codebases are difficult to navigate, understand and test due to the repetitive repetition of repetitious repeats.
And the idea that at-the-time-viable alternative languages like Java, C++ or D are too slow for something as relatively lightly trafficked as the core Kubernetes controller codebase is just plain silly.
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".
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.
The code will indeed still be easily understandable on a line-by-line basis, but larger units (functions, groups of functions, modules) then become harder to read and understand due to large amounts of noise. As you progress along to more advanced, larger codebases, with novice-style code you just pile boilerplate on top of boilerplate.
Larger Go codebases remind me of old versions of Java where they went as far as to embrace all the boilerplate and call it 'design patterns'. It's sad how Go designers recognized that Java code tends to be hard to read and generally bad, but apparently weren't really able to discern why that is. They decided to just blame it all on inheritance and exceptions.
(FTR I'm not advocating for inheritance or exceptions here, but believing that those are the root of Java's problems and simply omitting them will somehow magically make a language better is just naive & shortsighted.)
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.
> 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.
AH, Europe. In the US you pay around $1.5 to $4 per withdraw, because the ATM network is a private enterprise not owned by the banks.
You will get there, unfortunately.
And you completely missed the point. Loaning/re-investing with volume is a very sure way to make money, and was what banks used 30+ years ago. now they pad it with fees for everything.
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.
maybe by buying inflation indexed bonds on a rolling basis. nab something like 1-2% interest on the customers' money in an extremely safe investment vehicle, then return most of that to the customer after paying off infrastructure costs. (does this work? i have no idea whatsoever)
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!
Yep, I have probably messed up the relevancy a bit because of constantly experimenting with how to load the model/index. Right now I'm using phrases (sentences) as well as words, both extracted during the tokenization process. Initially I used only phrases because using the current 65K vector-space model that would match any word to any phrase containing that word. There are perhaps sideeffects of reinforcing each word like that.
"long way to go"
I don't think so. The real bitch was to figure out how to maintain a good representation of the language model on disk. How to update it. Remove data from it. Now I anticipate a couple of months fine-tuning the balancing of the tree and testing relevance. From what I have heard so far, relevance is a little sub-par.
Scaling is the next thing. I have a great plan for that of course, mentioned somewhere in this thread.
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.
You should really be careful about c preprocessor macros when you do things like this with .c files. You should always undefine any macros defined in a file which are not properly namespaced(as much as C allows for pseudo namespacing).
This only does what you want if you mush everything together into a single translation unit. Otherwise, you will get duplicate definitions for everything in onefilelib.c.
Is there a prominent C code base that does this sort of thing? I’m sorry this is all very questionable advice IMHO. What would be one word in a makefile (onefilelib.c) is a 4-line jumble of preprocessor macros, names starting with __ are reserved, and the suggestion to redefine main and entry points smells like more #ifdef spaghetti.
The #ifndef rigamarole is https://en.wikipedia.org/wiki/Include_guard and at least used to be fairly common. I also used to see the __FOO_BAR_H__ naming convention for these defines all over the place. I'm not sure if __ identifiers being reserved is a (not very) new thing or if it's always been around and people are just now more generally knowledgeable about the fact that they shouldn't be used.
Yes, the include guard is a very widespread technique for header files. My objection is against #include’ing a .c file to support the questionable trend of ‘single file libs’.
I wasn't suggesting this as a serious method of organizing your project - merely pointing out that this quick hack can be done and is rather straightforward. And I did actually see it once or twice in the wild.
I am not sure of a prominent code base that does this exactly, but some people do similar things with "amalagmated builds". Like https://www.sqlite.org/amalgamation.html
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.
