Of course I appreciate the fact that they’re improving it, but aren’t go builds already extremely fast? I’m still learning it and haven’t built anything of significant size yet, but I don’t remember seeing compile times in any language that are comparable to go’s.
When go was released the authors made a big deal about compilation speeds. Fast enough that after hitting enter you got a prompt back almost immediately.
Then compilation speed started trending down, and people are really excited to make up some of that ground.
They are. However people and tools often use Go in a “compile on save” manner, similarly to interpreted languages. When Go suddenly had a significant hit in 1.5 people’s workflows got “destroyed”. Since the Go team said it would get better again (I don’t thin anything more specific has been said) people are eager to get that back.
I agree, compared to other languages it seems like a non-issue. It’s just that workflows started to depend on it to some degree.
Yeah–the autotranslation from C to Go regressed a lot. Some big wins seem to have been replacing chunks of autotranslated C with native Go (first big piece like that was the SSA backend), tricks like this, and general speedups for all Go programs that help the compiler. Was smart of them to put that regression in a release with the background GC everyone wanted, haha!
I don’t know if or how quickly I expect them to get back to 1.4 speeds, since there is probably pressure to add optimizations that take compile time but make the resulting binaries faster. It sounds like improvements to the total CPU use (not pause time) of the GC would be one category that could make an outsize difference to the compiler, since it allocates a big object graph (the AST, types, and other internal data on your code) and keeps a lot of it live.
Slightly faster compilation speed. Inching towards 1.4 speeds, but will it ever reach or pass it?
Of course I appreciate the fact that they’re improving it, but aren’t go builds already extremely fast? I’m still learning it and haven’t built anything of significant size yet, but I don’t remember seeing compile times in any language that are comparable to go’s.
When go was released the authors made a big deal about compilation speeds. Fast enough that after hitting enter you got a prompt back almost immediately.
Then compilation speed started trending down, and people are really excited to make up some of that ground.
They are. However people and tools often use Go in a “compile on save” manner, similarly to interpreted languages. When Go suddenly had a significant hit in 1.5 people’s workflows got “destroyed”. Since the Go team said it would get better again (I don’t thin anything more specific has been said) people are eager to get that back.
I agree, compared to other languages it seems like a non-issue. It’s just that workflows started to depend on it to some degree.
Yeah–the autotranslation from C to Go regressed a lot. Some big wins seem to have been replacing chunks of autotranslated C with native Go (first big piece like that was the SSA backend), tricks like this, and general speedups for all Go programs that help the compiler. Was smart of them to put that regression in a release with the background GC everyone wanted, haha!
I don’t know if or how quickly I expect them to get back to 1.4 speeds, since there is probably pressure to add optimizations that take compile time but make the resulting binaries faster. It sounds like improvements to the total CPU use (not pause time) of the GC would be one category that could make an outsize difference to the compiler, since it allocates a big object graph (the AST, types, and other internal data on your code) and keeps a lot of it live.