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

261–270 of 511 posts

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

#261

Post by thetabyte »

nkohari wrote: post #158
rektide wrote: post #112

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- That said, you are wrong. I'm not a Go user and I don't care for it, but Go is fundamentally different and better than most runtimes. Go has it's own green threa…

> 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?

Yet, different, and sometimes more complex words can have entirely unlike connotations, that much more effectively describe the message the author is trying to convey. Sometimes, simpler words are just that—too simple to properly describe the concept the author would like to capture, and the emotions he would like to encode within it.

That's not to say complicated is always better. Like it programming, the best set of tools are those suited for the job.

In the end, you consider your audience. Can I add more to this sentence to better capture the feeling I'm trying to convey, without detracting from it's ability to be understood? The parent most likely decided that on a forum like HN, the answer was yes.

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

#262

Post by tptacek »

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…

Comments like this are weird. Go does not like exceptions. They've built a whole idiom around error returns. When you said, "I need exceptions", what did you expect them to say? "Oh, sorry, we forgot that, we'll get right on it"?

I also don't understand what you mean by "interactive debugger". What is gdb if not an interactive debugger? Gdb is my go-to debugger for Ruby as well.

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

#263

Post by dyselon »

jewel wrote: post #7

For large projects, it'd probably make more sense to rewrite the critical code sections in C. rubyinline makes this really easy, and ruby C extensions aren't that bad either. One time on a contracting gig I had some code that was interacting with cairo drawing and imagemagick. They didn't have a compatible raw image format at the time (one was RGBA and the other was ABGR, IIRC.) It's trivial to convert between the tw…

This definitely does make a lot more sense than throwing out your whole app and rewriting it in many situations, but I'm always a little hinky about moving stuff into C just because it has so many ways to shoot yourself in the foot. You can obviously create bugs in any language (I know I certainly have!), but Go really does hit a nice spot between safety, productivity, and speed, so I can definitely see the attraction.

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

#264

Post by pifflesnort »

kamaal wrote: post #235
TillE wrote: post #30

Earlier quoted context omitted.

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. The quality of a serious programmer is to get things done. Not tool tricks. When I go out to hire a carpenter, I just ask him to show me some of his work. If I like it I buy from him or hire his services. I don't go around and ask him to demonstrate how he uses a hammer.

Getting things done means using the best tool for the job. Sometimes that's a language outside of your immediate preference, because that's what the best tool/library/platform is written in.

Today I wrote Java (LDAP server plugin), and ssembly (for unit testing some code that has to minimally interpret x86 assembly). I'll also occasionally need to write some JS/HTML/CSS for the web, work on systems programming for other architectures (ARM, AVR), write kernel code and drivers (C/C++), write/extend a Python script (HTTP test client), write Tcl (to drive simulavr), ObjC (iOS apps), and occasionally write some functional code for fun (I have no business case for it, sometimes it's just nice to work on something clean).

I've done and do all those things (and more) not because I have 'tool tricks', but because in nearly every case, I needed to use the tool most suited to getting things done in that problem domain.

Programmers that refuse to adapt to the given problem domain do their users a disservice. It's like the old joke about which nationalities run heaven and hell -- the worst possible people set to tasks for which they're innately ill-suited. However, programmers can learn more -- if they're willing -- and adapt to better suit themselves to the problem at hand.

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

#265

Post by redler »

burntsushi wrote: post #115
tptacek wrote: post #35

Earlier quoted context omitted.

Well, Go has a bunch of libraries for different SQL servers. I wouldn't go so far as to say it has lots of good SQL stuff; it's in approximately the same place as C is w.r.t. databases. Having to interface with complicated SQL is a reason not to use Go (but not an insurmountable one).

> it's in approximately the same place as C is w.r.t. databases. I think the existence of a standardized interface like `database/sql` makes things strictly better. An anecdote: I started making a new web application using MySQL. As soon as I realized the error of my ways (not because of the driver), I swapped out a single import from the MySQL driver to the PostgreSQL driver, and everything continued to work as it d…

The downvotes are likely because they're reading your MySQL-to-Postgres anecdote as the firing of a shot in an unrelated battle many love to hate, if not a mild troll.

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

#266

Post by beatpanda »

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…

Hi, I'm in the market* for an Arabic sentiment engine for some academic research, can you contact me? My email is in my profile.

*Note that "in the market" doesn't mean I have a lot of money to spend :D

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

#267

Post by dwd »

stcredzero wrote: post #171
16s wrote: post #152

Earlier quoted context omitted.

C++ and Python pretty much run everything, everywhere. Standard, open languages are hard to beat when you want to fully control your development stack and not worry about future control issues. I wish go was an ISO standard like C++, I'd be more interested if it was.

> C++ and Python pretty much run everything, everywhere. I don't think so. Last I heard, there was still a lot of COBOL out there.

COBOL gets all the hate but if they have a Big iron mainframe then they'll most likely be running RPG.

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

#268

Post by burntsushi »

redler wrote: post #265
burntsushi wrote: post #115

Earlier quoted context omitted.

> it's in approximately the same place as C is w.r.t. databases. I think the existence of a standardized interface like `database/sql` makes things strictly better. An anecdote: I started making a new web application using MySQL. As soon as I realized the error of my ways (not because of the driver), I swapped out a single import from the MySQL driver to the PostgreSQL driver, and everything continued to work as it d…

The downvotes are likely because they're reading your MySQL-to-Postgres anecdote as the firing of a shot in an unrelated battle many love to hate, if not a mild troll.

Ah, right. My bad. The folly is still fresh, and there is still a bit of pent-up rage that I hadn't made this discovery sooner.

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

#269

Post by eru »

willismichael wrote: post #238
eru wrote: post #222

Earlier quoted context omitted.

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

I'm already having a hard enough time convincing the team at work to use Clojure!

Oh, Clojure is probaly more useful in practice. We also stick to a Haskell dialect at work, and don't dabble in Agda for production.

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

#270

Post by johnb »

boundlessdreamz wrote: post #240
pkulak wrote: post #234

Earlier quoted context omitted.

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.

The only gems that do not work are those which are not pure ruby. For the popular gems I think there have been rewrites. I haven't looked into JRuby but it has changed quite a bit in the last year from what I read

I don't think that's true. There are plenty of threadsafe gems with C extensions, and plenty of non-threadsafe pure ruby gems that mutate class/class-instance variable willy-nilly.
Post reply on HN