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.
Oh, painful point, I still try to ignore Scala's compile time and hope it will improve in the future, (it does gradually on every release) but when I do, then Scala feels a bit more natural to me than Go (it feels closer to Ruby for me, which I like, and has the Java interop aspect, which I unfortunately need). I just close my eyes, do sbt ~test-quick, and hope for the best. It's just that Scala feels to me more like a statically typed Ruby, where in Go I need to shift some paradigms and do some mental twists to accept how great it is.
"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.
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.
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.
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.
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.
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 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:
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.
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.
The analogy is a little flimsy, but I'll run with it anyway: I consider Go today to be similar in some ways to Java at around the time of Java 1.1 or 1.2.
Obviously, Go is modern and is in many ways better than today's Java 1.7. But I am trying to illustrate its maturity level and the trajectory that I believe it's on. If you recall the days of Java 1.1, it was already seeing a great deal of early traction. The early traction of Go seems roughly the same to me. Also Java in its 1.1/1.2 years was on a clear trajectory to become a dominant language. I think Go will only grow in popularity for years to come in the same fashion. Even as a primarily Java developer, I look forward to Go being a clear and viable alternative.
I could be wrong about the trajectory, of course.
But I believe a short answer to your question is: if you're considering it, take some time to actually do something with Go. At first something experimental, then something for production use.
As a long-time JVM user, I've been trying to explain to other developers for a while now that assuming you use a modern approach to Java development, the performance of the JVM allows you to be (in my opinion) even more efficient than a dynamic language because you can code your application fairly recklessly. You can defer optimization in all of its forms for a long time, perhaps infinitely. The resulting mindset is a dramatically reduced concern about performance. When I work with most dynamic languages, I can never fully set aside the inner voice saying, "this is going to perform like crap." Trouble is, the voice is often right.
Go brings the same ballpark of performance as the JVM and a style that I believe is more appealing to Python developers than a modern Java stack (although I don't think modern Java stacks are given much of a fair shake because of Java's legacy, but that's a separate rant entirely).
> 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.
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.
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".
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.
(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:
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.
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.
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...
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.
[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.
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 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.
[+] [-] programminggeek|12 years ago|reply
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.
[+] [-] eranation|12 years ago|reply
[+] [-] swah|12 years ago|reply
[+] [-] carimura|12 years ago|reply
[+] [-] illumen|12 years ago|reply
[+] [-] jd007|12 years ago|reply
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.
[+] [-] jerf|12 years ago|reply
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.
[+] [-] bhauer|12 years ago|reply
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.
[+] [-] paddyforan|12 years ago|reply
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.
[+] [-] neya|12 years ago|reply
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 ;)
[+] [-] bitcrusher|12 years ago|reply
I must be missing something.
[+] [-] Pxtl|12 years ago|reply
[+] [-] rprospero|12 years ago|reply
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.
[+] [-] bpodgursky|12 years ago|reply
[+] [-] dancric|12 years ago|reply
[+] [-] bhauer|12 years ago|reply
Obviously, Go is modern and is in many ways better than today's Java 1.7. But I am trying to illustrate its maturity level and the trajectory that I believe it's on. If you recall the days of Java 1.1, it was already seeing a great deal of early traction. The early traction of Go seems roughly the same to me. Also Java in its 1.1/1.2 years was on a clear trajectory to become a dominant language. I think Go will only grow in popularity for years to come in the same fashion. Even as a primarily Java developer, I look forward to Go being a clear and viable alternative.
I could be wrong about the trajectory, of course.
But I believe a short answer to your question is: if you're considering it, take some time to actually do something with Go. At first something experimental, then something for production use.
As a long-time JVM user, I've been trying to explain to other developers for a while now that assuming you use a modern approach to Java development, the performance of the JVM allows you to be (in my opinion) even more efficient than a dynamic language because you can code your application fairly recklessly. You can defer optimization in all of its forms for a long time, perhaps infinitely. The resulting mindset is a dramatically reduced concern about performance. When I work with most dynamic languages, I can never fully set aside the inner voice saying, "this is going to perform like crap." Trouble is, the voice is often right.
Go brings the same ballpark of performance as the JVM and a style that I believe is more appealing to Python developers than a modern Java stack (although I don't think modern Java stacks are given much of a fair shake because of Java's legacy, but that's a separate rant entirely).
[+] [-] waterside81|12 years ago|reply
http://blog.repustate.com/migrating-code-from-python-to-gola...
I love using Go and I'm a Python guy through & through.
[+] [-] kintamanimatt|12 years ago|reply
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.
[+] [-] nknighthb|12 years ago|reply
[+] [-] eblume|12 years ago|reply
[+] [-] txutxu|12 years ago|reply
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.
[+] [-] melling|12 years ago|reply
http://en.wikipedia.org/wiki/Dalvik_(software)#Performance
Go compiles to native, so "compile on install", would probably be needed.
[+] [-] binarycrusader|12 years ago|reply
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.
[+] [-] programminggeek|12 years ago|reply
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.
[+] [-] lttlrck|12 years ago|reply
[+] [-] pjbringer|12 years ago|reply
That said, not having run into a problem is a worthwhile feedback.
[+] [-] ulisesrmzroche|12 years ago|reply
[+] [-] BarkMore|12 years ago|reply
[+] [-] genwin|12 years ago|reply
[+] [-] toqueteos|12 years ago|reply
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|12 years ago|reply
[+] [-] pcwalton|12 years ago|reply
Then why post?
[+] [-] dodyg|12 years ago|reply
[+] [-] zurn|12 years ago|reply
[+] [-] knodi|12 years ago|reply
[+] [-] stephenitis|12 years ago|reply
[+] [-] enneff|12 years ago|reply
[+] [-] netcraft|12 years ago|reply
[+] [-] carimura|12 years ago|reply
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.
[+] [-] anfleene|12 years ago|reply
[+] [-] paddyforan|12 years ago|reply