The majority of Flywheel code is written in Go, a fact we mention only to dispel any remaining notion that Go is not
a robust, production-ready language and runtime environment.
> If I could get out of the 1970s and use an editor other than vi, maybe I would get some help from an IDE in this regard, but I staunchly refuse to edit code with any tool that requires using a mouse.
Ob"Fallacy of the excluded middle": you can get this kind of contextual information in emacs pretty easily.
Coming from an Erlang on Emacs background, does vim not allow you to follow variable declarations to their definitions or otherwise get contextually relevant information?
Could someone familiar with the Go ecosystem comment on how well Go works with relational and NoSQL databases? Specifically, I'm interested in libraries that serve an ORM (or ORM-like) function, or that are non-blocking.
For example, in the Java world, libraries like jOOQ[1] make type-safe SQL construction a breeze and allow you to make your relational schema a "first-class citizen" of your app, versus a mere afterthought of how your ORM happens to represent them.
Or in the Scala world, there's a non-blocking MongoDB driver called ReactiveMongo[2].
Would love to hear how this compares to the Golang ecosystem.
From my (rather limited) experience, dealing with arbitrary structures in Go is a bit of a pain, as you end up having to manually create types for all of the various possible "shapes". UNlike, say, Python, where you can just return a dict or tuple of arbitrary contents.
My open source NoSQL database, Aerospike, has made a strong commitment to Go. I first posted to golang-nuts in 2009, and our native Go client has been out for a while ( https://github.com/aerospike/aerospike-client-go ). We've supported the GothamGo meetup, which was a great session if anyone was in NYC that saturday.
Shameless plug over, please forgive me, but you did ask about Go and NoSQL.
"non-blocking" is kind of a funny concept in go, because since they have green threads, even what might seem blocking isn't "really" blocking. Not sure quite what you mean - do you really mean "using channels and goroutines as the interface" ?
The comment about Go's typing system not working well with NoSQL is certainly true. I find it's annoying working with JSON - similar problem - but the JSON tools have these nice ways of tagging your fields with the JSON fields for easy conversion. We might have to look at this with Aerospike.
I spent time with one company, LiquidM in Berlin, who rewrote a PHP production system ( that's not "muscular C developers" :-) and had a very, very positive experience. They told me their switchover to GoLang was incredible, with line counts reduced massively (like 3x) and performance up 10x and programmer productivity way up. I was trying to find a blog post about their experience, but nothing's coming up.
The most annoying problem with Go is its lack of performance compared to JVM (including probably Scala), where common operations are usually 2x ~ 3x faster runtime, in production. In my opinion, the GoLang people need to stop blaming their garbage collector, because even with GC off Go is far slower.
The GoLang argument is code is easier and funner to write, which is certainly true, and Go is still an evolving implementation.
Go's big thrust this year is solid support for ARM, likely so they can support Android well. I'm running Go on my Raspberry Pi2 (and my original Pis, but they only have one core so it seems a little dumb). It is a fun language.
On the topic of rewriting, has anyone had difficulty refactoring Go code? Having the compiler scream at you whenever you decide to leave a variable undeclared seems to make this more challenging as opposed to just having your IDE point out to you a variable is unused.
17 comments
[ 4.3 ms ] story [ 44.6 ms ] threadThe majority of Flywheel code is written in Go, a fact we mention only to dispel any remaining notion that Go is not a robust, production-ready language and runtime environment.
[1]: http://research.google.com/pubs/pub43447.html
Ob"Fallacy of the excluded middle": you can get this kind of contextual information in emacs pretty easily.
Like Acme.
For example, in the Java world, libraries like jOOQ[1] make type-safe SQL construction a breeze and allow you to make your relational schema a "first-class citizen" of your app, versus a mere afterthought of how your ORM happens to represent them.
Or in the Scala world, there's a non-blocking MongoDB driver called ReactiveMongo[2].
Would love to hear how this compares to the Golang ecosystem.
[1] http://www.jooq.org/ [2] http://reactivemongo.org/
Shameless plug over, please forgive me, but you did ask about Go and NoSQL.
"non-blocking" is kind of a funny concept in go, because since they have green threads, even what might seem blocking isn't "really" blocking. Not sure quite what you mean - do you really mean "using channels and goroutines as the interface" ?
The comment about Go's typing system not working well with NoSQL is certainly true. I find it's annoying working with JSON - similar problem - but the JSON tools have these nice ways of tagging your fields with the JSON fields for easy conversion. We might have to look at this with Aerospike.
I spent time with one company, LiquidM in Berlin, who rewrote a PHP production system ( that's not "muscular C developers" :-) and had a very, very positive experience. They told me their switchover to GoLang was incredible, with line counts reduced massively (like 3x) and performance up 10x and programmer productivity way up. I was trying to find a blog post about their experience, but nothing's coming up.
The most annoying problem with Go is its lack of performance compared to JVM (including probably Scala), where common operations are usually 2x ~ 3x faster runtime, in production. In my opinion, the GoLang people need to stop blaming their garbage collector, because even with GC off Go is far slower.
The GoLang argument is code is easier and funner to write, which is certainly true, and Go is still an evolving implementation.
Go's big thrust this year is solid support for ARM, likely so they can support Android well. I'm running Go on my Raspberry Pi2 (and my original Pis, but they only have one core so it seems a little dumb). It is a fun language.