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

221–230 of 511 posts

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

#221

Post by jbooth »

timr wrote: post #215
jbooth wrote: post #204

Earlier quoted context omitted.

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

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

#222

Post by eru »

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.

> I like how Lisp and Assembler at the top of the hierarchy capture the two extremes.

Not really. I'd place Agda or Coq above Lisp.

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

#223

Post by SomeCallMeTim »

TillE wrote: post #30
shurcooL wrote: post #20

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

>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 others for the first year or three using C.

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

#224

Post by chadcf »

mjn wrote: post #202
kyllo wrote: post #74

Earlier quoted context omitted.

This is why Joel Spolsky correctly observed that the replacement of C/C++ and functional languages with Java in university CS curricula is a tragedy. If you don't understand pointers or recursion, you are not a polyglot and you cannot pick up just any language in a matter of weeks. The "[language] programmer" (where [language] usually = Java or .NET) trend is a misguided attempt by industry to commoditize programmer…

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 programming because it's very very simple, yet also very very difficult. There's not much to learn, except a lot of concepts (memory usage, data structures, etc).

I also think Objective-C is a really great language though, so I might be crazy. But, you give me a choice between C++ and a language that is basically C with a few additional keywords and garbage collection, and I find that an easy choice...

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

#225

Post by jshen »

rgbrgb wrote: post #169
bingobangobongo wrote: post #160

Earlier quoted context omitted.

> impossible to maintain expert level skills in more than one or two language + library environments And the crappier your language and libraries, the more time it takes to be an "expert."

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.

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

#226

Post by oscardelben »

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…

I'd like to see some real benchmarks with a real app, but I doubt moving to jruby would bring the magnitude of improvement mentioned in the post.

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

#227

Post by trungonnews »

drivebyacct2 wrote: post #193
trungonnews wrote: post #188

Earlier quoted context omitted.

Go doesn't have any mocking framework like Mockito/Java or Rspec mock. You will end up writing a ton of code yourself if you want to mock something simple.

Uh what? No, that couldn't possibly be less true. Have you ever heard of "interfaces" in Go? They're kind of an important feature.

That's what the other gophers say too. Java has interfaces too, but it also has Mockito that makes testing much easier. You should look into it. Mocking library will help reduce boiler code. You would know that if you had used one.

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

#228

Post by drivebyacct2 »

trungonnews wrote: post #227
drivebyacct2 wrote: post #193

Earlier quoted context omitted.

Uh what? No, that couldn't possibly be less true. Have you ever heard of "interfaces" in Go? They're kind of an important feature.

That's what the other gophers say too. Java has interfaces too, but it also has Mockito that makes testing much easier. You should look into it. Mocking library will help reduce boiler code. You would know that if you had used one.

>You would know that if you had used one.

Cute.

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

#229

Post by TresAmiga »

drivebyacct2 wrote: post #187
TresAmiga wrote: post #163

Earlier quoted context omitted.

Wrong and you know it. Go does not have generics so you have to use void* (interface{}) and casting. It ends up being about an order of magnitude uglier and more verbose. Which is why map, fold, etc don't exist in Go. You go fanatics are incorrigible.

Seriously? Is this just a coincidence that another throwaway named "TakeTwo" and then "TresAmiga" are both making throw aways and dismissing all Go users? Jesus. What he's describing is far more than possible using interfaces. I have plenty of code that does so. How is that "wrong and he knows it". Your worse than any Go fan here. Where the hell does someone get off being vitriolic about a language or someone's prefe…

"What he's describing is far more than possible using interfaces. I have plenty of code that does so."

I did not say it was impossible, I said it was ugly and really verbose, which it is. If you think different how about actually posting the code and an example of generic map being used so everybody can see how 'wrong' I am.

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

#230

Post by azakai »

jbooth wrote: post #207
azakai wrote: post #77

Earlier quoted context omitted.

Rust and Go are not similar or competing. They are both new, but aside from that the differences are huge. So if a project uses one, that doesn't mean the other was a possibility for that project too.

They're not similar at all, but both were designed to replace C++. That sort of means that they're competing for the use-case of "things I would write in C++ if it wasn't a god-awful nightmare to do so". From there, though, you're right that they take very, very different approaches.

> They're not similar at all, but both were designed to replace C++.

In practice, the main use for Go appears to be like this story - an alternative to RoR, Node, Python/Django, etc. - and not a C++ alternative. Go and Rust may both start from the idea of doing C++ or something similar "right", but end up in very different places.

Post reply on HN