Live data from Hacker News

How We Went from 30 Servers to 2: Go

blog.iron.io

211–220 of 511 posts

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

#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 the JVM with which they are familiar and it is very fast (and true multi-threading).

Maybe they did look into it but I would have thought that would be #1 on their "We tried this but discounted it" list.

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

#212
post #198

Earlier quoted context omitted.

There's some idiots who troll the #golang-nuts freenode channel occasionally with a bunch of spam saying 'node is way better!'. I assume they're not gainfully employed, or else they would understand that the two languages/platforms have very different goals and principles.

`chord`? Yeah, I was in there and was one of the people feeding him/her, I'm ashamed to say. I'd had a few beers and wasn't on my best behavior. Chord was on about "Rails" is better, couldn't fathom a web world without MVC and failed to understand that Rails was just a framework on Ruby and that one could write similar helpers in Go. It was the perfect example of Dunning-Kruger. Painful to witness.

I think there is honestly something wrong with that guy in a mild "losethos" sort of way. He started spamming me trollish nonsense in PMs because I dared utter a single line while he was active.

Something about golang just seems to attract a certain flavor of nutters.

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

#213
post #146

Earlier quoted context omitted.

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

Are they also in Haskell as in Erlang pre-emptable by the runtime? There's certainly some cost in this design decision, more context that has to be swapped in and out and more state kept, but it's important capability to allow blind design & use- think Node, where everyone has to keep re-iterating how important it is to keep yielding to the event loop, to not do a lot of CPU work in a handler: irrelevant in Erlang wo…

> irrelevant in Erlang world

Exactly. That is a subtle distinction but for cases where responsiveness and low latency is important that is key. Another thing Erlang has is isolation of process heaps. If one process crashes, it won't affect others. No shared data structures between processes. It all goes to fault tolerance but also a major win for a completely concurrent garbage collection.

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

#214

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

In general I agree, but I think it's important to note that while a lot of language skills are interchangeable, going from an objected oriented language to a functional one is a pretty big step.

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

#215
post #204
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…

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, not less. People who place a lot of value on their "expertise" in Blub tend to do so because they're over-weighting the importance of their memory of the API details. When they don't automatically remember something, they leap to the conclusion that it doesn't exist. They're also typically a less-experienced cohort than people who have written in lots of different languages.

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

#216

Earlier quoted context omitted.

`chord`? Yeah, I was in there and was one of the people feeding him/her, I'm ashamed to say. I'd had a few beers and wasn't on my best behavior. Chord was on about "Rails" is better, couldn't fathom a web world without MVC and failed to understand that Rails was just a framework on Ruby and that one could write similar helpers in Go. It was the perfect example of Dunning-Kruger. Painful to witness.

I think there is honestly something wrong with that guy in a mild "losethos" sort of way. He started spamming me trollish nonsense in PMs because I dared utter a single line while he was active. Something about golang just seems to attract a certain flavor of nutters.

He stalked me too. Mocked my parents, my sexuality (lolironic), my job, etc. Classy fella.

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

#217

Earlier quoted context omitted.

> I'm very sympathetic to your tech-on-tech-on-tech-on-tech hogwashery promulgated by open sourcers & vendors prosteltyzing their wonderful solutions and the other acculturation factors that permits developers approaches other than trying & seeing & exploring- Are you studying for the SATs, or just trying to make your argument sound more compelling through the use of unnecessarily complex words?

It's how I feel, I'm so very very sorry it's tripped your acceptable tolerance levels. I'll bite my lip and not add "you prat" to the end. Thanks for your considered moderation, and I see your point.

My only point is that being obtuse is not the best way to get your point across. I assume your goal in expressing your opinion is to convince others, and to do so it helps to be clear, concise, and direct.

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

#218
post #179

Earlier quoted context omitted.

Testing: http://golang.org/doc/code.html#Testing Iterating: http://vimeo.com/53221560

from a testing point of view this looks pretty week. I would not bet my business on something that has not a testing culture.

What? Go check out any moderately popular library in Go (including packages in the standard library), and I bet you're fairly likely to see a `*_test.go` file somewhere (perhaps more than one).

Unit testing in Go is refreshingly simple. And it comes standard with the Go toolchain.

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

#220
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.

> Most of programming and all of computer science is universal.

Performance is not universal. Stacking generic algorithms and patterns on top of each other leads to language specific bottlenecks, tweaks and practices. Practical concerns are not universal. i.e. Lispers know the value of everything, but the cost of nothing. - Alan Perlis

Post reply on HN