Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How We Went from 30 Servers to 2: Go

blog.iron.io

Post reply on HN
Print view View original

131–140 of 511 posts

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

#131

Post by stalcottsmith »

I've seen a lot of dumb Rails server configs and even dumber usages of Rails without any tuning at all.

With a couple weeks or a month of work I could shrink the hosting fees or resources consumed by a factor of 5 out of most Rails apps that are sitting up around 30 servers... and probably a factor of 10. Leaving aside whatever rookie or even intermediate mistakes were made in their Ruby code or their database, this post indicates a lack of understanding of what happened when their server fell over. Proper tuning of a deployment should not trigger a 100% failure mode like this.

These folks were itching to get off of Ruby for whatever reason... after all their roots were in Java. If your goal is to do a rewrite and learn a new language and gain some notoriety why waste time learning what you did wrong with Ruby or your server config?

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

#132

Post by burntsushi »

laumars wrote: post #127
burntsushi wrote: post #98

Earlier quoted context omitted.

I use Apache too (it's all I've ever known), and run a few Go web apps. Everyone lives quite peacefully together. With Apache, I just set up a simple reverse proxy. Here's an example of one I use to run my own `godoc` server: ServerAdmin admin@burntsushi.net ServerName godoc.burntsushi.net ProxyPreserveHost On ProxyPass / http://burntsushi.net:8080/ ProxyPassReverse / http://burntsushi.net:8080/

Nice idea. I might try that before dipping my toes into Nginx

Yeah, it's a nice holdover. I keep hearing great things about Nginx though. Someday I'll have time to check it out :-)

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

#133

Post by paddyforan »

quaunaut wrote: post #86
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…

Maybe I'm just a new and terrible programmer, but I feel like if you wait to fully understand whatever tech is out there in terms of what to use, you'll never get started.

Let's be new and terrible programmers together, because I feel like the only way to fully understand whatever tech is out there is to actually use it.

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

#134

Post by martinced »

jianshen wrote: post #8

Hey that's my photo of the GOpher! :) [1] http://www.flickr.com/photos/jianshen/8080852738/in/photostr...

+1 for the cool monitor stands but geez... Invest some $$$ in a real keyboard: scissor switches are the most painful type of keyboard switches ever : (

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

#135

Post by codygman »

cpprototypes wrote: post #111
waterside81 wrote: post #66

Go's definitely picking up momentum. I know that Mozilla is shifting much of its services infrastructure to Go. We're porting over our Arabic sentiment engine, currently in Python/Cython to Go. If you're dealing with simple data structures, going from Python to Go is almost a line-for-line port, but the performance benefits are, of course, massive. Our benchmarks show a 40x speed improvement so far. Lastly, for anyon…

Just curious, what were the tradeoffs for profiling the Python code and rewriting slow parts in C vs total rewrite in Go? For high level languages, the usual argument has been to rewrite just the slow parts in C or some other low level language.

One thing you don't get in the C/Python combo is total static typing. The other big win of Go is elimination of a lot of runtime errors.

So it comes down to which will be more of a win for you and your product. Go has a big advantage here IMO though because of static typing AND performance increase.

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

#136

Post by willismichael »

georgeorwell wrote: post #129
stcredzero wrote: post #102

Earlier quoted context omitted.

That's how you gauge the experience of a programmer: how much of the field she/he's terrified by. EDIT: I originally meant this as a joke, but seriously, if someone accurately knows where the gotchas are, that's valuable. Also note if they're biased to false positives and/or false negatives, and by how much. Are their heuristics for dealing with unknown territory efficient and likely to converge on good approximate r…

Thanks guys, I guess I really have had some rough times. I like how Lisp and Assembler at the top of the hierarchy capture the two extremes. Some hypothetical language in the middle would be great, but maybe the best we can do is to straddle that point, e.g. with C++ and Python.

Rather than straddle the middle, I think I'd go with as high-level a language as I could get, coupled with a simple low-enough-level language to get whatever performance benefits I needed. Some combo like Python/C, Clojure/Java, or maybe some other lisp dialect and C.

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

#137

Post by laumars »

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.

This has been my experience learning Go as well.

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

#139

Post by martinced »

ikeepforgetting wrote: post #95
buro9 wrote: post #69

Earlier quoted context omitted.

We're writing most of the systems for our company in Go, and of the many reasons this ranked highly. Just removing the multiple unnecessary abstractions gets you a hell of a lot of simplicity and performance back.

I work in an area that requires a lot of high performance computing and there is a reason people in this area like code simplicity. Stacking layer upon layer of complex algorithms is a lot more difficult to reason about than having a simple and elegant system that's close to the metal. There is a recent trend of building more and more complex systems, have less coupling and 'good oop'. That's all good and nice but si…

"Having a 50K lines of code dedicated to just inversion of control or O/R mapping makes a problem a lot more complex than it probably needs to be."

Exactly. That's the terrible stuff with all this "enterprisey" mindset: people are working on medium-sized codebase made of this special kind of hell that Java/C# + ORM ([N]hibernate) + XML + SQL is and these app often run into the 200K / 300 KLOC lines if not more. Yet what does these applications really do? Actually not very much. Yet these programmers are sure to be working on super-advanced stuff because their codebase is big.

When several companies reported a drop in LOC of 90% by switching to something else than Java then at one point you have to at least consider that maybe most of your Java codebase is hot air.

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

#140

Post by duaneb »

pcwalton wrote: post #113
stcredzero wrote: post #105

Earlier quoted context omitted.

> Rust and Go are not similar or competing. Rust is more "kitchen sink" (done as elegantly and cleanly as possible) and Go is more minimalist.

Being "kitchen sink" isn't a design goal of Rust. Rather, Rust is a lower-level, safer language. Go is higher-level. Rust strives to be as minimalist as possible without sacrificing the goals of low-level control over memory and C++ performance (optional GC), memory safety, race-free concurrency, and type safety (no null pointers).

I don't think he meant kitchen sink, more that there are fundamental aspects from many parts of languages that are bound together well, which makes

> Rust strives to be as minimalist as possible without sacrificing the goals of low-level control over memory and C++ performance (optional GC), memory safety, race-free concurrency, and type safety (no null pointers).

somewhat funny.

Post reply on HN