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

81–90 of 178 posts

Re: Go After 2 Years in Production

#81

Post by obeattie »

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…

> it would be nice to be able to ascertain before running a program, certain time & space complexity bounds on it

I don't know about knowing what "space" a program will consume ahead of time, but I believe the halting problem[1] means there'd be no way of computing a time requirement.

[1] http://en.wikipedia.org/wiki/Halting_problem

Re: Go After 2 Years in Production

#82

Post by scott_s »

rprospero wrote: post #42
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.

It's not cliche, it's just personal. For instance, most of the code I write is numerical code. To that end, any language without operator overloading is a non-starter, since it's far harder to find a bug in: div(add(mult(-1,b),sqrt(sub(pow(b,2),mult(mult(3,a),c)))),mult(2,a)) than it is in (-b+sqrt(b^2-3 a c))/(2*a) On the other hand, if I wrote server code, operator overloading would be far less useful. I'd probably…

If you haven't seen Julia, you may want to give it a look: http://julialang.org/

Introduction to the manual: http://docs.julialang.org/en/release-0.1-0/manual/introducti...

Re: Go After 2 Years in Production

#83

Post by eevee »

toqueteos wrote: post #52

Not so relevant but for any of you who prefer Rust to Go and haven't tried Go, don't do it. Go's std, visibility by case and gofmt, among other things will make you cry for using Rust. I really hope Rust get's better with time and it really focuses on being developer friendly not just a bag of nice features.

Maybe we should do less crying and more contributing. Google has a bit more dev muscle to throw at projects than Mozilla, so community involvement is far more critical to Rust's health.

Re: Go After 2 Years in Production

#84

Post by binarycrusader »

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.

(disclaimer: My opinion on Go is based on my own limited experience from writing a few private projects using OpenGL.)

Go seems like an exercise in frustration to me at the moment for anything GUI or low-level OS-related.

Many GUI libraries use an object model that's difficult to map onto Go's heavily restricted interfaces, especially with a lack of generics.

In addition, interacting with popular libraries (such as libsdl or even OpenGL) that use thread-local variables (TLS) means using ugly workarounds like this one:

http://code.google.com/p/go-wiki/wiki/LockOSThread

So I think it really comes back to the "right tool for the right job." For most command-line utilities, and for anything networking-related, Go would be my first choice.

But for anything that needs a modern GUI toolkit and uses OpenGL, it would be difficult for me to justify.

Again, I love the model Go provides for programs and packages purely written in Go; it's only when interfacing with system-level components that I get cranky.

Re: Go After 2 Years in Production

#85

Post by bhauer »

jd007 wrote: post #74
bhauer wrote: post #58

Earlier quoted context omitted.

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 ha…

"Reasonably fast" is in the eye of the beholder.

In my opinion, many popular platforms and frameworks are not reasonably fast at providing a response in real-world applications. As a result, many web sites are frustratingly slow in my opinion (for example, a popular site used for hosting source code repositories). If those sites were to capture and share their profiling data (including time spent in drivers and the ORM), I would guess the database proper would not be as great a bottleneck as conventional wisdom says.

Perceived slowness is latency, and horizontal scaling doesn't necessarily address latency. Horizontal scaling may help alleviate an over-taxed CPU dealing with too many concurrent requests, but if a single request in isolation runs in 300ms, it will not run quicker than 300ms. It may run worse when contending for CPU capacity versus concurrent requests, but not better, unless a faster CPU is dropped in.

Performance matters, even in the world of horizontal scalability. Performance brings reduced latency (user experience) and reduced cost (size of cluster). If we can get that paired with an efficient, enjoyable developer experience, then yay for us.

Finally, "15 Go servers == 20 Python servers" seems a little unfair to Go.

Re: Go After 2 Years in Production

#86

Post by [deleted] »

paddyforan wrote: post #75
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'…

[deleted]

Re: Go After 2 Years in Production

#87

Post by zwieback »

rprospero wrote: post #42
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.

It's not cliche, it's just personal. For instance, most of the code I write is numerical code. To that end, any language without operator overloading is a non-starter, since it's far harder to find a bug in: div(add(mult(-1,b),sqrt(sub(pow(b,2),mult(mult(3,a),c)))),mult(2,a)) than it is in (-b+sqrt(b^2-3 a c))/(2*a) On the other hand, if I wrote server code, operator overloading would be far less useful. I'd probably…

Agree with what you're saying but I think you probably wanted 4ac

Re: Go After 2 Years in Production

#88

Post by bhauer »

Ziomislaw wrote: post #79
bhauer wrote: post #16

Earlier quoted context omitted.

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.

To be clear: I don't write Go professionally and I am not part of the "Generics or bust!" advocates. I'm agnostic.

I simply used it as an example of something that many would point to as evidence of Go's maturity level. If the language maintainers don't ever add generics to Go, I think I'd be comfortable with that. And if that's the way it plays out, eventually the design decision will be seen as firm and not a sign of immaturity.

Re: Go After 2 Years in Production

#90

Post by nexneo »

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.

Thats not true for Ruby or it needs lots of fine tuning to make this statement true.
Post reply on HN