Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting a large production system in Go

matt-welsh.blogspot.com

Post reply on HN
Print view View original

181–190 of 196 posts

Re: Rewriting a large production system in Go

#181

Post by freyr »

dubbledidu wrote: post #177
freyr wrote: post #173

Earlier quoted context omitted.

Take his criticism (not sure it even merits that title) with a grain of salt. Many people on HN and on the mailing list have sung the praises of Go's packaging system.

Yet another Go fanboy getting a bit defensive without having to add anything constructive? If you actually checked your “claims” you would see that people are singing so many praises that the mailing list is continually filled with proposals to fix the worst parts of Go's packaging system.

Your post has no substance, other than to say some people on the mailing list don't like it. But other people on the mailing list do like it. So your post is meaningless and useless.

If you actually have problems with Go's packaging, and care about it enough to write as much as you have, why didn't you simply point out the flaws?

Re: Rewriting a large production system in Go

#183

Post by pjmlp »

derefr wrote: post #6

You know, every time I see some Googler shocked at the effectiveness and various advantages of coding in Go, I wonder why Google never adopted Erlang. They could have been getting all these same advantages (and then some) a decade ago :)

> You know, every time I see some Googler shocked at the effectiveness and various advantages of coding in Go

Me too, but for other reasons.

Many of the Go nice features were already available in other languages back in the 80's and got lost with C and later C++ becoming mainstream.

That normal developers don't know them is understandable, but Googlers, given the requirements to be part of the Chocolate Factory, it surprises me every time.

Re: Rewriting a large production system in Go

#184

Post by banachtarski »

continuations wrote: post #28
derefr wrote: post #6

You know, every time I see some Googler shocked at the effectiveness and various advantages of coding in Go, I wonder why Google never adopted Erlang. They could have been getting all these same advantages (and then some) a decade ago :)

The author did say CPU efficiency is key, and Erlang isn't exactly known for its raw speed. In general search is very CPU intensive, maybe that's why Google never adopted Erlang.

Yes but intentionally so. There is an intrinsic tension between latency and throughput. Erlang chooses willfully to optimize for the former rather than the latter. This works when the majority of the tasks occurring concurrently are typically small and lightweight (aka, a web server).

Re: Rewriting a large production system in Go

#185

Post by banachtarski »

packetslave wrote: post #64
derefr wrote: post #52

Earlier quoted context omitted.

"Exotic tech" is the most amusing ad-hominem insult I've heard in a while. Erlang has more users than Go, at least, and more companies you could name off the top of your head have Erlang deployed somewhere (Github and Heroku, for just two.) Also, Google doesn't have "unique requirements." They have a unique set of overlapping, pretty common requirements. Some requirements in that set (e.g. serving data on dl.google.c…

I would say Google has a couple of fairly uncommon requirements: ridiculous scale and the fact that even a brief outage is world news. In terms of "rewriting all this software", I wouldn't say it's at all for the sake of switching to Go. It would be more accurate to say "well, we need to rewrite this thing anyway because it's no longer scalable or maintainable. Let's give Go a shot instead of C++/Java)"

Scale in and of itself isn't the basis of a sufficient argument though. You can write software at that scale in Visual Basic if you have billions of hexcore machines at your disposal.

Re: Rewriting a large production system in Go

#186

Post by banachtarski »

pmahoney wrote: post #167
derefr wrote: post #87

Earlier quoted context omitted.

> As for changes that are backward incompatible, you can still manage them with application level techniques, such as rolling out servers or simply allow two different versions of the class to exist at the same time (JRebel does that, as do other a few other products in the JVM ecosystem). Neither of these allow for the whole reason Erlang has hot code upgrade in the first place: allowing to upgrade the code on one s…

Tomcat (and other app servers) has support for doing hot reloads of Java web apps while not reloading the HTTP layer (and not dropping TCP connections). http://www.javacodegeeks.com/2011/06/zero-downtime-deploymen... I have implemented a similar system for JRuby apps running inside a Servlet container. There are many caveats. I don't actually recommend it because for a while you're using nearly twice the memory (and…

Erlang is not in that boat. Generally, you can upgrade the entire thing (except the lowest level libraries obviously) without too much fuss.

Re: Rewriting a large production system in Go

#187

Post by banachtarski »

lenkite wrote: post #171
derefr wrote: post #87

Earlier quoted context omitted.

> As for changes that are backward incompatible, you can still manage them with application level techniques, such as rolling out servers or simply allow two different versions of the class to exist at the same time (JRebel does that, as do other a few other products in the JVM ecosystem). Neither of these allow for the whole reason Erlang has hot code upgrade in the first place: allowing to upgrade the code on one s…

Out of curiosity, where/why would such an exotic feature be needed in today's internet architectures where you always front a group of servers with a load balancer ?

Not everything is a website! Also, not everything is stateless. Consider writing a chat application for the web for example and letting users on one page communicate with another one.

Re: Rewriting a large production system in Go

#188

Post by banachtarski »

zaphar wrote: post #49
derefr wrote: post #6

You know, every time I see some Googler shocked at the effectiveness and various advantages of coding in Go, I wonder why Google never adopted Erlang. They could have been getting all these same advantages (and then some) a decade ago :)

(full disclosure: I work at google and also like erlang) Erlang has fantastic facilities for robustness and concurrency. What it does not have is type safety and it's terrible at handling text in a performant fashion. So if you don't care about either of those things and only care about robustness and concurrency then Erlang is great. There were internal discussions about Erlang here but the upshot was. We had alread…

Benefits in "performance" is somewhat vague. What performance criteria was measured? Throughput? Memory consumption? Latency? Long tails? Standard deviation? Mean response time?

It's highly unlikely that any language can possibly provide all the above and Erlang makes certain tradeoffs (as does Go). Low level languages like C++ let the user choose the tradeoff at any given point with enough effort.

What was Google's criteria in making such a decision?

Re: Rewriting a large production system in Go

#189

Post by dubbledidu »

freyr wrote: post #181
dubbledidu wrote: post #177

Earlier quoted context omitted.

Yet another Go fanboy getting a bit defensive without having to add anything constructive? If you actually checked your “claims” you would see that people are singing so many praises that the mailing list is continually filled with proposals to fix the worst parts of Go's packaging system.

Your post has no substance, other than to say some people on the mailing list don't like it. But other people on the mailing list do like it. So your post is meaningless and useless. If you actually have problems with Go's packaging, and care about it enough to write as much as you have, why didn't you simply point out the flaws?

  > So your post is meaningless and useless.
Can I hand you some tissue so that you can get rid of your angry tears? That Go reality distortion field seems to be strong.

  > why didn't you simply point out the flaws?
Because there are already dozens of people who did that already?

Re: Rewriting a large production system in Go

#190

Post by freyr »

dubbledidu wrote: post #189
freyr wrote: post #181

Earlier quoted context omitted.

Your post has no substance, other than to say some people on the mailing list don't like it. But other people on the mailing list do like it. So your post is meaningless and useless. If you actually have problems with Go's packaging, and care about it enough to write as much as you have, why didn't you simply point out the flaws?

> So your post is meaningless and useless. Can I hand you some tissue so that you can get rid of your angry tears? That Go reality distortion field seems to be strong. > why didn't you simply point out the flaws? Because there are already dozens of people who did that already?

> Because there are already dozens of people who did that already?

Do you really expect people to scour a newsgroup to find the meaning of your vague and unsubstantiated claims?

Someone could similarly say "Scala is an unmitigated failure of a language. If you want to know why, just track down its detractors on the Internet. There are dozens." Would you be impressed by that?

Post reply on HN