[foldr]

I don't know anything about CLU. ML compilers are a mixed bag. OCaml (which is a different dialect, of course), has an acceptably fast compiler, but it's not near-instant like Go. Ada compilers are famous for being slow, at least historically. C# is, again, acceptably quick to compile, but not as quick as Go. I don't know about D. I've heard good things about Delphi's compile times, but no-one uses it now.

[pjmlp]

In that comparison you forgot the part of turning off optimizations so that the code quality is similar to what Go standard compiler spends time doing.

The compilation speed drop is easily seen when using gccgo instead.

A side note for Delphi, it is still relatively used in European enterprises, with an yearly conference in Germany.

And I could have mentioned other languages like Eiffel, with their mixed JIT for development and AOT via C compilers for final delivery.

[foldr]

The Go compiler is still faster than most of the competition, even when you compare with optimizations turned off.

[pjmlp]

So you hardly know the languages, never used some of them, but Go compiler is faster.

Very scientific.

[foldr]

>So you hardly know the languages

No, I know all of the languages that you mentioned except CLU. And since I don't think there are even any practical CLU implementations available for modern hardware, I'm not sure how you are able to compare CLU compile times to Go compile times. Are you maintaining a legacy CLU codebase or something?

Now, if there are scientific comparisons available, I'll happily defer to those. But unless you spend inordinate amounts of your time comparing compile times between languages, I doubt that you have any scientific info to go on either.

[pjmlp]

> I don't know about D. I've heard good things about Delphi's compile times

Doesn't look like actually knowing them to me.

> Are you maintaining a legacy CLU codebase or something?

No, just you are apparently stating that a CLU compiler developed to be usable in 1971 hardware will run slower than Go on 2018 hardware, which doesn't make much sense.

Talking numbers, D was taking 1.24s to compile its complete standard library in 2010, (too lazy to try out the latest version) including the piles of template code that it has.

https://digitalmars.com/d/archives/digitalmars/D/D_compilati...

[foldr]

> Talking numbers, D was taking 1.24s to compile its complete standard library in 2010, (too lazy to try out the latest version) including the piles of template code that it has.

I followed in the instructions for building Phobos on the wiki here at https://wiki.dlang.org/Building_under_Posix:

    real	0m12.269s
    user	0m12.896s
    sys	        0m2.150s

Quite a lot of that time appears to be spent linking. I wonder if the post on the mailing list was reporting the literal compile time, rather than the build time?

It was a bit difficult to find a go project of similar size that was easy to build. The backend component of limetext is about 10k LOC compared to 35k for Phobos. When I do a ‘time go build -o foo’ in go/src/github.com/limetext/backend, I get the following:

    real	0m0.163s
    user	0m0.140s
    sys	0m0.207s

Multiply that by 3 plus a bit to compensate for the LOC difference, and it's still pretty good.

Still no idea what you are on getting with regard to CLU. We don't have any info on how fast it compiled.