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

171–180 of 196 posts

Re: Rewriting a large production system in Go

#171

Post by lenkite »

derefr wrote: post #87
laureny wrote: post #80

Earlier quoted context omitted.

> 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…

> 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 ?

Re: Rewriting a large production system in Go

#172

Post by [deleted] »

dubbledidu wrote: post #156
jawr wrote: post #150

Earlier quoted context omitted.

Would you care to elaborate on this?

* Their implementation sucks so much that most decently built concurrency implementation will beat Go-routines by a wide margin. Just have a look at all those people on the Go mailing list whining about the scheduler. Not even talking about the fact that building concurrency mechanisms into the language is plain stupid. We all saw how well that worked out in plenty of other languages before. * You know why pretty muc…

[deleted]

Re: Rewriting a large production system in Go

#173

Post by freyr »

icedchai wrote: post #170
dubbledidu wrote: post #156

Earlier quoted context omitted.

* Their implementation sucks so much that most decently built concurrency implementation will beat Go-routines by a wide margin. Just have a look at all those people on the Go mailing list whining about the scheduler. Not even talking about the fact that building concurrency mechanisms into the language is plain stupid. We all saw how well that worked out in plenty of other languages before. * You know why pretty muc…

I'm interested in more details on the packaging system issues. (The biggest problem I see is lack of versioning, but there must be more.)

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.

Re: Rewriting a large production system in Go

#174

Post by pjmlp »

scott_s wrote: post #149
pjmlp wrote: post #93

Earlier quoted context omitted.

Yep, Go would be hardly mentioned here if it wasn't being developed at Google. Having said this, Go can be a nice replacement for many use cases one would use C for.

Go seems to be gaining traction. Does it matter if that's because of where it came from? Maybe in a cultural, I-want-to-think-about-why-some-languages-get-adopted sense, sure, then it can matter. And I think it's worth having those discussions. But I get the impression that people think there's some absolute injustice in the idea that people are adopting a language, and it's partly because it's from Google. Consider:…

> "Yes, C would be hardly mentioned here if it wasn't being developed at Bell Labs."

Fully agree, most likely if UNIX hadn't been adopted at important American universities, C wouldn't have spread as it did.

Re: Rewriting a large production system in Go

#175

Post by cgag »

JulianMorrison wrote: post #132
azth wrote: post #118

Earlier quoted context omitted.

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 t…

It sounds to me like you're lumping things like writing for loops and mutating state in with the inherent complexity of the algorithm. I think reducing the ability to create abstractions like generic map/filter increases cognitive load. Reducing cognitive load is the whole reason I'm learning Haskell and currently use Clojure.

Re: Rewriting a large production system in Go

#176

Post by Tichy »

gnuvince wrote: post #163
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.

Languages like SML and OCaml are pretty clean, pretty simple and have an awesome parametric polymorphism system.

I'll put them on my "to be checked out" list.

Re: Rewriting a large production system in Go

#177

Post by dubbledidu »

freyr wrote: post #173
icedchai wrote: post #170

Earlier quoted context omitted.

I'm interested in more details on the packaging system issues. (The biggest problem I see is lack of versioning, but there must be more.)

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.

Re: Rewriting a large production system in Go

#179

Post by butterflyhug »

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 all Internet protocols are HTTP. If you're running a service where long-lived connections are the norm, "simply fronting a bunch of servers with a load balancer" can require a pretty smart load balancer. E.g. IMAP connections often last hours or even days, and are required to maintain a degree of statefulness.

Re: Rewriting a large production system in Go

#180

Post by ternaryoperator »

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.

Ken Thompson (a Go lead) has held hostility towards C++ that is well-known and of long standing. (To wit, at the ACM Turing Centennial last year: 'I'm not sure what OO is supposed to look like, but I do know for sure it's not anything like C++.' (not verbatim, but accurate in the sentiment he expressed.)) As note below, Go was indeed designed to address perceived shortcomings of C++, among other goals.
Post reply on HN