Yeah, more interesting is having them rediscovering Turbo Pascal compile speeds.

EDIT: I wonder why the positive effect to re-discovering that not all compilers need to be like C and C++ compile speeds and that it was once upon a time mainstream, is worthy of downvotes.

Can't critique this one: Go was an attempt to re-create the Oberon experience in modern setting with some additions from other languages. Rather than accidental re-discovery, getting Oberon (not Pascal) speed out of the compiler was an explicit design goal. One of few examples of modern IT really learning from the past.

Unfortunately, they didn't learn about the stuff between Oberon and 2007 that would've been nice to have in a modern, app language. ;)

It is not a critic, apparently it was understood as such.

The remark is tailored to those that think compiled languages can only be slow as C and C++ compilers, since they never used anything else, and then jump of joy when they use Go.

Yet if it wasn't for the VM detour of the last 20 years, that experience would probably be a current one, instead of being re-discovered.

"The remark is tailored to those..."

Ahh. Ok.

"Yet if it wasn't for the VM detour of the last 20 years"

You mean the C++ and VM detours? ;)

I mean having the JVM not adopt the tooling model of Eiffel, OCaml and others where you get to choose bytecode/JIT for developing and AOT compilation for release builds.

Oh i hear you. That makes sense. I wanted all of them to do incremental compilation or interactive development for build then AOT for deploy. We're on same page there.

For the curious (I am sure pjmlp is well aware of this) D and Go compile speeds are pretty neck and neck. DMD was faster, then Go caught on, not sure which one is faster now, depends on the nod. If I may add, D is a lot less impoverished than Go, although its coroutines story is not that strong.

Are you claiming Go runs at the speed of Ruby/Python/PHP etc? Because from what I read, migration to Go from above mentioned language led to lot of hardware / memory saving. I'd think Java can certainly be considered having highly optimized compiler / runtime. But it has almost same performance as Go and much higher memory usage compared to Go.

http://benchmarksgame.alioth.debian.org/u64q/go.html

> Are you claiming Go runs at the speed of Ruby/Python/PHP etc?

No. I'm claiming it doesn't perform anywhere near the level of optimization of GCC and LLVM.

> I'd think Java can certainly be considered having highly optimized compiler / runtime. But it has almost same performance as Go and much higher memory usage compared to Go.

I disagree with what seems to be your implication that compiler optimizations don't matter (and almost everyone else who works on compilers would also disagree), but I don't really want to turn this thread into a critique of the benchmarks game, so let's just leave it at that.

> … and much higher memory usage compared to Go.

Please don't jump to the conclusion that huge differences in the default memory allocation of tiny 100 line programs means there will be similar huge differences between ordinary large programs.

Notice that even for those tiny 100 line programs, the difference can be more like 2x when memory actually needs to allocated for the task.

"Compiler optimization" in this thread is referring to speeding up compilation time†, not runtime of generated code. Go produces fast code, but the go compiler does not generate that code particularly quickly.

† Which can be seen as a runtime cost for interpreter+JIT languages, but that's a different issue. We're talking time-to-steady-state when the interpreter is fed a file (which is something Javascript engine devs worry about a lot), not benchmark-speed-at-steady-state.

No, it's the opposite. The Go compiler generates medium quality code but compiles fast.