Live data from Hacker News

How We Went from 30 Servers to 2: Go

blog.iron.io

281–290 of 511 posts

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

#281

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

What is an "Arabic sentiment engine" :-D? Like textual analysis as to whether a piece of Arabic text is positive or negative?

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

#282
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…

> Are they also in Haskell as in Erlang pre-emptable by the runtime?

Yes. [1]

[1] - http://www.haskell.org/ghc/docs/latest/html/libraries/base/C...

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

#283
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. It depends if you're going to spend years training someone or if you need an expert right now. My experience is that it is impossible to maintain expert level skills in more than one or two language + library environments. You can remain familiar with other environments but you don't have the time to be an expert. While I sometimes switch between C-family lang…

However, you do not need to be an expert to be productive. You can write Django web apps perfectly well without knowing about Python's metaclass tricks, for example.

An expert still needs time to become familiar with a large codebase and architecture. I wonder if a competent programmer could simply learn the language in addition during this period.

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

#284

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.

Go interfaces are not the same as Java interfaces. Go interfaces are implemented using structural sub-typing.

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

#285
post #251
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 :)

Could you give a specific example as I am still thinking "random number generator" and want to balance it with your "standard idiom or library that everyone steeped in $lang knows "

Cheers

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

#287
post #222

Earlier quoted context omitted.

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.

That is somewhat orthogonal. Lisp is better at abstraction than Agda or Coq or Isabelle or any of those ML/Haskell theorem proofers. To maintain the theme:

C if you are terrified about performance

Lisp if you are terrified about boilerplate

Agda if you are terrified about correctness

If you are terrified about all of these, then welcome to the world of engineering.

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

#288

Earlier quoted context omitted.

Hey OP! I appreciate your sharing. Since you came from ruby and we're on the topic of the language itself, I'd appreciate your impression of how well Go supports collections. Is there or could one write something like http://underscorejs.org/ ? Can you do this kind of thing? [1, 2, 3, 4, 5].reject {|i| i I did the go tutorial the other day and I became a little worried that one would not be able to do this kind of th…

Go's lack of type parametrisation makes many higher order functions really awkward. I'm no expert on Go, but below is my attempt at writing a generic Map function. As you can see, the code of the Map function itself isn't so bad (though there's a lot of noise in the declaration). Using that function however is really annoying, as you need to convert from the slice you have ([]string, []int, etc.) to an empty interfac…

Here's a more idiomatic go version:

http://play.golang.org/p/oH850AdLuQ

what you don't realize (apart from the fact that go doesn't terminate lines with semicolons since 2009) is that you don't need to create a copy that's typed []interface{} because []X already satisfies interface{} and you can use reflection to handle it. if a seasoned Go programmer wanted to write a somewhat generic map function they'd do something similar to this:

http://play.golang.org/p/qM8sBNcdwY

It doesn't look pretty and you're right, most go programmers don't have to write code like this. It is much more common to define a common interface for something that's map-able and expect callers to implement that. examples in sort.Interface.

Post reply on HN