Hacker News Reader

Comment by TurboHaskal | Hacker News Reader

I run a few side projects with a pool of about a dozen developers. Some love Java but others won't touch it, some are C developers, one of them only has experience with PHP, there are lispers, an Erlang zealot and even a Delphi refugee. I personally like Perl and OCaml but couldn't convince them to even consider them. It was a nightmare to agree and settle up with something.

Enter Go, and while we all agreed that the language kind of sucks and $FAV_LANG is better, we somehow stopped bike-shedding and started to get real work done.

Sure, it's not the most exciting language in the block and its community seems to live in the 70s, but sometimes targeting the lowest common denominator can pay off, as is the case for us.

View on HN

> Sure, it's not the most exciting language in the block and its community seems to live in the 70s, but sometimes targeting the lowest common denominator can pay off, as is the case for us.

Except that even Algol 68 is more feature rich than Go, assuming a 60's powerful computer, like the Burroughs B5000. :)

But I do appreciate that every line of written Go code is one less of written C code.

Define "feature".

Go thinks fast compile time is a feature. How fast is your Algol 68 compiler on a ten million line code base?

1. How many people have 10 million line code bases?

2. How many of those people would have much smaller codebases if they used a more expressive language?

3. Of the people who have 10 million line codebases and would still have 10 million line codebases in a more expressive language, how many of those could actually compile their programs faster if they used a language that allowed partial compilation of only the parts of the code that were changed?

Very few people have Google's problems, and I'm not even completely convinced that Go is the best way to solve Google's problems.

Fast enough for a 60's computer, imagine nowadays.

But if you want numbers, Turbo Pascal 5.5 was doing 34,000 lines/minute[1] on MS-DOS back in 1989.

[1] http://edn.embarcadero.com/article/20803

Turbo Pascal isn't Algol 68. A PC in 1989 isn't a B5000. But even accepting the example, 34,000 lines/minute gets you a compile that takes 294 minutes, or just under 5 hours. That's... not very good.

Of course faster hardware is part of the answer, but I suspect that it doesn't cover nearly all the ground between Turbo Pascal's compile time and Go's.

I gave Turbo Pascal as an example, because even when compared against it, there are many features that Go lacks and Turbo Pascal had.

Besides I am comparing an 8086 with 640 KB against a i7 with 16 GB and three level caches.

Go being fast isn't that much of an achievement in 2016.

If Go compiles faster than Turbo Pascal with an 8086 CPU and 640 KB RAM, that is an achievement.

I am going to guess that Go compiles at least 10 times faster than Turbo Pascal. From the numbers you gave, I think at least a factor of ten is left even after you account for the difference in hardware speeds.

So you are stating that Go will compile 10x faster than Turbo Pascal on a 8086 with 640 KB?!

My point is that Go's compilation speed isn't nothing extraordinary, I can keep giving examples of other compiled languages that had equally fast compilers in the the mid-90's.

Oberon, Go's grand daddy could bootstrap itself and build a full working graphical workstation OS in less than one minute if I remember correctly.

Sounds like a prison for programmers.

Reply on news.ycombinator.com