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

101–110 of 196 posts

Re: Rewriting a large production system in Go

#101

Post by EdiX »

seiji wrote: post #55
cageface wrote: post #46

Earlier quoted context omitted.

Google is heavily dependent on Java, Linux, Python, C++ etc. About two seconds of thought is all it takes to realize what an absurd claim this is. Google is almost alone in building internet services at its scale. The people calling for adoption of exotic tech like Erlang without understanding their unique requirements are the fadsters.

Well, they wrote their own infringing java VM for mobile, tried to fix Python (but it didn't work out), essentially run Google Linux internally with various levels of contribution back upstream, and their C++ is (I'm just guessing here) nigh unreadable by non-übernerds.

> their C++ is (I'm just guessing here) nigh unreadable by non-übernerds.

Judging by their coding guidelines the C++ they use is a smallish subset of the full C++ language hence very bearable.

Re: Rewriting a large production system in Go

#102

Post by RyanZAG »

pjmlp wrote: post #94
jff wrote: post #79

Earlier quoted context omitted.

Everybody talks about using C++ for efficiency, but the way most people end up writing C++? Not very efficient.

Because many try to write C in C++, instead of learning how to do it properly.

I think you'd have to agree that C++ does not make it easy to learn how to do it properly, and nor does it make it easy to actually do it properly. Go at least makes it far easier for most programmers to do an acceptable job which has to count for something.

Re: Rewriting a large production system in Go

#103

Post by onan_barbarian »

f2f wrote: post #90
onan_barbarian wrote: post #77

Earlier quoted context omitted.

Hmmn. I think there's a fundamental advantage in any rewrite that's allowed to drop functionality - even a C++ to C++ rewrite. It's not just the language. It's the fact that (a) you already have an instantiation of the idea to look at as a reference and (b) you're happily cutting bits off the original. The latter suggests that you're not only not supporting all of the original use cases, you're probably in a nice sta…

ironically, that's not the common experience; the term 'second system syndrome' was coined for a reason. "allowed to drop functionality", as used by you, is a strawman -- the team _added_ functionality to the part they were rewriting without incurring the wrath of the second system. sure, the line counts are off, but your argument does not stand in the general.

If I remember Brooks correctly, second system syndrome does not refer to all successor systems, and frequently complex/over-built systems spawn elegant ones in turn (oversimplifying a bit, but MULTICS -> UNIX springs to mind). I seem to recall Brooks regarding this as cyclical, with leaner third systems spawning bloated fourth systems, and so on.

Re: Rewriting a large production system in Go

#104

Post by marshray »

pjmlp wrote: post #95
marshray wrote: post #71

Earlier quoted context omitted.

Wrote an "infringing Java VM" now did they? Did you actually read the court's ruling on that?

I did, and to be honest it is not much different than Microsoft with Visual J++. Without the "Google is cool glasses" on, I came to the conclusion that Google just took enough care to avoid all the legal traps that could make them loose a suit like it happened to Microsoft.

Disclosure: I work for Microsoft but that is a very new thing (the J++ dispute was many years ago)

IIRC, the J++ suit had to do with the specific terms of a license agreement that Sun and Microsoft had entered into. I don't think it was much like this where Google claimed to have done a non-infringing clean-room reimplementation claiming this didn't require a license from Sun/Oracle at all.

Re: Rewriting a large production system in Go

#105

Post by cageface »

pjmlp wrote: post #95
marshray wrote: post #71

Earlier quoted context omitted.

Wrote an "infringing Java VM" now did they? Did you actually read the court's ruling on that?

I did, and to be honest it is not much different than Microsoft with Visual J++. Without the "Google is cool glasses" on, I came to the conclusion that Google just took enough care to avoid all the legal traps that could make them loose a suit like it happened to Microsoft.

The president of Sun himself praised Google's Dalvik initiative. What legal trap were they trying to avoid here?

http://www.techdirt.com/articles/20110724/11263315224/oracle...

Re: Rewriting a large production system in Go

#106

Post by f2f »

pcwalton wrote: post #97
f2f wrote: post #91

Earlier quoted context omitted.

it wasn't accidental -- it was written on purpose by a programmer (a conversion from Writer to WriteCloser). it was immediately acknowledged as an error and eventually may be caught by the standard code examining tool "vet".

What would the static analysis that "vet" is performing enforce to stop this? No interface-to-interface downcasts?

eventually, within the context of the `go vet` tool, the http://godoc.org/code.google.com/p/go.tools/go/types package may be used to analyze interface conversions ("I said I expected interface type A, but I'm using it as interface type B", which is unusual for go programs). i think that answers "yes" to your second question, but I'm not on the go team, so take my opinion with a grain of salt.

short of disallowing interface-to-interface casts, it is indicative of an error and should be vetted as such. the particular case I described earlier was covered by the Go 1.0 guarantee, so it had to be documented rather than fixed.

Re: Rewriting a large production system in Go

#107

Post by chetanahuja »

seiji wrote: post #55
cageface wrote: post #46

Earlier quoted context omitted.

Google is heavily dependent on Java, Linux, Python, C++ etc. About two seconds of thought is all it takes to realize what an absurd claim this is. Google is almost alone in building internet services at its scale. The people calling for adoption of exotic tech like Erlang without understanding their unique requirements are the fadsters.

Well, they wrote their own infringing java VM for mobile, tried to fix Python (but it didn't work out), essentially run Google Linux internally with various levels of contribution back upstream, and their C++ is (I'm just guessing here) nigh unreadable by non-übernerds.

"and their C++ is (I'm just guessing here) nigh unreadable by non-übernerds."

Actually google C++ codebase is some of the most carefully written and extensively commented codebase I've ever had the pleasure to work on. Of course a large amount of google C++ codebase is open source (Chromium, leveldb etc.) and you're free to read it and form informed opinions instead of guessing.

Re: Rewriting a large production system in Go

#108

Post by f2f »

onan_barbarian wrote: post #103
f2f wrote: post #90

Earlier quoted context omitted.

ironically, that's not the common experience; the term 'second system syndrome' was coined for a reason. "allowed to drop functionality", as used by you, is a strawman -- the team _added_ functionality to the part they were rewriting without incurring the wrath of the second system. sure, the line counts are off, but your argument does not stand in the general.

If I remember Brooks correctly, second system syndrome does not refer to all successor systems, and frequently complex/over-built systems spawn elegant ones in turn (oversimplifying a bit, but MULTICS -> UNIX springs to mind). I seem to recall Brooks regarding this as cyclical, with leaner third systems spawning bloated fourth systems, and so on.

i was referring to recent examples such as python 3.0, perl 6, or even, say, apache 2.0. eventually they were usable, but the blood sweat and tears involved did not make for cute blog posts such as the one we're commenting on.

Re: Rewriting a large production system in Go

#109

Post by pjmlp »

RyanZAG wrote: post #102
pjmlp wrote: post #94

Earlier quoted context omitted.

Because many try to write C in C++, instead of learning how to do it properly.

I think you'd have to agree that C++ does not make it easy to learn how to do it properly, and nor does it make it easy to actually do it properly. Go at least makes it far easier for most programmers to do an acceptable job which has to count for something.

> I think you'd have to agree that C++ does not make it easy to learn how to do it properly, and nor does it make it easy to actually do it properly.

I know C++ since 1993. Having used it alongside many other programming languages and followed quite closely the standardization process in "The C++ Report" and "The C Users Journal", latter named "The C/C++ Users Journal".

I only used C instead of C++ when forced to do so.

Yes it is a complex language, requiring a good background in programming languages to use it properly, but so are quite a few other languages that provide a similar set of abstractions.

> Go at least makes it far easier for most programmers to do an acceptable job which has to count for something.

True, although in a similar way as Java 1.0 was a better C++, however we are no longer in 1995.

Re: Rewriting a large production system in Go

#110

Post by gizzlon »

dodyg wrote: post #39
lbarrow wrote: post #11

It's interesting to see that more and more internal projects at Google are getting redone in Go. However, this sentence stands out to me in the article: "Before doing the rewrite, we realized we needed only a small subset of the functionality of the original system -- perhaps 20% (or less) of what the other projects were doing with it." I'm guessing that a lot of the benefit of the rewrite came simply from the simpli…

This is why a "go" rewrite story is not that appealing to me. You can rewrite a subset of a system and gain many improvements simply by benefits of hindsight and clearer requirements regardless of languages.

Obviously, but the author is smart enough to acknowledge this and take it into consideration. So.. what's your point?
Post reply on HN