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

341–350 of 511 posts

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

#341

Post by codygman »

pjmlp wrote: post #311
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.

Just a guess, I'm guessing python isn't your favorite language either? They seem to be rather unopinionated languages that let you have access to lots of tools. I hear they manage to keep it pretty simple despite having a "kitchen sink", so definitely interested in both.

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

#342

Post by LinaLauneBaer »

chadcf wrote: post #224
mjn wrote: post #202

Earlier quoted context omitted.

My intro programming course (in high school) was in C++, and I think it would've scared me off programming entirely if I hadn't picked up mIRC-script (a very different language) on my own as a hobby. There is so much accidental complexity in C++ that it's a pretty terrible introductory language. We literally spent several weeks of the semester on how to get input and output to work properly through the giant mess tha…

Me too (well, ok, my first programming class was in Fortran taught by a 85 year old man who spent most of the time telling us about how much harder it was back when you had to use fortran). I hated C++. I still think it's a fairly terrible language. But, for fun I took the Harvard CS50 course to refresh my knowledge of C and I found that WAY better than my C++ course. I think C is brilliant for introducing programmin…

The Objective-C garbage collection is deprecated.

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

#343

Post by codygman »

pjmlp wrote: post #312
bpicolo wrote: post #199

Earlier quoted context omitted.

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.

Typically a language is considered slow or fast based on it's most popular implementation, sadly.

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

#344

Post by timr »

jbooth wrote: post #251
timr wrote: post #231

Earlier quoted context omitted.

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. That's called "laziness", and is even more likely than NIH syndrome to be mitigated by experience. Certainly, having lots of coding time with a single language doesn't make you less lazy, and having lots of experience with different languages doesn't make you lazier.

Well, I'm less lazy than most devs and have worked in lots of languages and did it just the other week -- maybe I'm just not that bright :)

It's certainly possible that you'll miss some oddball idiomatic way of doing things in a new language (e.g. Python itertools or using C++ STL algorithms or something like that), but this is rarely a real problem. The job gets done correctly -- and in any case, we're all learning new ways of doing things. It's not as if you gain total prescience after N days on the job with Blub.

The point isn't that the generalist programmer will be 100% correct in all the details in new language, it's that they'll be able to quickly (and correctly) implement the important parts in whatever language you're using. Idioms tend to be the low-order bit of a solution anyway.

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

#345

Post by grey-area »

treeder wrote: post #43
grey-area wrote: post #14

Interesting to hear of Go being used in production. It'd be great to hear some more details on your setup when deploying the go processes - how are you managing failover, what's your load balancer, and how are you handling swapping out processes etc? Are you compiling on the server or local machines before deployment? Most other languages have lots of solutions on the deployment side now but Go is so new there isn't…

We actually have our own deployment tools for Go (and for Rails, our databases, etc). We built them before all the new hip options that are around today. We build on the target machines, although that's not a requirement since we all run the same architecture on our dev machines too (64 bit linux). I'm not sure about writing a front end in Go, there's not a lot in terms of UI frameworks and Iron.io front end (HUD) is…

Interesting to know that you're building on target machines, I have yet to explore cross compilation, but it'd be great to be able to build before deploy.

Sorry, deployment was probably the wrong word - I was not so worried about getting the files up there (like you I have a simple home-grown solution for that), but more how you were handling process management, swapping out processes etc.

Perhaps with Go this is less of an issue because startup time for new processes is minimal, and you can simply kill one process, start another and not really miss any requests (unlike say Rails with startup times of 10 seconds or so for instances)? Did you find this wasn't a big issue in practice and something very simple works for you?

I'm currently playing with go but if considering it for client use would have to be sure that things like this were not an issue. Are you using any off the shelf tools for process management/load balancing or is it something that you have built yourself? Did you run into any problems?

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

#346

Post by flyinRyan »

jbooth wrote: post #204
timr wrote: post #177

Earlier quoted context omitted.

"It depends if you're going to spend years training someone or if you need an expert right now." I'm not going to claim that there are no legitimate reasons to hire people who are narrow experts in Blub (and only Blub), but I'm having a hard time thinking of any. At an established company, you've got the luxury of time -- there's rarely a good reason to "need an expert right now" that isn't just a contractor. At a st…

Even at an established company, a really smart language newbie could write a bunch of ad-hoc code that does almost the same thing as well-understood libraries that everyone more experienced in the language uses. Even if his code was relatively high-quality, now you have a bunch of extra stuff to maintain, and everyone who interacts with it will have to learn this thing instead of just using the library everyone knows…

You talk as if we develop code by chiseling it out in stone. We write it in text files, usually with IDEs. No one needs to learn the new libraries the newbie made, they can talk to the newbie, point out what the library already gives (and where to look in future) and write to well known interfaces.

Any project should have time allocated for "tech debt" and that's where this sort of thing gets addressed.

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

#347

Post by vitalie »

I rewrote my DNS checking tool (http://www.dnsinspect.com/) in Go and I saw huge differences in resource usage (previously it was implemented with Ruby on Rails + EventMachine), my memory usage went down from 128MB per background worker to a few KB.

Now I'm able to run hundreds to thousands of concurrent reports using a small VPS, the Go application is using 36MB of RAM (24MB front end + 12MB for background workers). Go language is well suited for my particular case (many concurrent IO operations).

This was my first Go project, in a week I was comfortable with it, I had many alternatives but I really liked the simplicity of Go, fast compilation and easy of deployment. Because I've missed some pieces from the Ruby's world I've combined Jekyll (Compass, HAML SASS, RedCarpet, etc) with Go. :)

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

#348

Post by ghostganz »

pkulak wrote: post #234
rurounijones wrote: post #211

Ok, this bit has left me confused. They were Java devs that liked ruby, they wrote applications in Ruby on Rails and the ruby apps were hitting limits so they immediately started looking at other languages. But they don't mention the most obviously (to my mind) simple option. JRuby It is ruby (They like ruby). Most ruby apps can be run on JRuby with very very little changes (No need for a big rewrite) and it runs on…

In my experience, rewriting for JRuby is as much work as re-writing in a new language. Last I looked was a year or two ago, so it may have all changed, but it's not as simple as just moving your code over. Many really important gems don't work, or don't work properly.

That used to be the case, but a lot has happened in the last few years. Most of the time you'll be able to move a large Rails application to JRuby without any changes at all, except adding a Warbler config for deployment.

We use JRuby for a one of our backend applications in production, but we develop them with plain MRI Ruby. Only real problem we've run in to was some of our badly performing (badly written) parsing code that ran even worse under JRuby.

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

#349

Post by julien_c »

vitalie wrote: post #347

I rewrote my DNS checking tool ( http://www.dnsinspect.com/ ) in Go and I saw huge differences in resource usage (previously it was implemented with Ruby on Rails + EventMachine), my memory usage went down from 128MB per background worker to a few KB. Now I'm able to run hundreds to thousands of concurrent reports using a small VPS, the Go application is using 36MB of RAM (24MB front end + 12MB for background workers…

Looks great, bookmarked.

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

#350

Post by regularfry »

cartwright wrote: post #186
rgbrgb wrote: post #169

Earlier quoted context omitted.

By this definition, Ruby/Rails are pretty crappy (I kind of disagree). As a newcomer, the amount of stuff going on in a Rails app and the stack trace when there's an error are pretty overwhelming. Meanwhile, people expound on how simple and elegant Rails is. Lately I've been thinking that this is because those people started using it 5 years ago when it was small and their knowledge has built incrementally with the e…

Rails is pretty crappy if you ask me. It's "omakase" which is Japanese for "acts according to what DHH wants despite what the community wants". And there's a lot of magic happening that isn't explained very well. There are better frameworks in Ruby. Ruby itself doesn't take all that long to be an expert at.

Ruby doesn't take long to be productive in. It is an utter pain to become expert in, for any reasonable definition of "expert". Fortunately it's fun enough that I don't mind the slog.
Post reply on HN