Hacker News Reader

Comment by zaphar | Hacker News Reader

You've obviously never compiled java at google :-)

I think that's because they have a lots of Java code to compile. When there are a lot of GO codes to compile, it will take hours as well. I doubt GO's compile speed is significantly faster than Java. Both of them don't have the dependency problem plaguing C++. It would be interesting to compare the two.

I'm pretty sure that go's compile speed is significantly faster than java. It's hard to compare though because java compilation is not the same thing. There is the bytecode in the class files and on the fly compilation in the vm. As well as some stuff that happens when the bytecode is loaded and run.

A lot of go's compile speed comes from how simple it's syntax is besides the gains it gets from avoiding C++ dependency issues. Java's syntax while less complex than C++ is still complex compared to go's. And it won't have go's parse time savings.

Go's syntax may look simpler, but from a how many tokens do I need to look ahead parser perspective, I don't think it's much simpler than Java. Go does have a hand tuned parser written in C, vs the java parser written in java and perhaps not tuned for speed, but there's no reason a fast java parser cannot be written.

Java has jars and classes and dynamic calling. You don't compile everything into one big lump, nor you have to recompile millions of lines of code for one change in a file.

If Go wanted to compete on compile speed, then dynamic loading would be a better idea than having a simplistic compiler that compiles fast into one monolithic executable.

The main reason the Go compiler is fast, is because it is simple and doesn't do many passes and optimizations.

Which is like advertising the fact that your company makes a fast car, but forgetting to mention that it can only carry a driver if he weights 10kg.

Nothing you've said contradicts my statement concerning compiling java at Google.

Go doesn't need to rely on dynamic loading because compiling a library is fast and statically linking the libraries is fast. The result is a monolithic executable true but it's still fast without dynamic loading. Go doesn't compile all the source that goes into a binary every time. Libraries get compiled into an archive and don't have to be compiled again unless they change. In that way it has the same benefit as jars for compilation speed.

Reply on news.ycombinator.com