Live data from Hacker News

How We Went from 30 Servers to 2: Go

blog.iron.io

481–490 of 511 posts

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

#481
post #440

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…

Do you also used the default net/http support libraries?

Yes, I'm using net/http.

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

#482
post #466
post #461

Earlier quoted context omitted.

D syntax is nicer than Go's, but its also dead compared to Go. Where are you going to put your chips?

> D syntax is nicer than Go's, but its also dead compared to Go. Because it is full of Google PR and happens to have some cool names on the team? > Where are you going to put your chips? In languages that the designers don't throw away the last decades of improvements in language design.

Yes, because its full of Google MONEY! Its about the libraries...

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

#483
post #482
post #466

Earlier quoted context omitted.

> D syntax is nicer than Go's, but its also dead compared to Go. Because it is full of Google PR and happens to have some cool names on the team? > Where are you going to put your chips? In languages that the designers don't throw away the last decades of improvements in language design.

Yes, because its full of Google MONEY! Its about the libraries...

Which will get canned like many other Google projects when they fed up with it...

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

#485
post #225
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…

"it's a lot harder to track down bugs for a newcomer" This is FUD. It's a different way of doing things, not harder. I live inside Pry which makes it rather easy to figure out what's going on.

That's kind of what I'm talking about. I've never heard of Pry. With Rails I have to learn about the 100 most common gems (devise, paperclip, mongomapper or mongoid), Pry (thanks for that), bundler, rvm, and ActionEverything before I can be productive (or understand a simple app) . With Node.js, something newer with less "maturity", I figure out npm and I'm good to go.

I really don't think it's FUD to say that Rails has gotten much bigger in the past 5 years, and it's definitely not FUD to say that as codebases and tooling grows, so does barrier to entry.

The specific thing I guess you're objecting to is that it's harder for a noob to understand implicit imports and where something is coming from if you don't know much about what you're importing. If you use a tool to solve that language deficiency, that doesn't remove the deficiency from the language. By that logic, adding an IDE to Java makes it a very concise language.

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

#486
post #140

Earlier quoted context omitted.

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.

Why funny? (coming from someone who's thinking about giving Rust a try)

He said "rust doesn't have the kitchen sink", and then listed the kitchen sink. Rust is awesome, you should use it.

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

#487
post #486

Earlier quoted context omitted.

Why funny? (coming from someone who's thinking about giving Rust a try)

He said "rust doesn't have the kitchen sink", and then listed the kitchen sink. Rust is awesome, you should use it.

Alright, I'll download the compiler/etc right now :D

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

#488
post #453
post #400

Earlier quoted context omitted.

You mean by designing a language that is basically Alef from Plan9(1992) with a few changes? Yeah, really actual.

The English term for "actual" is "up-to-date". The English word "actual" means "not imaginary".

thanks for the correction.

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

#489
post #30

> "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.

Many programmers are religious about their languages.

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

#490

Earlier quoted context omitted.

That's not really true. Granted Go doesn't have as many libraries as the more established languages, but to say there aren't many and there's "nothing to learn besides the language" is just flat out wrong. Just for starters there's http://code.google.com/p/go-wiki/wiki/Projects

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. :)

A seasoned java developer stays away from orm anyway ;)
Post reply on HN