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

111–120 of 196 posts

Re: Rewriting a large production system in Go

#111

Post by pjmlp »

marshray wrote: post #104
pjmlp wrote: post #95

Earlier quoted context omitted.

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.

Yes, this is what I mean by taking care.

Google did a clean room implementation, while making a clear distinction between Java the language and Java the VM, while avoiding doing any kind of public statement that could violate the Java licensing trademark.

So now you have an environment, where Java the language version 6 can be used, while Java the language version 8 is going to appear next year, without any signs of ever appearing in Android.

Now, quite possibly as consequence of the litigation, Java developers targeting Android have to live with Java the language version 6 forever.

The end result is no different than the fragmentation Microsoft attempted with J++, but since it is Google, it is ok to do so.

Re: Rewriting a large production system in Go

#112

Post by stock_toaster »

f2f wrote: post #108
onan_barbarian wrote: post #103

Earlier quoted context omitted.

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.

I think a component in a service oriented architecture would lend itself more cleanly to reimplementation, with less chance for "Second System Syndrome", because you still have an api contract you are responsible for.

I think a "released" software, like those you mentioned, would be somewhat more likely to become a stereotypical "second system".

Re: Rewriting a large production system in Go

#113

Post by rdtsc »

AYBABTME wrote: post #50
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 :)

When people ask «Why not Erlang instead of Go, Erlang is X and Y and Z...» they seem to be oblivious to the fact that Go is C-like and Erlang has a pretty weird Prolog-like syntax. I've had some experience with Prolog before touching any Erlang. It's not a syntax or a programming style that I liked, not at all. When I came to do some Erlang [1], I found the same style and it was not a pleasant surprise. I learned C-l…

> they seem to be oblivious to the fact that Go is C-like and Erlang has a pretty weird Prolog-like syntax.

Yeah it has Prolog-like syntax. However, when designing and working on large distributed system looking at just the syntax is a kind of shortsighted. The problem is not syntax (which is different, and is actually pretty simple, and a lot less ambiguous than say Javascript or has less "features" than C++), the problem is _semantics_. And by that I mean structuring your programs as a set of multiple concurrent actors. That is the hard part.

Another way to put it. Erlang is probably getting looked at because someone wants to either scale, build a distributed system or a highly fault tolerant system. At that point, if dots vs semicolons is a major stumbling block what are they going to do when they hit a netsplit.

Now, Erlang like any tool has trade-offs. But those are about isolation and private heaps vs raw sequential performance. Hot code upgrades and compiled static code and pointers referenced everywhere in the code is not going to work well. Stuff like that. Single assignment is also another common one.

(And if syntax is a major stumbling block, there is Elixir or a lisp like languages LFE and Joxa that all take advantage of the actor model and run on the BEAM VM).

Re: Rewriting a large production system in Go

#114

Post by rdtsc »

laureny wrote: post #80
derefr wrote: post #63

Earlier quoted context omitted.

Interesting, thanks for that; it's pretty much what I guessed (especially the bit about the supervision tree and hot-code-upgrade advantages being mooted by your infrastructure.) On a tangent, though: > What it does not have is type safety I've tried to work this out before (I'm designing a new language for Erlang's VM), but as far as I can tell, type safety is in practice incompatible with VM-supported hot code upgr…

> type safety is in practice incompatible with VM-supported hot code upgrade. That's not true. First, it's very easy to hot reload changes that have been made to the code that are backward compatible. The JVM spec describes in very specific details what that means (adding or removing a method is not backward compatible, modifying a body is, etc...). This is how Hotswap works, the JVM has been using it for years. As f…

> lack of static typing is a deal breaker for pretty much any serious production deployment.

Are you talking about Google only where they made it a mandate or in general? There are serious production deployments on Python, Ruby, Erlang and Javascript.

I will trade expressiveness and less lines of code with a strong but dynamically typed language + tests over more a static typed language with more lines of code all being equal.

Or put it another way, if strong typing is the main thing that protects against lack of faults and crashes in production, there is a serious issue that needs to be addressed (just my 2 cents).

Re: Rewriting a large production system in Go

#115

Post by Tichy »

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…

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.

Re: Rewriting a large production system in Go

#116

Post by michaelwww »

pjmlp wrote: post #111
marshray wrote: post #104

Earlier quoted context omitted.

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.

Yes, this is what I mean by taking care. Google did a clean room implementation, while making a clear distinction between Java the language and Java the VM , while avoiding doing any kind of public statement that could violate the Java licensing trademark. So now you have an environment, where Java the language version 6 can be used, while Java the language version 8 is going to appear next year, without any signs of…

> Now, quite possibly as consequence of the litigation, Java developers targeting Android have to live with Java the language version 6 forever.

I suspect this was one of the motivations behind Dart.

Re: Rewriting a large production system in Go

#118

Post by azth »

mdwelsh wrote: post #36
kailuowang wrote: post #15

It disheartens me a bit when people compare Go with C++. It gave me the impression that Go was created to be better C++ (or Java) mostly to make life easier for the thousands of developers at Google who are stuck with those two languages.

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.

Re: Rewriting a large production system in Go

#119

Post by threeseed »

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…

Java as a platform is absolutely not dwindling in velocity. All that is happening is people are looking into alternative JVM languages like Scala, Clojure and Groovy. This trend has been happening for a while and is as much to do with Servlets/Spring as it is with Java the language. It has absolutely nothing to do with Oracle which has been a fantastic steward for the platform.

I don't think you actually have much understanding of enterprise environments otherwise you would know how ridiculous the idea that Go or C# is going to take over from Java anytime soon.

Re: Rewriting a large production system in Go

#120

Post by coldtea »

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.

>ironically, that's not the common experience; the term 'second system syndrome' was coined for a reason.

And the reason was overly ambitious rewrites of huge and complex codebases.

For simpler stuff and especially when cutting down on feature bloat, rewriting is fine.

There's a phrase about rewrites, by the same guy that coined the "second system syndrome": "plan to throw one away".

Post reply on HN