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.
