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.
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.
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.
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.
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).
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.
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
