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

401–410 of 511 posts

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

#401

Post by microtonal »

Ziomislaw wrote: post #373
microtonal wrote: post #369

Earlier quoted context omitted.

One other aspect that really guided us towards Go was memory usage. Python was just sucking up so much memory whereas our Go implementation thus far is so much thinner. It's funny that you mention that, because in computationally intensive work memory management is an issue with Go. E.g. I wrote a maximum entropy parameter estimator in Go, which was terribly slow until I circumvented the garbage collector by prealloc…

> I am interested how Go gave you one or two orders of magnitude speedup, while rewriting hot spots in C didn't... paralellization

One can easily do that in C with OpenMP.

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

#402

Post by flyinRyan »

Luyt wrote: post #390
flyinRyan wrote: post #351

Earlier quoted context omitted.

If the language is strictly OO (as Java and C# are) then an ORM is pretty much required. What is the preferred solution in Go? And please don't say writing out raw SQL.

What's wrong with using SQL in your program? As long as your database layer is able to perform parameter substitutions to avoid SQL injection, this is a pretty efficient way to get stuff out of the database (and only the stuff you want). Why would using an ORM be a 'requirement' for OO-oriented languages?

There are quite a few problems using SQL directly in your program. Separation of concern issues, typing issues (e.g. the compiler can't tell you the USER table isn't appropriate here because it has no way to see what you're doing).

In a multi-paradigm language you wouldn't be tied to using an ORM but you should still use something that provides some kind of anti-corrupt support. In an OO language you can have nothing but objects so there is nothing else your database library can return. It may as well return objects that represent the records rather than, say a list of strings.

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

#403

Post by philh »

lifeisstillgood wrote: post #366
philh wrote: post #333

Earlier quoted context omitted.

I dunno how well-known the things I didn't know about are, but an example of me doing it: https://news.ycombinator.com/item?id=5113202

I think there is a fine line between using a library and writin your own to understand better the domain It's something to do with how critical the library functions are to you / your system. I would never write my own compression software, but I can see why people would just to learn about the trade offs.

Okay, but if I had known about the alternatives I would have used them, so I'm not sure how that's relevant.

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

#404

Post by virmundi »

flyinRyan wrote: post #351
burntsushi wrote: post #273

Earlier quoted context omitted.

So what, the lack of a mainstream ORM implies "So there is really nothing to learn besides the language itself"? I don't think so. And there's probably more to a lack of an ORM other than "Go is immature." It's a fairly common opinion among the Go community that ORMs are not worth their complexity. I tend to share that opinion myself, after having worked with a few in a couple different languages.

If the language is strictly OO (as Java and C# are) then an ORM is pretty much required. What is the preferred solution in Go? And please don't say writing out raw SQL.

I've moved away from ORMs in Java because they don't really solve the problem faced. Hibernate could be a really good solution to providing a blanket system for SQL interaction except for the performance issues. If one was really using Domain objects (not pojos, or dumb DTOs) the typing ability of Hibernate would be great. Unfortunately for simple CRUD apps the issues presented by Hibernate (like loading it in an EAR) are such that it requires too much maintenance time on complex projects.

I know that I've used Hibernate for years. I've used it with DTOs. I know that it does provide a certain benefit for simple reads and writes. Unfortunately, Hibernate was designed to work in a disconnected manner like the Web. As a result you get into complications of session management. This is just one example of Hibernate maintenance costs.

Now I use Spring JDBC. This removes the noise of the checked exceptions, connection management, transactions, just like Hibernate. But I write simple or complex SQL in one place and map in and out contently.

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

#405

Post by S_A_P »

Now I know that the dynamic languages such as ruby and python are not known for performance, but the benchmarks I have seen with Go look like it isnt exactly the fastest language available either. After reading this article I am more apt to think that something is/was VERY wrong with their Ruby code than to think that Go is that much better. Maybe my lack of experience with either GO or Ruby is showing here, but Ruby cant be that slow can it????

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

#406

Post by kyllo »

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.

Yes, yes there is.

Most banks, and many other businesses that have been around 30+ years, are still running on COBOL.

It was popular because of its highly readable syntax and its fixed-point packed decimal math for financial calculations.

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

#407

Post by StavrosK »

mercurial wrote: post #355
fkdjs wrote: post #274

Earlier quoted context omitted.

wow, worse than the irc python channel.

Why would you say something like this? The IRC Python channel is a kind of state machine which goes like: - How do I do this? - Why do you want to do this? - Because XXX - Then that's not really what you should be doing, it's dangerous/inefficient/etc., do this instead The post about Acme could have been a one-line answer: "If you want do do any of this, just use a better editor".

There are many times when I said "I need to do X, I know it's ugly, but I've considered all the alternatives and, for reasons too lengthy to go into right now, I just need to do X. How can I do it?" only to get people treating me like an idiot who doesn't know anything, and only giving an answer after I've responded to every single of the alternatives with my reasons.

Sometimes, people aren't new.

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

#408

Post by pjmlp »

kyllo wrote: post #399
pjmlp wrote: post #370

Earlier quoted context omitted.

> The "[language] programmer" (where [language] usually = Java or .NET) trend is a misguided attempt by industry to commoditize programmer talent. From what I can experience in the multi-site enterprise projects I participate, the industry is being quite successful at that.

Successful at commoditizing programmer talent? Perhaps. Successful at producing high-quality software, relative to the resources they are expending on it? Not so much.

> Successful at commoditizing programmer talent? Perhaps.

Yes this is what I mean.

In most enterprise companies nowadays, developers are seen as easy to replace programming cogs.

> Successful at producing high-quality software, relative to the resources they are expending on it? Not so much.

Who cares about quality when the price is right?! :)

Being sarcastic here, I am the opinion the software industry should be under the same quality regulations and expectations as the other industries.

Usually most people return stuff that does not work properly, while with software they just live with whatever bugs the software has.

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

#409

Post by masklinn »

Ziomislaw wrote: post #375
masklinn wrote: post #317

Earlier quoted context omitted.

> But I've used a lot of languages and I never seen concurrency done as easily as shown in that video. So I take it you never used Erlang.

Erlang is big and complicated compared to Go. It's not easy, and besides it is functional (not easy) which already makes it unusable by 90% of people.

> Erlang is big and complicated compared to Go.

No. OTP is big (arguably), Erlang isn't even remotely. It's also completely irrelevant to OP's remark.

> It's not easy, and besides it is functional (not easy)

That doesn't make sense. What's hard in Erlang? That you don't have a for loop?

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

#410

Post by kyllo »

Skywing wrote: post #252
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.

Try a Lisp. You'll be humbled. In my opinion, anything resembling C is easy stuff. Pointers, threads ... it's all pretty easy, really. Truly breaking out of that C mold is the differentiator though, in my opinion. Anybody can learn C, Python or Javascript.

Lisp is a huge paradigm shift, but once you get that writing code in Lisp is basically just writing parse trees directly, it's not so scary.

If you don't already get recursion, though, you will struggle. Everyone struggles with recursion at first.

Post reply on HN