Hacker News Reader

Comment by niggler | Hacker News Reader

"Go compiles down to native code and it does it fast. Usually in just a few seconds."

Very strange statement. Most programming languages/runtimes do small operations very quickly.

What do you mean? He means that you can compile a pretty large program in seconds, most languages' compilers aren't that fast.

What's "pretty large"? It's fair to say that compilation is quick, but that's meaningless without a comparison.

For example, you can generate really short C++ programs that exploit the template mechanism to perform heavy calculations at compile time.

It's not a scientific test or anything, but the results are so marked it's almost worth not even bothering to measure it:

24k loc of C (24743 total excluding headers and comments), using ninja and cmake, without using the autofail tool suite (which ups the time taken about about 150%):

    $ time make
    ...
    real	0m16.929s
    user	0m9.952s
    sys	0m4.641s

23kloc of go code (23588 total excluding comments):

    $ time go build
    ...
    real	0m1.667s
    user	0m1.331s
    sys	0m0.214s

What do you mean? Even C# is measured in millions of lines per-second. The only compilers that are kind of slow these days deal with complex static type systems (Scala), whereas Go has a simple static type system and should compile fast.

Agreed. In terms of compilation times, Scala feels as slow in compilation times as C++ did in the early 2000's. Kotlin and Ceylon are showing that it's possible to be a modern JVM language and still compile fast. Hopefully, Scala can learn from them.

Martin Odersky does care about compilation speed a lot and pulls out as many tricks as possible to make it faster. But Scala has a way powerful type system in a way that I doubt Kotlin and Ceylon are barely approaching. I don't think many want to give up scala's features for better compilation speed, which anyway can be mitigated via better incremental compilation (disclaimer, my experience is about 5 years out of date).

With c# though it has to compile it again at runtime which destroys your advantage.

That hasn't been true for a long time (ngen.....).

Ngen is useless if you're deploying to IIS. Think of views, asp.net pages etc. You're to going to put them in the GAC are you. Ir makes pretty much no sense to ngen anything other than stuff exposed to com or core framework bits. All you do is fuck yourself at deploy time.

I've never done any asp.net programming, but then isn't C# competitive with everything else in that space (like python, ruby...)?

.net has a pretty good back end and the only thing you really fight with is not instruction compilation/execution time, but garbage collection. GC is mainly why you might want to use C++ sometimes instead of C#.

Well to be honest we decided to use go for a couple of things rather than c# (out logging back end and configuration store forked from doozer) and it ended up being used for considerably more in the end precisely because it is very easy to a) get deterministic GC behaviour and b) profile it.

Is there an implicit claim being made that go is already competitive with C# on performance? If so that would be huge, the CLR is very mature and tuned, much faster than the JVM.

I'm also surprised to hear they are ahead on garbage collection. Assuming they are using a sweep and/or copy collector and not reference counting, why is it more deterministic than the CLR's?

I'd like to see some benchmarks/numbers if you have them handy.

I would write it up but you're not allowed to (check the license that comes with windows server and the .net SDK).

Anecdotal evidence points to go being faster on nearly all counts bar regular expressions once you know what you are doing. The GC differences come from the fact that go does a hell of a lot less allocations. It's possible to write complex code in go which doesn't allocate or GC at all. The same is not true for the CLR. Fundamentally the GC in go is slower and causes more pauses but you can easily tune around it without shitty hacks like the disruptor pattern.

Anyway numbers cannot be published thanks to Microsoft's suspicious intentions with their EULA so you'll have to compare yourself behind closed doors.

I've read the EULA, it's mostly about best/fair practices when releasing benchmarks to the public. But having this codified in the EULA must give legal departments the shivers! I'm surprised there are no perf benchmarks on the web comparing Go....to anything! The last I heard they were way behind even the JVM on perf; just because they ahead of time compile doesn't give them much of a natural advantage here (since JIT compilation is not a perf problem in practice).

.net has value types that you can use to avoid allocations. I've used them to write GC free code before where it's necessary, like doing a physics engine. I'm not sure if this is comparable to how you are avoiding GC in Go.

That's what it's supposed to be, but somehow when I press "Go" on VS, in a project with <200,000 lines, it takes several seconds to compile and start.

This is not the compilers fault but rather something choking somewhere else in your VS tool pipeline, most likely the debugger.

> most languages' compilers aren't that fast

All mainstream languages compile in about that ballpark, if not faster.

I've always found it odd that one of the driving design principles of Go was "fast compilation". It's always struck me as odd and short-sighted, obviously motivated by the Go authors' history with C++. If only they had spent some more time studying other languages, they would have realized that compilation times are really not a concern in languages these days, and they might also have designed Go with more modern features in mind, such as exceptions and generics.

Not really a concern? I don't agree. Look at large C++ projects, and let's not speak about GPU frameworks like CUDA, OpenCL and OpenACC. If it weren't be a concern, software companies wouldn't invest in clusters just for compilation.

Didn't I just single out C++ as the only mainstream language being slow to compile?

Apparently you're stuck in a world where nobody around you uses C++. I hate to be the one to break the news to you...

Didn't I just call C++ "mainstream"?

Contrary to what many young developers may think, C and C++ aren't the only languages with compilation to native code.

Already in 1987 Turbo Pascal 4.0 was compiling quite fast, Borland states around 34,000 lines/minute for the 5.5 version in 1989.

Similar compilation speeds are possible for languages with modules, since the early 80's.

Go's compilation speed is only news for someone that never used a module based language for systems programming like Modula-2 or Turbo Pascal, just to name two.

It doesn't matter if somebody knows Turbo Pascal 4.0 or Modula 2 if you can't use it.

We are repeating history because the old ways were forgotten or replaced.

What he was trying to say is that you shouldn't "design for fast compilation". You should design the language to allow modularity and fast compilation will naturally follow.

> It doesn't matter if somebody knows Turbo Pascal 4.0 or Modula 2 if you can't use it.

Some Modula-2 compilers:

http://www.modula2.org/adwm2/

http://plas.fit.qut.edu.au/gpm/

http://www.modulaware.com/

http://www.excelsior-usa.com/xdsx86.html

Modern Turbo Pascal compatible compilers:

http://www.freepascal.org/

http://www.mikroe.com/mikropascal/avr/

http://turbopascal.org/

http://www.embarcadero.com/products/delphi

It is just a matter to look for them.

Actually, compile time was a huge factor during the design of Go, due to the massive code bases at Google.

See http://talks.golang.org/2012/splash.article for discussion on the import/compile system.

At the kind of project sizes you see at Google, you start to measure compilation time in tens of minutes. If you have a source control system that triggers an automatic build every time you upload a change for review, can you see how waiting 45 minutes (a number I got from a current Googler) to compile and verify that your change doesn't break the build might just be an inspiration to put a focus on compilation speed?

Also, when you code with generics, you're coding with Hitler.

It looks like Go has a compiler implementation with a custom linker and object format. Turbo Pascal got much of its speed from its linker (and by having a module system instead of include files) so they may have decided on the same strategy. They do list the Wirth family of languages as an influence in the FAQ -- of course Oberon and Plan 9 also have history with the Go designers.

Reply on news.ycombinator.com