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

131–140 of 196 posts

Re: Rewriting a large production system in Go

#131

Post by fauigerzigerk »

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.

Why guess if you can look for yourself? Here's the Chromium source for instance: http://src.chromium.org/viewvc/chrome/trunk/src/ In my opinion, Google's C++ code is exceptionally readable.

Re: Rewriting a large production system in Go

#132

Post by JulianMorrison »

azth wrote: post #118
mdwelsh wrote: post #36

Earlier quoted context omitted.

OP here. What do you think we should be using apart from C++ or Java?

Scala. Rust also looks extremely promising, though not mature yet. It is getting there quickly though.

If you use Scala in a way that has not a whole lot of extra cognitive load, it's a slightly prettier re-skin of Java. If you use it like it's Haskell, it has a cognitive load that's as bad as Haskell (or worse). And if you inherit a codebase from someone else, you can bet they've been tempted to be oh-so-clever. That's why I'd never let Scala near production.

Go has almost no cognitive load beyond the complexity of the algorithm itself.

Re: Rewriting a large production system in Go

#133

Post by szalansky »

pjmlp wrote: post #124
Tichy wrote: post #115

Earlier quoted context omitted.

Sometimes less is more. Not implementing every fancy feature under the sun might be a bonus and keeps the language clean. I know I never managed to like generics in Java. Don't know C#, though.

Java generics are an example on how not to do it, but it does not mean all generic implementations are like Java's.

Hope you write some further explanation for your statement, because so far it looks like part of this c++ vs. java flame.

Re: Rewriting a large production system in Go

#135

Post by JulianMorrison »

mdwelsh wrote: post #34
zzzeek wrote: post #2

> If I could get out of the 1970s and use an editor other than vi, maybe I would get some help from an IDE in this regard, but I staunchly refuse to edit code with any tool that requires using a mouse. So you've shown that Go is appealing to rigid curmudgeons. Personally I'm still hung up on the "every function (edit: that does anything which might itself return an error code, which in large scale code is quite a lot…

The joke goes, "If every other line of code you write starts with 'if err != nil', you might be a Go programmer."

No, we can just see the "if err != nil". It's still there in Java or Ruby or Python, lurking in the notional space between the lines and waiting to branch to an exception handler you installed in the caller's caller's caller.

Re: Rewriting a large production system in Go

#136

Post by jesstaa »

sytelus wrote: post #86

The number of strongly typed garbage collected compiled languages is surely shrinking. I can understand someone's disgust towards Java considering dwindling velocity in adding next-gen features and now sleeping in same bed as lawyer run Oracle. That pretty much had left C# in the arena until Go came on the scene. I was honestly hoping Go would give us head-to-head battle with C# but from initial looks Go pretty much…

The C# and the Go cultures are very different. Culture is a big part of what makes programming languages different. Python and Ruby are basically the same language, but the culture of the users is very different and so the libraries and tool are quite different.

Go is from the unixy C culture, C# is from the Java/win32 culture and the libraries and tools reflect that.

Re: Rewriting a large production system in Go

#137

Post by pjmlp »

szalansky wrote: post #133
pjmlp wrote: post #124

Earlier quoted context omitted.

Java generics are an example on how not to do it, but it does not mean all generic implementations are like Java's.

Hope you write some further explanation for your statement, because so far it looks like part of this c++ vs. java flame.

- Type erasure. Going the .NET way would be a better approach on my opinion;

- Lack of type definitions. If it was possible to declare types in Java, the generic declarations wouldn't need to be so monstrous;

- The common co-variance/contra-variance issues with the generic types;

- Lack of support for builtins;

- No way to specialize generic algorithms for specific types

Re: Rewriting a large production system in Go

#138

Post by Nitramp »

sytelus wrote: post #86

The number of strongly typed garbage collected compiled languages is surely shrinking. I can understand someone's disgust towards Java considering dwindling velocity in adding next-gen features and now sleeping in same bed as lawyer run Oracle. That pretty much had left C# in the arena until Go came on the scene. I was honestly hoping Go would give us head-to-head battle with C# but from initial looks Go pretty much…

I'd take a second look at Go. It has a number of innovations over C# - and of course also a number of shortcomings. It's quite a different language, much more so than Java compared to C# (1.0 even).

A couple of things of the top of my head:

    * goroutines and efficient multithreading, both in terms of syntactical constructs and language implementation. Go doesn't have await/async because it fundamentally doesn't need them.
    * a type system that works without inheritance or subtypes but rather static duck typing, quite different from any other language
    * very memory efficient layout of data structures, internal pointers
    * small set of builtins with maps, slices, channels (that do have 'generic' types for their members) to reuse, rather than re-implement
    * comes with a well designed build and packaging system
    * comes with a very convincing standard library
It's worth taking a look. C# surely is a nice language, but it inherited many of the design flaws of Java, in particular with respect to the runtime and memory layout. Google does use Java internally a lot, Go gets uptake in spite of that competition.

Regardless of language merits, licensing C# can indeed be a problem, as can be the operational complexity of managing Windows running on hundreds, thousands, ten thousands etc of machines.

Re: Rewriting a large production system in Go

#139

Post by lifebeyondfife »

mdwelsh wrote: post #44
grannyg00se wrote: post #41

"So given code like: foo, bar := someFunc(baz) You'd really like to know what foo and bar actually are" Wouldn't your editor, mouseless though it may be, provide for that? Does ctags not work with vi? And why use vi over vim?

OP here. I do actually use vim but I have yet to adopt most of the fancy plugins that vim provides -- put me in a time machine back to 1977 and I would be very capable of programming on any UNIX system that you'd drop me in front of, provided it had vi installed. I'm not defending this choice of lifestyle; it's just how I learned to program :-)

Even in the 2010s I've found proponents of the UNIX console style of programming because, as you say, they can be dropped in front of any similar system and off they go.

However, tools improve and you're denying yourself productivity benefits. One of the advantages of a statically typed language is that the computer knows the type of the arguments. I love environments that allow me to 'mouse over' a function or variable etc. and tell me exactly what it is (and allow me to navigate to its definition). You don't have to use a mouse but what's the disadvantage in having alternatives to keyboard shortcuts where appropriate?

Re: Rewriting a large production system in Go

#140

Post by bane »

npalli wrote: post #32
bane wrote: post #30

> So programming in Go is making me soft. Something similar happened to me years ago when I started picking up Perl. All the BS C++ and Java made me go through to get anything done seemed like such a huge waste of time I ended just writing lots of stuff in Perl until I had pretty much forgotten how to C++ and how to Java. Go might be a new Perl in that sense. I'd also add that as Google moves more and more production…

"For each system that Google brings on-line with Go, even if it took a team of 10 6 months, they've likely saved themselves millions of dollars in new capex infrastructure acquisition" I thought the old systems were in c++. So, how did the infrastructure savings accrue? In fact, I don't recall anyone doing analysis on that front.

You're right. I think I got ahead of myself in what I was thinking, conflating the rewrite of the C++ system into Go with the some of the other speedups I've been reading about coming from other languages/frameworks.

I'd be interested to know more from Matt about speedups or slowdowns in specific subsystems that are feature-for-feature complete (as opposed to comparisons of Go to C++ where the Go rewrite is simply doing less stuff because lots of cruft was tossed out).

Post reply on HN