How We Went from 30 Servers to 2: Go • Hacker News Board

Re: How We Went from 30 Servers to 2: Go

#291

Post by qznc » Wed, Mar 13, 2013, 6:53 AM UTC

cpprototypes wrote: post #108

memset wrote: post #57

Earlier quoted context omitted.

I agree with the premise that, as a professional software engineer, it is my responsibility to be a polyglot. As for myself, when I started writing Python, I mainly wrote C or Java code in Python - in a similar way, perhaps, how early C programs were littered with __asm__() constructs. It took a long time to learn how to write things in (though I hate the term) a "pythonic" way. That is, to learn the common language…

I agree, but I think the age of the language and community is another factor. Java, Python, C++, these are all old languages with decades of history and habits. Newer things like Node.js and Go have no history, no baggage to learn or avoid. I think starting in something with such a clean slate is somewhat easier because there is less ecosystem to learn.

I once heard a quote like this "programming languages are frozen knowledge about software engineering". (Anybody got a clue who said something like this?)

New languages usually improve upon older languages by making certain errors impossible by design. For example, Go allows pointers, but not pointer arithmetic. With C we learned pointer arithmetic is often harmful (though sometimes necessary), so Java removed pointers from the language (not completely, though). Go takes a sensible middle way, because no pointers sometimes is ugly. Such a clean slate is good, because with older languages programmers fight their language deficiencies with habits (e.g. if (5 == x) instead of if (x == 5) to prevent if (x = 5)).

On the other hand, we will find the pitfalls and dark corners of Go over time, but currently we do not know them enough. Go will acquire its own conventions, but we do not know all of them yet. This is the risk of a clean slate.

Re: How We Went from 30 Servers to 2: Go

#292

Post by gnuvince » Wed, Mar 13, 2013, 6:56 AM UTC

f2f wrote: post #288

gnuvince wrote: post #180

Earlier quoted context omitted.

Go's lack of type parametrisation makes many higher order functions really awkward. I'm no expert on Go, but below is my attempt at writing a generic Map function. As you can see, the code of the Map function itself isn't so bad (though there's a lot of noise in the declaration). Using that function however is really annoying, as you need to convert from the slice you have ([]string, []int, etc.) to an empty interfac…

Here's a more idiomatic go version: http://play.golang.org/p/oH850AdLuQ what you don't realize (apart from the fact that go doesn't terminate lines with semicolons since 2009) is that you don't need to create a copy that's typed []interface{} because []X already satisfies interface{} and you can use reflection to handle it. if a seasoned Go programmer wanted to write a somewhat generic map function they'd do somethin…

In your more idiomatic version, you actually went ahead and changed the declaration of words to be []interface{}, but you may not be in control of the type of words (for instance if it's the return value of a function). This is why I did the explicit conversion. As for the reflection, it's pretty ugly.

Also, what about semi-colons?

Re: How We Went from 30 Servers to 2: Go

#293

Post by pestaa » Wed, Mar 13, 2013, 6:57 AM UTC

burntsushi wrote: post #273

trungonnews wrote: post #232

Earlier quoted context omitted.

A seasoned Java developer is expected to have worked with one of the mainstream ORM like Hibernate or Ebean. But a Go developer gets away with not having to know an ORM because there is no mainstream ORM in Go. :)

So what, the lack of a mainstream ORM implies "So there is really nothing to learn besides the language itself"? I don't think so. And there's probably more to a lack of an ORM other than "Go is immature." It's a fairly common opinion among the Go community that ORMs are not worth their complexity. I tend to share that opinion myself, after having worked with a few in a couple different languages.

Not sure why you were downvoted, I tend to agree ORMs are not the best ways to communicate with databases.

As to only the lack of ORM would make Go immature? Honestly I don't know. There are tons of software written in JavaScript; do they make JavaScript mature? Hell no.

Re: How We Went from 30 Servers to 2: Go

#294

Post by qznc » Wed, Mar 13, 2013, 7:01 AM UTC

trungonnews wrote: post #260

yannk wrote: post #248

Earlier quoted context omitted.

tl;dr: I tried Go, but it wasn't like Ruby, so now I'm trying Scala.

Ha. Is there a high performance, compiled, and concurrent friendly language that looks like Ruby? Please share. :)

Looks like Ruby? You mean syntactically like "end" instead of "}", I assume.

Sorry, but the C syntax is dominating the native-compiled world. You could try Pascal, they have "end". Or use C with preprocessor magic:

  #define END     ;}

If you mean Ruby like terse, generic code, then try Rust, Go, and D.

Re: How We Went from 30 Servers to 2: Go

#295

Post by lysium » Wed, Mar 13, 2013, 7:03 AM UTC

burntsushi wrote: post #275

desireco42 wrote: post #272

I went briefly to through the comments, it seems that no-one is bothered with lack of details in this post, things are not logical at all, almost like it was written by PR agency in charge of promoting Go. Except it is established business so I would assume things are true, but real motives are hidden. Go is obviously good language for some specific things, but it's not like ruby is pure trash, how come you did 'ever…

> but real motives are hidden Could you elaborate on this please? Are you referring to the OP's motives of publishing the article? Or of switching to Go? > Go and Rails are so different that there is almost no point in comparing them. Except when one solves the same problem better than the other.

- They did not say why they did not choose one of the other alternatives.

- They did not say how they used the concurrent features of Go, only mentioned that they were there.

- They did not say how long it took to rewrite.

- They did not say what they changed in the API.

I'm not saying the story isn't true, but for a true story it lacks a lot. You could summarize the article with the title and you won't be missing much.

Re: How We Went from 30 Servers to 2: Go

#296

Post by f2f » Wed, Mar 13, 2013, 7:05 AM UTC

gnuvince wrote: post #292

f2f wrote: post #288

Earlier quoted context omitted.

Here's a more idiomatic go version: http://play.golang.org/p/oH850AdLuQ what you don't realize (apart from the fact that go doesn't terminate lines with semicolons since 2009) is that you don't need to create a copy that's typed []interface{} because []X already satisfies interface{} and you can use reflection to handle it. if a seasoned Go programmer wanted to write a somewhat generic map function they'd do somethin…

In your more idiomatic version, you actually went ahead and changed the declaration of words to be []interface{}, but you may not be in control of the type of words (for instance if it's the return value of a function). This is why I did the explicit conversion. As for the reflection, it's pretty ugly. Also, what about semi-colons?

i understand why you did the explicit conversion, the idea i was trying to relay is why i undid it...

nevermind the semicolons, 'twas a joke :)

Re: How We Went from 30 Servers to 2: Go

#297

Post by qznc » Wed, Mar 13, 2013, 7:07 AM UTC

orangethirty wrote: post #38

What changed in the architecture? It is rather interesting that by just having a language change you could remove 28 servers from the system.

I chuckled at "just a language change".

What could be more expensive than rewriting all you code? For many Rails web apps the cost of additional servers is far below the cost to rewrite things in Go.

Re: How We Went from 30 Servers to 2: Go

#298

Post by danielbarla » Wed, Mar 13, 2013, 7:13 AM UTC

shurcooL wrote: post #20

> "We also weren't sure if we would be able hire top talent if we chose Go, but we soon found out that we could get top talent because we chose Go." I feel[1] that a smart/talented C/C++/anything developer can go from someone who has never seen or heard of golang to a proficient and productive Go developer in a matter of a few weeks, maybe even _days_, if not less. That's how long it takes to go through the following…

Re [1]: I think that's a reasonable statement. My issue with it, however, is that after just a few weeks (or even a few months), said developer might still not know about various design pitfalls or best practices in the new language.

In short, they might not be writing idiomatic code, and you'll end up maintaining it for a long time. IMHO, becoming basically proficient with a language is very different to being able to create software which will scale well to large teams, while also aging gracefully over time.

Re: How We Went from 30 Servers to 2: Go

#299

Post by fauigerzigerk » Wed, Mar 13, 2013, 7:15 AM UTC

neya wrote: post #280

It's funny that they argue that they dumped the JVM derivatives like Scala, but wouldn't exactly tell why, nor support their argument with any sort of data/logs. I am genuinely curious to know why they chose Go over Scala. If it was the syntax, etc. I can partially agree because it's one of scala's weak points, but then they pitch the main reason citing performance, so I'm genuinely curious to know.

He mentions JVM memory usage.

Re: How We Went from 30 Servers to 2: Go

#300

Post by ramchip » Wed, Mar 13, 2013, 7:20 AM UTC

TillE wrote: post #30

shurcooL wrote: post #20

> "We also weren't sure if we would be able hire top talent if we chose Go, but we soon found out that we could get top talent because we chose Go." I feel[1] that a smart/talented C/C++/anything developer can go from someone who has never seen or heard of golang to a proficient and productive Go developer in a matter of a few weeks, maybe even _days_, if not less. That's how long it takes to go through the following…

It's quite strange to me that people would identify as or look for a "[language] programmer". Sure, I happen to write more C++, Python, and C than anything else, but I've dabbled in just about everything and could reach comfortable proficiency in a matter of weeks. Most of programming and all of computer science is universal. Any serious programmer should be a polyglot by default.

Generally I don't understand "C++ programmer" to mean a programmer who is an expert in C++, and C++ only, but rather a programmer who may be comfortable in many languages but has a special expertise in C++. All my team identifies as C++ programmers, but we all speak Python and Java, and some can do Haskell, etc.

It takes a long time to become really good at C++.