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

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

#311

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

trungonnews wrote: post #244

I was originally very excited about Go when I first learned about it. But then I got tired and frustrated quickly after having to listen to the other Gophers telling me that I don't need this or that feature because there is a better way to do it in Go. Like. I don't need exceptions because Go function can return multiple values. I don't need a mocking framework like Mockito because Go has interfaces. I don't need an…

Same thing happen to me, I even did some small contributions around 2010.

Then I discovered D and Rust are better languages for my purposes.

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

#312

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

bpicolo wrote: post #199

sabat wrote: post #157

Earlier quoted context omitted.

Not quite. He's saying that people who think Ruby is slow are often people who have no idea how to performance-tune it.

Well, more of the time it's because Ruby actually is, in fact, slow.

I though the implementations were slow or fast, not the languages.

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

#313

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

trungonnews wrote: post #244

I was originally very excited about Go when I first learned about it. But then I got tired and frustrated quickly after having to listen to the other Gophers telling me that I don't need this or that feature because there is a better way to do it in Go. Like. I don't need exceptions because Go function can return multiple values. I don't need a mocking framework like Mockito because Go has interfaces. I don't need an…

We also checked out both Go and Scala and picked Scala due to better IDE support (IntelliJ) and existing Java lib ecosystem. It also is typically faster than Go (but does use much more memory): http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

Overall very happy with our choice. I will probably learn Go too, but I also don't really like the way it does error handling and the tooling support seems limited vs what I can get for the JVM.

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

#314

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

rdtsc wrote: post #206

jaggederest wrote: post #153

Earlier quoted context omitted.

Ia, Ia, Erlang Ftagn! I agree though, I just wish that Go would have developed from Erlang as a runtime. The Erlang virtual machine and systems are beautiful things - I used them for some wire-level work on a project and bitfields are awesome, and it provided a clean interface to a more 'normal' language to display to the user, fail-fast fault tolerance on a public safety project, neat stuff. It's just erlang-the-pro…

> It's just erlang-the-programming-language that has all the Prolog warts that scares people, I think. I must be strange but I actually like Erlang's syntax. Its pattern matching is really hard to beat. Also with Erlang, it is not just about the language unless one just wants to learn academic FP or Actor model concepts -- it is about the framework. Debugging, tracing, distribution all those come as part of the packa…

Another one here... I like Erlang's syntax as well. Of course, we could have some things better (like record syntax), but it's really not bad at all.

I think most people have curly braces fetish (we call them "tits" at times where I work). If it doesn't have "tits", no thanks, it's ugly and bad.

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

#315

Post by masklinn » Wed, Mar 13, 2013, 7:54 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.

I got the same feeling from the odd dismissal of Erlang.

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

#316

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

jbooth wrote: post #221

timr wrote: post #215

Earlier quoted context omitted.

Not Invented Here syndrome goes away with general experience. It doesn't come back every time you switch to a new language. Just because I've never written Erlang doesn't mean that I will automatically try to write a random-number generator (say) the first time I need one in Erlang. I have enough experience to look for a library function first. Empirically, NIH tends to be more common in single-language developers, n…

I wasn't talking about NIH syndrome, I was talking about "I don't know that a common library exists for this standard use-case so I'm going to write my own one-off because I have a job to do". I mean, you can google for libraries but sometimes you just don't find them and then find out a few weeks later what you should have used.

Being a programmer is not about knowing everything. With experience one should be able to separate library functions that should always exist from those that are unique for each language. Everything else should just be a matter of information searching.

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

#317

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

jussij wrote: post #242

zobzu wrote: post #41

It's not really "go" that makes the difference. it's how the runtimes and frameworks are used and/or made. frameworks on top of frameworks, all being over engineered, with poor understanding of what the system actually does, result in super slow apps on top, that you generally go to aws to scale. It's not the first time that I see people reducing a dozen servers that were "always maxed out" by a couple of servers "th…

> It's not really "go" that makes the difference But from what I've seen and read about Go, it does seem to have things in it that do make a difference. For example from day one Go was designed for with concurrency in mind and that's a big plus. To see how this can help this Rob Pike video does a good job of showing off Go's version of concurrency: http://blog.golang.org/2013/01/concurrency-is-not-parallelis... Now,…

> But I've used a lot of languages and I never seen concurrency done as easily as shown in that video.

So I take it you never used Erlang.

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

#318

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

kamaal wrote: post #237

SomeCallMeTim wrote: post #223

Earlier quoted context omitted.

>Any serious programmer should be a polyglot by default. My own experience is that there are PLENTY of programmers who have used, say, PHP and Python, but who you wouldn't want to touch your C codebase in a pair-programming session. If you've used C++ and C, then sure, you can probably jump to just about any language. Someone who's only used Python (or worse, Java or PHP) will likely be a danger to themselves and oth…

Starting out with Python as a newbie is disastrous. I started out with assembly, then went to C and then all the C-family based languages. Non C-family languages are actually rare enough to neglect for 99% of all programming tasks today. Always remember going from something difficult to simple is easy, but going from something simple to difficult is not easy.

>Always remember going from something difficult to simple is easy, but going from something simple to difficult is not easy.

Great. There are plenty of hard working people to make this "piece of wisdom" completely worthless.

>Starting out with Python as a newbie is disastrous.

... why?

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

#319

Post by neya » Wed, Mar 13, 2013, 8:04 AM UTC

fauigerzigerk wrote: post #299

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.

I think he edited it after me and many other posted similar comments, coz I didn't notice it the first time...

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

#320

Post by masklinn » Wed, Mar 13, 2013, 8:04 AM UTC

Peaker wrote: post #146

rektide wrote: post #119

Earlier quoted context omitted.

One could adopt some kind of event-based system in scala or clojure, but Erlang and Go are alike in being the lone runtimes where running millions and millions of very small messaging processes is AOK no problem for the runtime, and not something one has to work really hard for. Fun and joy are terms applicable here because the alternative is Erlang. Zing! Go is rather ideal for these guys use case: if it wasn't an e…

Haskell's runtime makes for cheaper threads than Erlang. Possibly cheaper than Go's, too.

> Haskell's runtime makes for cheaper threads than Erlang. Possibly cheaper than Go's, too.

What's your measure for expenses? Because if it's size in memory goroutines seem more expensive than erlang processes: http://en.munknex.net/2011/12/golang-goroutines-performance.... indicates goroutines were measured at ~4k; the default start size for an erlang process is ~310 words, or ~2k on a 64b machine.