Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go After 2 Years in Production

blog.iron.io

Post reply on HN
Print view View original

71–80 of 178 posts

Re: Go After 2 Years in Production

#71

Post by nknighthb »

dancric wrote: post #3

As a developer on the Python stack, I would love to know when would be a good time to start using Go in serious production work. It seems to me that it solves a lot of the backend services infrastructure problems associated with interpretive languages (one of the reasons I was considering diving in Scala or other JVM languages), is relatively reliable, and has a fairly strong core library. It still seems bleeding edg…

I'm using Go in production, and migrating existing Python services to it. I've found nothing wrong with using it for "serious production work". The ecosystem obviously isn't as mature, but it's getting there. There don't seem to be any gaping holes.

Re: Go After 2 Years in Production

#72

Post by jerf »

jd007 wrote: post #31

"Two years in, Go has never been our bottleneck, it has always been the database." I would expect this to be true with any language, if you code well. Regular web applications do not have state so they are very easily scaled horizontally anyway. Databases on the other hand are trickier to scale the same way and will end up being the bottleneck almost all the time.

Profile your code. You might be surprised.

You might not.

Or, you might be surprised when you find something like "I'm making 5000 DB queries?" instead of your language being slow.

But certainly if "enough" people take my advice here who have not profiled one of their web pages before, there's a non-empty set of them that are going to go "Oh crap, I didn't realize that's what was so slow, I just assumed it was the database!" Not every web app is a glorified select statement.

And there'll also be quite a few people who discover that their page isn't "slow" or anything, but who will discover that the CPU vs. IO is closer to 50/50 than they realized or something.

Re: Go After 2 Years in Production

#73

Post by noelwelsh »

neya wrote: post #32

Another Scala user here. And I've been using Scala for the last six months. Mostly developing web applications on Scalatra and Play. I love Scala - It still has its goodiness and it's an excellent alternative to Java. If you notice in all of the Scala books (I've read the one by Martin and the One by David Pollak as well), they all seem to push you towards the functional programming model instead of the much more com…

I find your comment quite odd, as a web service is just about the most functional thing you can get -- it's just a function request => response as you note. I don't see where you'd need to make it "more functional."

Re: Go After 2 Years in Production

#74

Post by jd007 »

bhauer wrote: post #58
jd007 wrote: post #31

"Two years in, Go has never been our bottleneck, it has always been the database." I would expect this to be true with any language, if you code well. Regular web applications do not have state so they are very easily scaled horizontally anyway. Databases on the other hand are trickier to scale the same way and will end up being the bottleneck almost all the time.

In my experience, with slower platforms/languages, while it may be conventional wisdom that the database is the bottleneck, that's not actually the case in many circumstances. Certainly in circumstances where you're doing a complex query involving fields that are not indexed or several joins, you're going to be waiting on the database. But if you're just fetching rows by ID or indexed fields, slower platforms and lan…

If you are talking about a breakdown of time consumed during a single request's processing, then yes on slower platforms/languages/frameworks, the database access portion may not be the most significant percentage of time used. But this is not that relevant as even the slower platforms usually can handle a single request reasonably fast.

What I was talking about was more about in the scaling of a system, i.e. what happens when your architecture needs to handle lots of requests. In this case, it is very rare for the application server part of your architecture to be a bottleneck in scaling because it is generally stateless (for normal web apps at least) and hence very easily horizontally scaled out. Of course a faster platform will allow you to use fewer servers but 15 servers on Go vs. 20 servers on Python is not that big of an issue.

Re: Go After 2 Years in Production

#75

Post by paddyforan »

jd007 wrote: post #31

"Two years in, Go has never been our bottleneck, it has always been the database." I would expect this to be true with any language, if you code well. Regular web applications do not have state so they are very easily scaled horizontally anyway. Databases on the other hand are trickier to scale the same way and will end up being the bottleneck almost all the time.

I think one of my favourite things about Go is that it makes it easy and obvious to code well. Generally the first thing that comes to my mind is going to be performant and extendable.

The reason this is the case, I think, is that Go strives to make algorithmic complexity clear: you know when you're allocating memory, but you don't need to jump through hoops to do it. You know the rough performance costs of what you're doing because the core team works hard to make it obvious. For example, some regular expressions features (lookahead, if I remember correctly) aren't implemented in the Go standard library's regular expression package, because they're impossible to achieve in O(n) time. https://groups.google.com/forum/#!topic/golang-nuts/7qgSDWPI...

This level of care in making simple, clearly-defined tools with known properties makes it easy to code well. Ruby, Python, PHP, NodeJS... you can shoot yourself in the foot and not even notice.

Re: Go After 2 Years in Production

#76

Post by jlarocco »

programminggeek wrote: post #6
melling wrote: post #2

The memory footprint for Go seems to makes it ideal for mobile devices. Also, considering that Dalvik performance is much slower than Java, it really seems like have Go on Android would be a huge win. http://en.wikipedia.org/wiki/Dalvik_(software)#Performance Go compiles to native, so "compile on install", would probably be needed.

Go on Android would be great, but Google used Java in the first place so that they could leverage all the Java devs in the world to build Android apps. Go might be a much better choice from a pure dev standpoint, but from a getting everyone to build apps standpoint, it's a fail in the short/middle term.

I'm not so sure. There's no lack of iOS developers, and most of them are using Objective-C...

Re: Go After 2 Years in Production

#77

Post by bpodgursky »

Pxtl wrote: post #10

I know it's cliche, but I still can't live without generics or a macro-like approximation thereof. I suffered under Java 2 for too long to go back to that.

Totally with you. I can't imagine using a language where I can't create easily re-usable data structures. It feels like a huge step backwards.

Re: Go After 2 Years in Production

#78

Post by pkinsky »

neya wrote: post #32

Another Scala user here. And I've been using Scala for the last six months. Mostly developing web applications on Scalatra and Play. I love Scala - It still has its goodiness and it's an excellent alternative to Java. If you notice in all of the Scala books (I've read the one by Martin and the One by David Pollak as well), they all seem to push you towards the functional programming model instead of the much more com…

>Another downside of Scala is its HUGE syntax. Processing strings? Here's a ten million ways to do it.. (a bit over-exaggerating). Oh and if you chose this way, then you should use this syntax. No, not that one, THIS one. Oh no, not that one, this variation of that one that looks like this.

On the other hand, Scala lets you deal with collections and Strings using the same enormous set of methods.

    "\"foo\"".drop(1).dropRight(1)
is just

    List('"', 'f', 'o', 'o', '"').drop(1).dropRight(1)

Re: Go After 2 Years in Production

#79

Post by Ziomislaw »

bhauer wrote: post #16
Pxtl wrote: post #13

Earlier quoted context omitted.

And like Java 1.2, it is still missing some critical deal-breaker features for a lot of people.

Exactly. The maturity level is about the same--obviously in different ways--but I think you get what I mean. Will they ever add generics? Not sure. Will Java ever have proper first-class functions? Not sure.

why generics? Have you really understood how to write Go? Generics are not needed, you have interfaces.

Re: Go After 2 Years in Production

#80

Post by scott_s »

winter_blue wrote: post #70
m0th87 wrote: post #38

Earlier quoted context omitted.

> I think Scala is an Academic language Sometimes "academic" seems like a catch-all for stuff people don't like. Scheme has a strong academic history in its use and implementation, yet it seems to be described as "academic" only when someone is unhappy with how minimalistic it is, which is the opposite issue described here.

Has anyone here used Haskell in a production environment? I want a language that is small, clean, and can provide a lot of static guarantees . I know many people find static guarantees and unacceptable curtailment of their "programming freedom", but frankly I think it's the answer to many of the problems we face in software today. Small is another thing. E.g. Go and Scheme are small . C++ and Scala are large . You kn…

User thirsteh talked about his experiences with Haskell in production yesterday: https://news.ycombinator.com/item?id=6278588
Post reply on HN