14 ms·

Go After 2 Years in Production

323 points by treeder 13y ago

melling 13y ago
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 http://en.wikipedia.org/wiki/Dalvik_(software)#Performance Go compiles to native, so "compile on install", would probably be needed.
- programminggeek 13y ago
  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.
  - melling 13y ago
    I didn't say get everyone to build apps. It would simply be another option. App development is getting more competitive, of course, so people that want to stand out might need to move to Go to gain an edge. Plus, I image that a Go environment might provide a better interactive development cycle.
    - programminggeek 13y ago
      Yeah totally. I'm with you there. It would be great and I hope they do it.
  - jlarocco 13y ago
    I'm not so sure. There's no lack of iOS developers, and most of them are using Objective-C...
- lttlrck 13y ago
  NDK on Android is native (C++/C) and it's there to boost performance and avoid GC in game loops. I've seen too many devs discussing how to mitigate the effects of GC in games to consider Go to be a worthy upgrade at this point in it's development, the NDK would probably still be needed...
  - rdtsc 13y ago
    Go has a GC so still not sure that would help. You'd have to benchmark it though, it might not matter.
- binarycrusader 13y ago
  (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 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.
dancric 13y ago
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 edge, but the language seems to have developed far faster than Python did over the last decade or so.
- eblume 13y ago
  Only one way to know that: give it a try!
  - dancric 13y ago
    Good point!
- kintamanimatt 13y ago
  > I would love to know when would be a good time to start using Go in serious production work Now would be a good time. No language, runtime, compiler, library, or framework is ever going to be perfect, but now is a great time to dive in. > It still seems bleeding edge This is probably a good thing in many respects because Go doesn't have the baggage from yore, and it was created by some pretty smart and capable people. > but the language seems to have developed far faster than Python did over the last decade or so Language designers are getting better at marketing. No language succeeds without fantastic marketing.
  - gnur 13y ago
    Exactly, there is never a better moment to start learning something new then now.
  - danieldk 13y ago
    This is probably a good thing in many respects because Go doesn't have the baggage from yore, and it was created by some pretty smart and capable people. As was Javascript plus Node.js two years ago, Ruby and RoR five years ago, etc. You'd think that more reasons are required than 'it is new, doesn't have baggage in was created by smart people'.
programminggeek 13y ago
Go seems to be hitting some kind of tipping point where it's going from being more of a niche thing with a small user base to something with a broader appeal. I don't think that it's because go is changing so much as the kinds of problems people are encountering writing web services that need to scale (or at least have that option). I've been comparing go to scala lately and what has really got me into go is the development speed. The fast compiles and fast web page auto-reload make it feel every bit as fast to develop in as ruby or python or php, but with type safety, fewer tests, and very clean code. Scala is a fantastic language, but even with jrebel autoreload you still have 2-3 second page reloads and a 5 second test suite reload. That seems like a small thing, but the faster I see code change results, the more hooked I am to the process. A 5 second wait is probably enough to get me out of the zone. With go, on just a default simple test of a small thing it is less than a second to compile/run. In revel, pages reload/update as fast/faster than they do in rails/sinatra. Oh, and with go, each web request will run in a separate goroutine, so you get excellent nonblocking IO performance without dealing with the callback soup of node.js. It might just be irrational exuberance because I haven't built anything big and messy yet, but so far go is seriously fantastic and solves a lot of real world problems elegantly.
- illumen 13y ago
  So you've enjoyed all the marketing and Google employee upvoting?
  - untog 13y ago
    So you ignored the part where the OP described having actually used it in development and liking it?
    - weego 13y ago
      I think we need more than 1 account of Go in production before we start high-fiving each other about Go in the mainstream. And to be fair to the person you are responding too, there has been an inordinate amount of Go articles on HN over the last few months compared to anywhere else on the internet tech/dev wise, so much so that a number of my friends have independently made a joke of it.
Pxtl 13y ago
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.
- rprospero 13y ago
  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-3ac))/(2*a) On the other hand, if I wrote server code, operator overloading would be far less useful. I'd probably curse any programmer who used it and thank the gods that it was left out of Go. Conversely, since I write a lot of numerical code, I don't care about generics or typing, which is crucial to many other programmers. Generics don't matter since everything I work with is either a Double or a collection of Doubles. Similarly, static typing doesn't help, since most functions just have the type (Double -> Double) and the type checker can't tell a sine from a logarthim. Of course, the reverse is also true. Since everything is either a double or a collection of doubles, the fancy tricks that dynamic languages offer don't give me a damn thing, so I'm extremely ambivalent about the typing debate. Of course, on other projects, I've written code that benefited from static typing and I've written valid code that would choke any type checker. I've written code that heavily needed generics. When I did that, I used the languages that had the features I needed. Go just won't work for the programs I write and it sounds like it doesn't work for yours, either. That's why we won't use Go. I've heard it works wonderfully for a certain class of server software and I'm glad those guys have a useful language for their domain. If I ever have to write another server, I might even teach myself Go. But don't feel guilty that you're using an old hammer instead of the shiny new saw.
  - termain 13y ago
    Ambivalent or apathetic regarding the typing debate? Typing can become useful in numerical code when you move past operating on scalars. Column and row vectors needn't be confused, a two-vector and a complex number have different types, etc. Also, physical quantities can have different types and a type system can be useful there. I totally agree that for numerical code, operator overloading is of great utility.
bitcrusher 13y ago
I can't be the only person who thinks Go is really interesting, but can't get over the 'package' hump... It's just too wonky for 'real-world' from my experience. For example, how do you create clear lines of separation with internal modules? If you want to use 'namespaces' then each namespace has to be it's own package, which then requires its own Repo that you have to 'go get'. There's unsustainable for a project of any useful size. I must be missing something.
- BarkMore 13y ago
  Organize your packages in a directory tree. You can check the entire tree into a single repository. There's no requirement to put the code in a repository or use 'go get'. The page at http://golang.org/doc/code.html http://golang.org/doc/code.html explains how to organize code into packages.
- Game_Ender 13y ago
  Google has said they don't use 'go get' internally to manage dependencies, so they appear to agree with you.
  - gt384u 13y ago
    I would imagine this has something to do with having an existing package dependency management system company-wide and it causing friction trying to get the two to coexist. I have similar issues where I work with trying to integrate an internal build system and rubygems. Our answer is to essentially mirror the gem version internally into our own repo. It's not the best answer I could hope for.
- trevordixon 13y ago
  Exactly what I've been wondering. I've done `import "./[internal_module]" in some of my little experiments, but I've read that's unacceptable.
  - BarkMore 13y ago
    Absolute import paths are preferred. If the import path for the importing package is [app], then import the package using `import "[app]/[internal_module]"`.
jd007 13y ago
"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.
- bhauer 13y ago
  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 languages end up being a bigger bottleneck than modern databases. Sometimes this is masked somewhat by the fact that the database drivers and/or ORM are slow, so from the application's perspective, the "database" is the bottleneck. But one should not confuse the drivers and ORM for the database.
  - jd007 13y ago
    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.
    - bhauer 13y ago
      "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.
neya 13y ago
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 common imperative model. But you know, there's a problem with that. Not with the language itself, but with the web development side of Scala. There's only certain ways by which you can program with a particular function that accepts a request and returns a response. So, most of the time, I would find myself wasting time thinking "How can I make this more functional?" Functional programming is really great when you can actually enforce it - When writing algorithms and so forth, but otherwise, you are forced to fallback to this imperative model which sucks, because you have to constantly keep changing your mindset between these two models. 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. I've advocated Scala to many HN members here in the past, you can even check out my comments, for instance. But from my experience, I think Scala is an Academic language. But it's superior in its own ways - I just LOVE the concept of avoiding nulls and passing an Option. It's beautiful. But the downside is its huge academic complex syntax. I want to be able to write code which shouldn't reduce my hair count even if I look at it after 6 long months. I don't want to refer to an 800 page book each time I'm confused about something. That's why I think Go is beautiful. The syntax is just enough to keep it inside your head forever. I fear that as the language matures, this might also evolve into something as complex as Scala, but let's hope not so. Go isn't a magic bullet though. It has its own downsides, but nothing w.r.t performance or similar. For the most part, it's awesome. Once you go Go, you never go back. P.s - I still love Scala as well ;)
- m0th87 13y ago
  > 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.
txutxu 13y ago
I wish we could know what happens "after 12 years in production" (just 10 more). Update: Sorry if someone did feel offended (the negative voting), I said it with my best and more constructive intention. In my opinion, the problem is not in the content of my comment. Well, maybe, if someone understands it as: "oh, can't argue against that, is attacking the language" instead of, "let run your imagination to 2023". Have a nice day/night.
ulisesrmzroche 13y ago
Anyone got a good tutorial on Go? I'm interested in fiddling around with it.
- BarkMore 13y ago
  http://tour.golang.org/#1 http://tour.golang.org/#1
  - ulisesrmzroche 13y ago
    Sweet, thanks Barkmore!
- genwin 13y ago
  Beyond the online tutorials and e-books, I've found the book Programming in Go (by Mark Summerfield) to be an excellent reference.
  - ulisesrmzroche 13y ago
    Just kindled that up thanks dude. I'm going to see what what all the buzz is about.
pjbringer 13y ago
It's a shame they have actually converted a real system, and they rely on the language benchmark to make an argument about performance. That said, not having run into a problem is a worthwhile feedback.
netcraft 13y ago
on an unrelated (to golang) note, does anyone have any experience they would like to share about iron.io? especially it vs rabbitmq or amazon sqs?
- paddyforan 13y ago
  We're friendly. Drop by get.iron.io/chat and we'll answer any and all questions you may have. :)
  - carimura 13y ago
    that too.
- carimura 13y ago
  [Disclaimer/Warning I work there and this is about Iron.] Vs RabbitMQ: - Native cloud service over HTTP transport - Clean easy API - Scales to unlimited queues/clients - Push queues can have URL endpoints as subscribers - Highly available (our #1 priority is to keep it running at all times) - Nice UI to manage queues, stats, rate, etc. - IronWorker integration (workers as a service) Vs SQS: - Fast, clean API - FIFO - One time delivery - Multi-cloud - Push queues / pubsub / fanout as first class feature - IronWorker integration (workers as a service) Best way is to just try it out. It's already one of the leading cloud MQ's out there and we have a lot of big plans for IronMQ to make it the safest "bet your business" cloud message queue available.
  - rabbitmq 13y ago
    RabbitMQ supports HTTP and has a clean easy API. Scales in lots of ways. Supports very high throughput on a single cheap AMI. Has awesome GUI and UI. Etc. YMMV.
- anfleene 13y ago
  I've used IronMq in production for about 6 months. It's easy to use but the uptime is terrible http://status.iron.io/history http://status.iron.io/history so if the messages are time sensitive I wouldn't recommend it. You should also queue the messages locally to ensure they end up in IronMq at all.
toqueteos 13y ago
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.
- eevee 13y ago
  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.
  - wtf_is_up 13y ago
    The Go team at Google consists of a handful of people: http://thechangelog.com/100/ http://thechangelog.com/100/
    - pcwalton 13y ago
      Please, let's not have an argument over which dev team is smarter. The fact is that Go and Rust are very different languages with different goals and feature sets, with different levels of ambitiousness and which started development in earnest at different times.
      - enneff 13y ago
        Agreed. There is room in this world for both projects to succeed, and I hope they do.
      - wtf_is_up 13y ago
        That's not what I meant. I was just replying to parent that was, to me, implying that Google had a huge team working on Go.
- pcwalton 13y ago
  > Not so relevant Then why post?
dodyg 13y ago
This is awesome. I much prefer this to "we rewrite some stuff with Go" articles.
stephenitis 13y ago
I would love to see codeacademy, codeschool, treehouse, and the online course community to jump on creating go curriculum.
- enneff 13y ago
  http://tour.golang.org/ http://tour.golang.org/
knodi 13y ago
Being using go for a year now. Really enjoying using it.
zurn 13y ago
Interesting that Go lost so heavily to Ruby on amount of code (~ 3x more on average.)

323 points by treeder 13y ago

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 http://en.wikipedia.org/wiki/Dalvik_(software)#Performance Go compiles to native, so "compile on install", would probably be needed.

programminggeek 13y ago
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.
- melling 13y ago
  I didn't say get everyone to build apps. It would simply be another option. App development is getting more competitive, of course, so people that want to stand out might need to move to Go to gain an edge. Plus, I image that a Go environment might provide a better interactive development cycle.
  - programminggeek 13y ago
    Yeah totally. I'm with you there. It would be great and I hope they do it.
- jlarocco 13y ago
  I'm not so sure. There's no lack of iOS developers, and most of them are using Objective-C...
lttlrck 13y ago
NDK on Android is native (C++/C) and it's there to boost performance and avoid GC in game loops. I've seen too many devs discussing how to mitigate the effects of GC in games to consider Go to be a worthy upgrade at this point in it's development, the NDK would probably still be needed...
- rdtsc 13y ago
  Go has a GC so still not sure that would help. You'd have to benchmark it though, it might not matter.
binarycrusader 13y ago
(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 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.

dancric 13y ago

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 edge, but the language seems to have developed far faster than Python did over the last decade or so.

eblume 13y ago
Only one way to know that: give it a try!
- dancric 13y ago
  Good point!
kintamanimatt 13y ago
> I would love to know when would be a good time to start using Go in serious production work Now would be a good time. No language, runtime, compiler, library, or framework is ever going to be perfect, but now is a great time to dive in. > It still seems bleeding edge This is probably a good thing in many respects because Go doesn't have the baggage from yore, and it was created by some pretty smart and capable people. > but the language seems to have developed far faster than Python did over the last decade or so Language designers are getting better at marketing. No language succeeds without fantastic marketing.
- gnur 13y ago
  Exactly, there is never a better moment to start learning something new then now.
- danieldk 13y ago
  This is probably a good thing in many respects because Go doesn't have the baggage from yore, and it was created by some pretty smart and capable people. As was Javascript plus Node.js two years ago, Ruby and RoR five years ago, etc. You'd think that more reasons are required than 'it is new, doesn't have baggage in was created by smart people'.

programminggeek 13y ago

Go seems to be hitting some kind of tipping point where it's going from being more of a niche thing with a small user base to something with a broader appeal. I don't think that it's because go is changing so much as the kinds of problems people are encountering writing web services that need to scale (or at least have that option). I've been comparing go to scala lately and what has really got me into go is the development speed. The fast compiles and fast web page auto-reload make it feel every bit as fast to develop in as ruby or python or php, but with type safety, fewer tests, and very clean code. Scala is a fantastic language, but even with jrebel autoreload you still have 2-3 second page reloads and a 5 second test suite reload. That seems like a small thing, but the faster I see code change results, the more hooked I am to the process. A 5 second wait is probably enough to get me out of the zone. With go, on just a default simple test of a small thing it is less than a second to compile/run. In revel, pages reload/update as fast/faster than they do in rails/sinatra. Oh, and with go, each web request will run in a separate goroutine, so you get excellent nonblocking IO performance without dealing with the callback soup of node.js. It might just be irrational exuberance because I haven't built anything big and messy yet, but so far go is seriously fantastic and solves a lot of real world problems elegantly.

illumen 13y ago
So you've enjoyed all the marketing and Google employee upvoting?
- untog 13y ago
  So you ignored the part where the OP described having actually used it in development and liking it?
  - weego 13y ago
    I think we need more than 1 account of Go in production before we start high-fiving each other about Go in the mainstream. And to be fair to the person you are responding too, there has been an inordinate amount of Go articles on HN over the last few months compared to anywhere else on the internet tech/dev wise, so much so that a number of my friends have independently made a joke of it.

Pxtl 13y ago

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.

rprospero 13y ago
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-3ac))/(2*a) On the other hand, if I wrote server code, operator overloading would be far less useful. I'd probably curse any programmer who used it and thank the gods that it was left out of Go. Conversely, since I write a lot of numerical code, I don't care about generics or typing, which is crucial to many other programmers. Generics don't matter since everything I work with is either a Double or a collection of Doubles. Similarly, static typing doesn't help, since most functions just have the type (Double -> Double) and the type checker can't tell a sine from a logarthim. Of course, the reverse is also true. Since everything is either a double or a collection of doubles, the fancy tricks that dynamic languages offer don't give me a damn thing, so I'm extremely ambivalent about the typing debate. Of course, on other projects, I've written code that benefited from static typing and I've written valid code that would choke any type checker. I've written code that heavily needed generics. When I did that, I used the languages that had the features I needed. Go just won't work for the programs I write and it sounds like it doesn't work for yours, either. That's why we won't use Go. I've heard it works wonderfully for a certain class of server software and I'm glad those guys have a useful language for their domain. If I ever have to write another server, I might even teach myself Go. But don't feel guilty that you're using an old hammer instead of the shiny new saw.
- termain 13y ago
  Ambivalent or apathetic regarding the typing debate? Typing can become useful in numerical code when you move past operating on scalars. Column and row vectors needn't be confused, a two-vector and a complex number have different types, etc. Also, physical quantities can have different types and a type system can be useful there. I totally agree that for numerical code, operator overloading is of great utility.

bitcrusher 13y ago

I can't be the only person who thinks Go is really interesting, but can't get over the 'package' hump... It's just too wonky for 'real-world' from my experience. For example, how do you create clear lines of separation with internal modules? If you want to use 'namespaces' then each namespace has to be it's own package, which then requires its own Repo that you have to 'go get'. There's unsustainable for a project of any useful size. I must be missing something.

BarkMore 13y ago
Organize your packages in a directory tree. You can check the entire tree into a single repository. There's no requirement to put the code in a repository or use 'go get'. The page at http://golang.org/doc/code.html http://golang.org/doc/code.html explains how to organize code into packages.
Game_Ender 13y ago
Google has said they don't use 'go get' internally to manage dependencies, so they appear to agree with you.
- gt384u 13y ago
  I would imagine this has something to do with having an existing package dependency management system company-wide and it causing friction trying to get the two to coexist. I have similar issues where I work with trying to integrate an internal build system and rubygems. Our answer is to essentially mirror the gem version internally into our own repo. It's not the best answer I could hope for.
trevordixon 13y ago
Exactly what I've been wondering. I've done `import "./[internal_module]" in some of my little experiments, but I've read that's unacceptable.
- BarkMore 13y ago
  Absolute import paths are preferred. If the import path for the importing package is [app], then import the package using `import "[app]/[internal_module]"`.

jd007 13y ago

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

bhauer 13y ago
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 languages end up being a bigger bottleneck than modern databases. Sometimes this is masked somewhat by the fact that the database drivers and/or ORM are slow, so from the application's perspective, the "database" is the bottleneck. But one should not confuse the drivers and ORM for the database.
- jd007 13y ago
  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.
  - bhauer 13y ago
    "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.

neya 13y ago

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 common imperative model. But you know, there's a problem with that. Not with the language itself, but with the web development side of Scala. There's only certain ways by which you can program with a particular function that accepts a request and returns a response. So, most of the time, I would find myself wasting time thinking "How can I make this more functional?" Functional programming is really great when you can actually enforce it - When writing algorithms and so forth, but otherwise, you are forced to fallback to this imperative model which sucks, because you have to constantly keep changing your mindset between these two models. 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. I've advocated Scala to many HN members here in the past, you can even check out my comments, for instance. But from my experience, I think Scala is an Academic language. But it's superior in its own ways - I just LOVE the concept of avoiding nulls and passing an Option. It's beautiful. But the downside is its huge academic complex syntax. I want to be able to write code which shouldn't reduce my hair count even if I look at it after 6 long months. I don't want to refer to an 800 page book each time I'm confused about something. That's why I think Go is beautiful. The syntax is just enough to keep it inside your head forever. I fear that as the language matures, this might also evolve into something as complex as Scala, but let's hope not so. Go isn't a magic bullet though. It has its own downsides, but nothing w.r.t performance or similar. For the most part, it's awesome. Once you go Go, you never go back. P.s - I still love Scala as well ;)

m0th87 13y ago
> 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.

txutxu 13y ago

I wish we could know what happens "after 12 years in production" (just 10 more). Update: Sorry if someone did feel offended (the negative voting), I said it with my best and more constructive intention. In my opinion, the problem is not in the content of my comment. Well, maybe, if someone understands it as: "oh, can't argue against that, is attacking the language" instead of, "let run your imagination to 2023". Have a nice day/night.

ulisesrmzroche 13y ago

Anyone got a good tutorial on Go? I'm interested in fiddling around with it.

BarkMore 13y ago
http://tour.golang.org/#1 http://tour.golang.org/#1
- ulisesrmzroche 13y ago
  Sweet, thanks Barkmore!
genwin 13y ago
Beyond the online tutorials and e-books, I've found the book Programming in Go (by Mark Summerfield) to be an excellent reference.
- ulisesrmzroche 13y ago
  Just kindled that up thanks dude. I'm going to see what what all the buzz is about.

pjbringer 13y ago

It's a shame they have actually converted a real system, and they rely on the language benchmark to make an argument about performance. That said, not having run into a problem is a worthwhile feedback.

netcraft 13y ago

on an unrelated (to golang) note, does anyone have any experience they would like to share about iron.io? especially it vs rabbitmq or amazon sqs?

paddyforan 13y ago
We're friendly. Drop by get.iron.io/chat and we'll answer any and all questions you may have. :)
- carimura 13y ago
  that too.
carimura 13y ago
[Disclaimer/Warning I work there and this is about Iron.] Vs RabbitMQ: - Native cloud service over HTTP transport - Clean easy API - Scales to unlimited queues/clients - Push queues can have URL endpoints as subscribers - Highly available (our #1 priority is to keep it running at all times) - Nice UI to manage queues, stats, rate, etc. - IronWorker integration (workers as a service) Vs SQS: - Fast, clean API - FIFO - One time delivery - Multi-cloud - Push queues / pubsub / fanout as first class feature - IronWorker integration (workers as a service) Best way is to just try it out. It's already one of the leading cloud MQ's out there and we have a lot of big plans for IronMQ to make it the safest "bet your business" cloud message queue available.
- rabbitmq 13y ago
  RabbitMQ supports HTTP and has a clean easy API. Scales in lots of ways. Supports very high throughput on a single cheap AMI. Has awesome GUI and UI. Etc. YMMV.
anfleene 13y ago
I've used IronMq in production for about 6 months. It's easy to use but the uptime is terrible http://status.iron.io/history http://status.iron.io/history so if the messages are time sensitive I wouldn't recommend it. You should also queue the messages locally to ensure they end up in IronMq at all.

toqueteos 13y ago

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.

eevee 13y ago
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.
- wtf_is_up 13y ago
  The Go team at Google consists of a handful of people: http://thechangelog.com/100/ http://thechangelog.com/100/
  - pcwalton 13y ago
    Please, let's not have an argument over which dev team is smarter. The fact is that Go and Rust are very different languages with different goals and feature sets, with different levels of ambitiousness and which started development in earnest at different times.
    - enneff 13y ago
      Agreed. There is room in this world for both projects to succeed, and I hope they do.
    - wtf_is_up 13y ago
      That's not what I meant. I was just replying to parent that was, to me, implying that Google had a huge team working on Go.
pcwalton 13y ago
> Not so relevant Then why post?

dodyg 13y ago

This is awesome. I much prefer this to "we rewrite some stuff with Go" articles.

stephenitis 13y ago

I would love to see codeacademy, codeschool, treehouse, and the online course community to jump on creating go curriculum.

enneff 13y ago
http://tour.golang.org/ http://tour.golang.org/

knodi 13y ago

Being using go for a year now. Really enjoying using it.

zurn 13y ago

Interesting that Go lost so heavily to Ruby on amount of code (~ 3x more on average.)