Aren't most serious languages designed for large code bases?
(and compile faster than anything else),
So, why not invest in incremental compilation for an existing language? E.g. the ECJ compiler for Java has done wonders in terms of immediate feedback while developing. clang aims to do the same for C code and slowly makes editors and IDEs more effective.
Anyway, don't take this to mean that you're doing software wrong if you don't see the value of Go.
I fully agree with the author, on the one hand Go does not provide the performance of C or C++, on the other hand it nearly no useful new abstractions to manage complexity. Languages such as Haskell, OCaml, F# or even D provide a better type system and have similar or better performance.
Google is a special case
Out of curiosity: how much is Go used in Google? What percentage of new projects use Go compared to e.g. Java or C++?
Maybe the big companies like Google and Facebook are approaching a new meaning of a “large codebase”. They have a huge number of programmers, the development is much more distributed into different locations and time zones, and the release cycles are much smaller than they used to be with large codebases in the past. There’s for example this very interesting discussion about the way these companies use their versioning systems:
https://news.ycombinator.com/item?id=3548824
Some of the practices (like keeping their whole codebase in one big repository) look quite questionable, if not downright stupid from a smaller viewpoint, but make sense in their case. Go could be a similar thing – most serious languages are designed with good modularization, encapsulation and other features that support large scale code bases as most of us know them, but that does not mean these languages are a great match for software at the Google scale.
If codebase is that large, language alone can't solve all the problems. Be it compiling time, testing time, or whatever problems large codebase may have. I guess that's exactly what Steve Yegge tried to say in his famous Platform Rant blog post.
Haskell is definitely interesting. If I wanted to build a large system that was super-performant, I'd look at C, Haskell, and Go. I don't know enough to make a great decision, but all three look good.
Go has the advantage of being designed for the kind of thing Google does - massive concurrency. It's also like C, which make it easier to find good programmers who are confortable with it. Actually, you'd be hard pressed to find good programmers who are uncomfortable with a language that's nearly C. I'm not saying Haskell programmers aren't good programmers, but Google probably doesn't have enough of them, and they'd have to port their existing code to a completely different base (bad idea).
The original article complains about Go's GC. For a single process application, this could be murder. I don't think Google uses a single process.
I intentionally said most, since, obviously there are serious domain-specific languages. But stating that Go is designed for large code bases, creates a false dichotomy.
Go has the advantage of being designed for the kind of thing Google does - massive concurrency.
So, claims the C fan since there's GCD, so claims the Erlang/Scala fan since it has actors, so claims the Haskell fan since it has green threads, STM, and purity.
Also, is Google interested in massive concurrency or parallelism?
It's also like C, which make it easier to find good programmers who are confortable with it. Actually, you'd be hard pressed to find good programmers who are uncomfortable with a language that's nearly C.
That's a good point. But as a result it provides only a marginally better type system, at the cost of performance compared to C. Why not make it a lot better than C, with the same performance?
It's kind of a domain anti-specific.
I would. I used the gtk-perl bindings for a project and I thought they were very well done. Previously I had only used the C bindings and taking the step to a higher level language (and more importantly, one with closures) was a very nice step. It was a much better experience than doing Cocoa with Objective-C, IMO, but that could have also been related to the specific (smallish) project I was doing.
For many things, GC is a huge productivity boost. I've heard good things about C99, C will probably evolve into a language with a better type system anyway. I don't use C myself, but I don't see why there couldn't be a flag to ensure code only uses a saner subset of the type system.
Well, C is basically designed for Version 6 Unix, the Programmer's Workbench http://en.wikipedia.org/wiki/PWB/UNIX and troff, not a very large code base by today's standards.
Of course it's still a horrible kludge. But the reality is that C++ exists and is widely used ;).
Why the seemingly almost complete lack of love for Pypy from Google then? It's not like you can stop using Python anytime soon even if you keep extending Go. I believe Google's made one tiny donation to Pypy. Given their benchmarks (http://speed.pypy.org/) and given Google has literally tens of billions in hard cash lying around I can't see how you can't get them some money. A few hundred thousand to Pypy would be justifiable on the performance improvement YouTube would experience alone. Sure the motto is "don't be evil" rather than "do good" but this seems like a no-brainer. Can you give reasons why it's not happening?
(2) Last thing I heard, Google's trying to minimize their Python usage in favor of Java.
But Django and Rails seem to be the major reasons why people continue to use Python.
Having said that no company that is making billions in profits is going to bet their very survival on a framework written and maintained by volunteers. Frameworks come and go, Every 5 years there is something new.
This is a remarkable claim. Well beyond what the most dedicated perl enthusiast could make with a straight face.
Do you have any supporting data or evidence to back it up?
Even in such cases one you infrastructure begins to expand, one you are a reasonably sized team. Perl usage becomes inevitable.
Even among the heavy Python using companies like Google, its becoming clear why anybody would not use Python or even deprecate it in production. Because it doesn't quite really have a strong dedicated niche. Php has the web, Perl has the scripting/glue part on the Unix environment. Java has the static large app part.
Python/Ruby have great web development frameworks.But when it comes to scripting, there are no real alternatives to Perl. And besides if you wish to develop large applications, Static languages serve well. There is no point in using Python when you don't want to cook things quickly.
You will be shocked how many places apart from web communities and forums like these people haven't even heard of Ruby and Python. Most of my friends in big companies some of who also lead big teams over the years 'have just had a look at Python'.
I realize that I have posted this in a community that likes Python a lot and I'm likely to be downvoted. But I'm writing just what I've seen over time.
Regarding your other comments they seem to be way off base and just using your personal bubble/ "what I've seen over time". Ruby and Python have crushed Perl in modern web development (Twitter and Reddit come to mind among many others). Python has vast user communities in research and science (including computer science teaching now, MIT, Stanford). Perl might be before Ruby in the pack behind R/Matlab/Mathmatica/Python in some research settings, but that's not saying much. Python additionally is the chosen admin utility language of Red Hat and Ubuntu for their Linux distributions, so it seems there are real alternatives to Perl.
I'm not saying Perl is bad, I am just saying objectively it's been in decline since the 1990s against its rising competitors in all areas: universities, other research, Linux systems administration, application development and web development.
I don't suggest otherwise. It's known that Python is one of Google's three languages approved for internal use (or apparently four now that JS has got a foothold). But I'm sure I've seen reports that people are nonetheless being pushed towards Google's other two officially blessed languages, at least on production code - and in fairness, Google is a place where developer time is often cheaper than the machine time you have to spend to save developer time. But moveover it seems that, even when people in Google do want to fix their Python performance issues by making Python perform better rather than by reducing its use, they tend to want to do it in-house rather than by adopting or supporting other people's work: look at Unladen Swallow. That would be in line with the rather hubristic, command-economy approach - "let's hire all the world's smartest people, then order them to build the future" - that seems to determine Google's actions in general. Hiring GvR fits that pattern too (as well as making plenty of sense).
But I'm sure other people here are much better informed about this than I am.
This creates a dilemma for a lot of people while choosing a technology. If you have to choose a language where you don't want to develop stuff quickly. Then you now have sufficient time to choose a static language and then develop stuff at the speed desired.
For other quick stuff there is Perl anyway.And it doesn't make sense to use Python, which is slow(compared to java), which doesn't give quick development cycle(compared to perl).
If you wish to relevant for a long time, then you have to do at least one thing properly.
It is. When you launch Visual Studio >= 2010 it's there alongside C# in the Project Creation wizard.
IIRC, the original research was going to be into making Haskell for .Net, but there were enough issues (in particular, being purely functional makes interop with C# and the existing .Net libraries radically more difficult) that ML seemed like a better fit.
http://msdn.microsoft.com/en-us/vstudio/hh388569
Microsoft also sponsors Haskell and OCaml research via Microsoft Research centers.
Java and C# helped their companies do that.
But with Python,Tcl and Haskell its a little different. Its good for the companies if they off, but if they don't they don't loose anything.
Still, I assume this is fixable, and it's getting more and more competitive in terms of the megabyte-second cost of computation (i.e. if you use twice as much memory but run four times as fast, that can be OK depending on the circumstances).
They've enforced style by mandating committers hook a linter into a git pre-commit hook, and compilation time hasn't been a huge problem since the languages always support incremental/partial compilation (Java/Lisp for the most part).
I can imagine that not working at Google-scale.
Style-related presubmit hooks are a part of every project at Google. Plus readability requirements, etc - style is kept pretty damn consistent.
> compilation time hasn't been a huge problem since the languages always support incremental/partial compilation (Java/Lisp for the most part).
This is the far more interesting problem to solve at scale with a single centralized repository.
Use http://astyle.sourceforge.net and add it to your build process and/or commit or push/pull hooks of your source control.
(I am surprised I have to give this tip to anyone on HN!)
However, Python, because space is significant, tends to look fairly similar "in the wild". Add minimum adherence to a style guide and you're pretty close to that goal.
Unless something changed in the last six months that's not the case, there is a tool called gofmt that will do the reformatting if you call it.
I'm not really sure I see publishing a style guideline in the form of code rather than english text makes any difference, at least it didn't make it for my go code.
I suspect it has more to do with the fact that some of the developers behind go use acme than anything else.
If Go is really designed for large code bases, then IDE support for go with code browsing, refactoring, debugging and profiling would be developed in parallel with the Go language itself.
Since Go IDE support go only as far as petty Vim and even pettier Emacs modes, I couldn't call go "made for large codebases".
One key feature is that the Go compiler itself is the style guide: it automatically reformats your code to remove style guide violations. This makes it easy to work on a codebase the size of Google's because everything looks like it was written by the same person. We try to do the same thing for C++, Java, and Python, but it doesn't work as well because the process is manual.
Similarly, compilation time and runtime for every component, no matter how unimportant, is of utmost importance for Google's codebase. It may not matter how long it takes to run one one-off script, and it may not matter to you how long it takes to compile, but it does matter at Google because we compile every project and run every test after every commit. (OK, builds and tests that are obviously unaffected are skipped. But it's still a lot of code being built and tested.) So your Python project that takes 5 seconds to run tests instead of 1 second ends up wasting decades of CPU time throughout its life time. Same for C++ projects that take many hours to compile. Go tries to be as expressive as Python and run as fast as Java (and compile faster than anything else), and this saves lots of time in aggregate. (Remember, when you break someone's build, the delay between submitting your change and the system knowing about the breakage can result in a lot of hair-pulling for the developers on the project you broke. But if we can know the build is broken before the change is even submitted, then many hours of developer productivity are saved.)
Anyway, don't take this to mean that you're doing software wrong if you don't see the value of Go. Google is a special case and just because we have some problem doesn't mean you should have the same problems. One-man shops should optimize for individual efficiency instead of aggregate efficiency like Google does.