Heh, this is kind of complicated. It was Dorsey's initiative. The project's goal was to produce a technology that Twitter could move to. However, nobody on the team was from Twitter.
I'm going to be blunt and state that what most people want is not what they actually need. If you use Git for how it was designed, the commands remain generally pretty clean. If you come from an SVN mindset, you are probably not really using Git the way it was designed, and Mercurial fits better.
I have used (actually introduced) Mercurial before at a company and considered them basically equivalent enough, only to get stuck in some horrible design choices of early Mercurial (named branches and not having rebase by default). I am happy to see these elements corrected in Sapling, giving me enough confidence that I might actually use Sapling over time...
There are two reasons Git is better, and the UI is NOT one of them: speed and repository format. I think Keith Packard wrote about this best: Git is technically under the covers way superior over Hg, it's not even a competition. For usability, I think with Sapling we finally get some real competition and that might be the user interface alternative we need, as well as the monorepo approach it was basically made for, but let's just say that I don't trust people who think Mercurial is technically even close to a good idea.
They have mentioned that you don't really need it as an explanation after they already said for a long time that they do consider it, from the start. They never strayed from that POV.
No, the documentation stated that Go was designed for reading without backtracking. That results in single pass compilation being possible and thus being faster, but that was never a limitation that was imposed. The reading without backtracking is still valid: go generate DOESN'T work on .go files, only on any other tool that generates .go files.
About the second part, you seem to mix up goroutines and channels. In a concurrent system, you would need locks for your example, and channels fix this. Goroutines are just the representation of independent processes and can be implemented and ARE implemented differently per compiler, check e.g. how tinygo and gopherjs do this.
Your example point 2 doesn't make any sense, check fan in and fan out patterns with channels. Go supports message passing, that is what channels are. You really didn't try Go and it shows.
They never rejected it. In the very first post launching it they commented that they considered Generics but didn't add them because they didn't find a way that works well with Go's principles. I'm happy it took them the time it did to get to the current design. They did have a vector type before version 1 too, they intentionally removed it for similar reasons.
Generics were considered at the very release. Go just focuses on getting it right. And I love it for it, because to this day Go is the only language that got OOP right, and now Generics.
Go is a language made for the human factor.
Go generate by the way is mostly NOT used for generics. Check for example Vugu, which compiles UI documents to pure Go code. Go generate is made to incorporate any random external tool without making it complicated for the humans using it. And it makes sense because the goal was not single pass compilation, it was single pass parsing, which is exactly WHY Go generate is useful. It is still true to the exact way this has been defined. Go is simple in ways that matter.
I've designed an interview test before and I am ironically now doing a very similar interview test to what I designed for the company I used to work at. It worked extremely well for where I used it and I am absolutely thrilled to work on it now for this company. The key element here is indeed relevancy to the job you apply for and not looking for a perfect answer.
For anyone doing programming tests, I would like to give some advice, too, based on the tests I did and got through successfully:
- Always give it a try
- Always explain what you do and what you are trying to do
- Don't worry about sending in an incomplete test when you don't manage to do it
- Be verbose about what you are trying to do to solve it
- Don't be afraid to ask questions
My first great programming job was at a place where I got a hard mathematical problem to solve, and I didn't manage to solve it at the moment, so I asked if I could take it home. I didn't manage to solve it at home but sent in the broken code that I had either way.
I got the job.
Why? Because the broken code I sent in showed that I understood recursion (it was for a Common Lisp job, that code was in Clojure) and the other people, even if they did manage to solve it, used more common languages and iterative solutions. He wanted someone who got the spirit of what they were working with, so that got me in. I asked my boss later how to solve that question, and he didn't manage either.
When I did the interviewing myself, the situation was similar. One candidate sent in a huge resume that looked impressive, but didn't send in the test. Immediate fail. Two others had a hard time with the test, but they showed that they cared about making it work, and that was enough for us to accept them: the core thing we wanted to see was that they could learn and cared enough to learn about what they needed.
One of those became main programmer and leader of many others later on, and made the company hugely successful.
When I had to get the right people for a job, I made the sifting assignment simply: write an app that consumes a JSON API. I got an Indian guy with a long CV who never even tried, and a guy who machine translated the Dutch ad and sailed through this question. Guess who got the job...
reply