Comment by microtonal | Hacker News Reader

Comment by microtonal | Hacker News Reader

Parent Full thread

Go is designed for large codebases, which is a problem that the author may not have, and so he may not see the benefits.

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++?

> Aren't most serious languages designed for large code bases?

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.

> Maybe the big companies like Google and Facebook are approaching a new meaning of a “large codebase”.

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.

SQL isn't, and if it's not a serious language, what is? Perl and PHP are what the web app layer was originally built on, and they seem to be designed to maximize developer efficiency for small projects.

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.

SQL isn't, and if it's not a serious language, what is? Perl and PHP are what the web app layer was originally built on, and they seem to be designed to maximize developer efficiency for small projects.

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?

Calling Perl domain specific? I think those would be considered fighting words in some places. ;)

I love a certain subset of Perl with a passion bordering on mania. While I wouldn't call it domain specific, I do think it's better defined by the domains it's not well suited for. I wouldn't use Perl for GUI programming for example.

It's kind of a domain anti-specific.

> I wouldn't use Perl for GUI programming for example.

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.

> 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?

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.

I also don't plan to learn Go, but if I have to because it becomes the de-facto standard for some important niche, then I will. This depends massively on the quality of their implementation and also on that of their competition.

> Aren't most serious languages designed for large code bases?

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.

I think clang has a good chance to became as competitive as Go for compilation speed. This way you will have a fast compile/run process and the power of C or C++.

I could believe it for C (tcc is an existence proof for very fast C compilers), but building a C++ compiler of that speed is a pretty difficult task. Separate compilation for templated code is also really hard to get right, since the standard isn't really designed for it and gives few guarantees; if a templated class is changed, determining when you can safely avoid recompiling classes that use it is tough.

Definitely. I am anxious to see how much C++11's extern template will improve compilation time, when it will be used by large libraries.

Of course it's still a horrible kludge. But the reality is that C++ exists and is widely used ;).

Reply on news.ycombinator.com