byronr

100% on the team making the most difference. (An aside: a software project I've been admiring recently is the Apollo Guidance Computer's. To the moon and back on a 15-bit 1s complement machine and a few kb of memory. It's a case where the team was certainly better than the available tools.)

On the perf side: I'm curious to know where Go sits now relative to C assuming you elide away all heap allocations in your inner loops. In the early days Go's codegen was based on plan9's simple and simplistic C compiler's back end. Things have gotten much better since then and to my knowledge it's within striking distance of C. But I could be wrong.

It's awesome to see all this Java expertise on this thread but at its essence -- a jar file doesn't define the program that's going to run. It's the union of a jar and the JVM it runs on. With Go, the binary is the whole story.

So even if I can predict how a particular JVM will treat a given jar, I'm still stuck if my code might be deployed across a range of JVMs.

I say all this having written orders of magnitude more Go, with apologies to the Java programmers.

Go and Java are close cousins.

The difference is of course the JIT -- with Go the single binary means you can disassemble it to find out what it's trying to do. JIT adds a layer of mystery.

Also, with Go it's largely possible to avoid heap allocations in performance hotspots. With Java I'm not so sure.

I have written hundreds of thousands of lines of plain old C, as well hundreds of thousands of lines of Go over a career spanning three decades. I've used Go in earnest since 2013.

I would pick Go for any large project in a heartbeat.

I have to concur that the haters who post to HN probably have never used this language in earnest.

Here's what you get out of the box:

* Extensive standard library * Cheap concurrency * Fast compilation * Built-in test/benchmark framework, including coverage and race detection * Built-in heap and CPU profiling

Of all the complaints the one I understand the least is the reservations about performance. It is within 10-20% of C, and callouts to C and assembly are possible. (My 8-way multiplexed MD5 routine was written in AVX assembler and lives on in minio.) Extracting that last 10-20% is two or three sigmas away from the norm of how programming languages are used these days.

The objection to generics is similar. The lack of generics shows up -- once in a long while. It doesn't prevent me from being immensely productive with this language.

Looking back at the last few years I've wondered if I could have accomplished what I did in Go by using a different language (C in particular) and the answer, for me, is "not a chance".

No coercion needed. Pre-ANSI C does not have a void type, so unless otherwise specified the return type of a function defaults to int.

As an IOCCC winner I've had my winning entry verbatim on my resume for years. It's small enough to look like a decorative footer and it always garners comments.

Your question has another angle: why would I care to work for an employer who looked down on my IOCCC win? It acts as a filter both ways.

It's hosted on github now and still serves as the login shell for me and presumably many others!

Yes, I did! I used Duff's paper as a reference, and relied on the good taste of all my beta testers to guide me towards a working shell. Back when source code was distributed via shar files in an email.

> Rob Pike probably has never written a program where performance really mattered

Rob Pike has written window system software which ran in what now would be called a "thin client" over a 9600 baud modem and rendered graphics using a 2MHz CPU. He probably knows a thing or two about performance tuning.

One of the eyewitnesses to Bach's playing was Constantin Bellermann. (chronicled in the Bach Reader)

Bellermann wrote about a pedal solo that Bach played: he “ran over the pedals so quickly that his feet appeared winged, with a thundering fullness of sound, and penetrated the ears of the listeners like a bolt of lightning”, and that he “was admired in amazement” by Prince Frederick van Hessen. The prince removed a jewelled ring from his hand on the spot and gave it to Bach. If he had earned that just with the speed of his feet, wondered Bellermann, what would the prince have given him if Bach had used his hands as well?

I wrote a toy lisp 1.5 interpreter in Go a few years ago, and part of the joy was making the core of the interpreter mimic McCarthy's typography. This is my apply function:

  func apply(fn, x, a Addr) Addr {
          if atom(fn) == T {
                  switch fn {
                  case CAR:
                          return caar(x)
                  case CDR:
                          return cdar(x)
                  case CONS:
                          return cons(car(x), cadr(x))
                  case ATOM:
                          return atom(car(x))
                  case EQ:
                          return eq(car(x), cadr(x))
                  default:
                          return apply(eval(fn, a), x, a)
                  }
          }
          switch car(fn) {
          case LAMBDA:
                  return eval(caddr(fn), pairlis(cadr(fn), x, a))
          case LABEL:
                  return apply(caddr(fn), x, cons(cons(cadr(fn), caddr(fn)), a))
          }
          panic(errint("bad node: " + car(fn).String()))
  }