Why Apple and Google Made Their Own Programming Languages
Gamoid writes: This Business Insider article looks into the state of Google Go and Apple Swift, highlighting what the two languages have in common — and why tech companies would bother involving themselves in the programming language holy wars. From the article: "One fringe benefit for Google and Apple is that making your own programming language makes recruitment easier — for instance, since it builds a lot of its own server applications in Go, Google is more likely to hire a developer who's already proficient in the language since she would need less training."
Right. Apple created Swift because Objective-C was a nice language for the requirements of '90s computing, but is starting to be limited by its C heritage. They needed a more modern language that interoperates very well with Objective-C (because they have a lot of legacy Objective-C code that isn't going away any time soon) and this required making a new language because there weren't any good contenders available. MacRuby is the closest, but falls short in a number of areas.
Google didn't create Go as the result of some corporate masterplan, a small team at Google created it and managed to get buy-in from some other groups at Google. It's still far from the most widely used language for new projects inside Google, but it does have some advantages (though is slightly let down by Rob Pike's refusal to accept that some people who are not Rob Pike have had good ideas in the last 30 years).
The recruiting thing can't really work. It would only really make sense if people would learn a cool language and then discover that there are very few places where they can work and use it. This is sort-of true for something like Erlang or Smalltalk, but Swift is fairly widely used by people developing for iOS and OS X (and would probably not be worth Apple's effort in developing it if it weren't). If the language is successful enough that enough people are learning it to significantly affect the pool of potential applicants for a company the size of Apple or Google, then enough other companies are likely to be using it that it isn't a significant benefit.
I am TheRaven on Soylent News
The reason why companies develop new languages is because the ones coming from academia are focused on the wrong things. Product development requires an industrial strength, strongly typed (for the most part) fast language.
Projects coming from academia are interpreted, JVM based, functional, obsessed with (im)mutability, closures, and lambda functions.
This is not to say those things are not nice, however they are not central to a programming language as used in large scale industrial systems.
It took me less than a week to learn go. I still don't know all of C++ after two years. Learning Go was not a bad investment: the perspective I learned from it helped me write better C++ and C# code from both a OOP design perspective and threading perspectives, and is also a nice thing for my resume (Maybe is helped me get my option to work for Google, I don't know).
And if Pike had the general credibility and design sense of Torvalds then there'd be no issue, of course. In fairness, Torvalds' job is easier because cloning a UNIX kernel is the least interesting design space imaginable: you just do what was done before, but better. Designing a new language is harder.
Still, the problem remains, that Pike is no Torvalds. Yes he did some good stuff a long time ago. But Go sucks.
Go sucks because (in no real order)
1. There is no debugger that is worth a damn. GDB is barely functional. Pike's view is that this is unlikely to ever change because gdb would need to understand the Go runtime and the Go guys don't seem to be building their own debugger.
2. The compiler is only fast because it doesn't do a lot of things modern compilers are expected to do.
3. You can't write generic code, but because this is such a stupid limitation, the built in functions are generic. So you can write them as long as you are Rob Pike, essentially.
4. Go code doesn't use exceptions. It uses error codes instead. This makes lots of code into a giant clusterfuck of "if err != nil" type checks that nest horribly, are incredibly verbose, are easy to miss out and which destroy any chance of getting useful stack traces when something goes wrong.
5. Go does not seem to know who it is for. Pike has claimed Google needs it because Googlers are idiots who "are not capable of understanding a brilliant language". No shit he really said this - I guess that didn't do much for his popularity inside the googleplex. Originally he said it was a "systems language" and then tried to retcon it as "by systems we mean web servers at Google", a definition of systems that nobody else uses.
6. Go has no versioning system: you import packages by referring to github paths and it just grabs whatever is at git master (ya rly)
7. CPU profiling is a joke. It doesn't work at all on MacOS.
8. It's basically reinventing Java and the JVM but very slowly, and whilst loudly proclaiming it's totes different because static linking! Except now they're adding dynamic linking too.
9. The GC is a decade or so behind the cutting edge
10. The Go Gopher is creepy
...and it had nothing at all to do with recruitment.
When Apple came up with the LLVM static analyzer, they became much more aware of just what kind of coding mistakes were costing them the most time and money, and Swift addresses those issues.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."