Hacker News Reader

Comment by 5e92cb50239222b | Hacker News Reader

What a joke. Go's GC was always pushed as a 'no tuning required' solution, as opposed to e.g. JVM collectors. As it turns out in real practice, there's no one size fits all solution and it does require tuning in non-toy applications. Go just keeps repeating the same mistakes that's been solved elsewhere 40-50 years ago.

View on HN

oh my a company that runs on over 70k CPUs has atypical problems. surprise surprise. oh and look, they were able to resolve it with a few lines of code. the horror.

I think this is an overly harsh take. In many applications Go's knob-less GC works well enough and avoids any fiddling at the cost of non-optimal memory utilisation in some cases. It's not obvious to me that adding loads of knobs to help tuning for special cases is an overall win as it undoubtedly adds complexity for many users who are not bothered about this fine tuning.

Given that two of the original team members also ignored the state of art of systems programming and just got lucky with way UNIX licensing was managed in the early years, Go's approach to language design isn't a surprise.

That "lucky" is conflating two things: UNIX winning and UNIX surviving. The second part is not chance based, imho. So open question is weather any of the contemporary "state of the art" approaches would not have run into design issues that become manifest at internet scale utility. Naturally the original gophers must think UNIX overall made the right choice ignoring SoTA.

When the option is between free beer or paying tons of money for Xerox, DEC and IBM alternatives, it is hardly based on merit.

That's granted. That's selection step 1. Then UNIX cum Linux approach eats the world for a couple of decades, pulling its weight. If it was inherently flawed, if SoTA approaches were addressing inherent issues, then it would have failed selection steps 2..n. And we would have long ago bitten the bullet to replace the "lucky" legacy. So, yes, the lucky contender has issues, has warts, can certainly benefit from x, y and z, but as is, it continues to be viable at scale and that is not "luck".

Second, we simply don't know, considering all aspects including human resources and engineering economics, whether Xerox, DEC, or IBM's alternatives would have fared better than UNIX. I'm open to learning why/how if this is a shut case in your opinion.

I bet if UNIX was sold with the same market prices as Xerox, DEC, or IBM's alternatives, it would have been a footnote on the history of OSes, like many others since the mid-1950's.

You elicit my first ever OMG. Yes, granted! :) But that's just mechanics of computing history. That was the lucky break. But it wasn't 'garbage' getting lucky. It wasn't some lame specimen that survived a battle that killed off titans of a species. It was and remains a contender. And, to the point, its authors determined (certainly influenced by not being or as SoTA aware as academic CS lights) that a compelling 80% solution with a [simple] versatile conceptual model can work and it has. Same story goes for Go the language. Of course it is like PLT reto with bolt-ons, but like it or not, it is a viable approach to building software and systems.

Reply on news.ycombinator.com