C? Go? Cgo | Hacker News Reader

C? Go? Cgo

blog.golang.org

79 pointsfogus24 comments

Just curious, and I apologize if this sounds snarky, that's not my intent, but is anyone here actually using Go for anything? If so, what?

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

Care to elaborate a little? I'll settle for links to previous posts if you have them.

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?

Communicate with them via IPC.

I find Go's channels a much more natural way to express things than Javascript callbacks, so I've been using it where everybody else is using Node.

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.

Has the absence of generic types been a problem for you?

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

[1] https://github.com/timtadh/Go-Filestructures

[2] https://github.com/timtadh/tdpp

[3] https://github.com/timtadh/Tecellate

[4] https://github.com/timtadh/gobuild-fork

Some open source things I've written in Go:

- A port from C of a fast prime number generator: https://github.com/jbarham/primegen.go

- A Cdb ("constant database") implementation: https://github.com/jbarham/cdb.go

- A Cgo PostgreSQL wrapper: https://github.com/jbarham/pgsql.go

- The beginnings of an AWS library: http://code.google.com/p/goaws/

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.

http://news.ycombinator.com/item?id=2335228 is another comment I made about programming in Go.

C Cgo. C Cgo go. Go Cgo go.

#include <something> are broken in code listings

Thanks, this has been fixed.

I've used it as a lightweight web server in several projects.

Have you fuzz tested it? How’d it fare?

What would I be fuzz testing, my own code? I do that always.

Cgo, goatse, c goatse go!

For a language based on C, it has dreadful C integration.

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.

Reply on news.ycombinator.com