I've written a few thousand lines. A couple toy VMs/compilers, some web apps, some random graphical tinkering. Nothing big, but enough to feel like I've gotten a sense of the language. I started using it expecting to be annoyed by all of the features it doesn't have, but I ended up really liking it and not really missing much. It has become my go-to language for random tinkering and prototyping, in part because I always end up thinking about the code and never the language.
For me this was something I missed when I started with Go about a year ago (at that point my brain was still filled with years of C# dogma). I was not very familiar with Go's own way of doing things back then. Go may seem familiar at first glance, but there are some peculiar little differences which offer new and novel ways of dealing with a problem. Unfortunately these are very difficult to explain to someone who is not already familiar with the language.
At this point I don't miss generics at all. The benefit they would give me are marginal enough to not consider it a vital component.
I've found that when you become proficient in Go, you will write different code that does not really require generics to be present. At least 99% of the time.
Having said that, I am still hoping that we might one day get unions. Unfortunately there is little hope of that at this point. It has been considered, but they would have to be type-safe in order not to circumvent Go's type system. And doing so, would differentiate them very little from Go's existing 'interface{}' type. There is a small benefit to unions, but apparently not big enough to warrant implementing them.
As far as generics go, they are not out of the question. The problem so far has been that nobody has yet offered a generics proposal that doesn't partially or completely mess up the language and generally make things more difficult for everyone.
I have written BTrees and B+Trees in Go[1]. I wrote a Top Down Predictive Parser[2]. Currently a friend and I are writing a distributed network simulation.[3] I also maintain a fork of the gobuild project (a build system for go) which I have modified for my purposes.[4]
Written ~10k lines in total maybe more. I like the language. However, it has its limitations.
I've done several smaller projects in it (command-line tools, one-off programs, etc), and I've been building a small web app in it (as a learning exercise). I'm planning to post my results, and a brief tutorial when I get it finished. Curious if anyone (company or otherwise) has been doing anything bigger...
I use it for everything these days. I've written numerous web apps and we publishing apps as well as a few prototype game servers. It's a joy to program in.
Regarding the OP, Cgo is like magic since e.g. my PostgreSQL libpq wrapper provides a pretty rich PostgreSQL driver for Go in well under 400 LOC. Best of all, I can write most of it in pure Go itself! The grungy low-level C interface code is mostly auto-generated.
I have a lot of Go packages and apps on my github repos.
Nothing really very big (yet), but mostly 'scratching my itch' stuff. I do thoroughly enjoy writing Go code, which is why I stick with it. A large project where I can use it will present itself sooner or later.
I'm using it to write a ZX Spectrum emulator. Go is a neat language. It is expressive as an high-level language and - at the same time - it is powerful on the low-level side. Moreover, it has interesting built-in concurrency mechanisms. Last but not least, I like the fact that it is openly developed.
I've been patiently waiting for them to target shared libraries, so I could use it from inside of many different VMs or/and servers, from ruby/python/jvm to apache/nginx. Frankly I just don't see a need for Go executables. What will I do with them? Run in bash?
Cgo seems to me like one of the best (i.e. seamless) implementations of C integration (certainly better than e.g. generating wrappers with SWIG).
Can you elaborate what is so "dreadful" about it and which language does it better?
I'll give props to C# as one of the languages that does it very well, but most others don't (Java's jni is worse, Python before ctypes was worse, lua is worse - I could go on).
In terms of C integration, Objective-C wins, giving C priority even over it's own syntax :)
D has pretty nice integration - you can convert (reasonably non-hacky) C headers to D headers and use C functions and types almost as if they were D native.
Explicit type casts, even for most basic types like ulong and void* stuck me as very inelegant.
For known prototypes, it should be possible to do it much cleaner. There are various Objective-C bridges (e.g. PyObjC) which are able to seamlessly convert known C types and ObjC classes to equivalents in high(er)-level languages.
