Ask HN: Is Google's Go ready for serious projects?

I've spent the last few weeks re-learning C to write a simple server for my startup. The last time I wrote any C, I was in college and had only just finished "Learning to Program with Pascal". Re-approaching it as a more experienced programmer—and one used to newer, more dynamic languages, at that—I've found it pretty frustrating.

C has frustrated me not because more lines are required to get things done, or because malloc'd memory must be freed. (I understand what kind of language C is and what it is designed to do). I'm frustrated by the inherent problems of macros and the constraining nature of static typing. I think my frustrations are best summed up by this thought experiment: Imagine the only pre-processor directive was #include; with no #define or #if etc. What would C be like?

My take has been that a lot of what makes C so simple, and effective at achieving it's noble but relatively humble goals, also causes it to be greatly constraining. I think this is why the C pre-processor was introduced. The pre-processor attempts to tackle problems of excessive constraint. It sort of solves them (kinda), but also introduces a whole load of new ones.

In my most recent attempt, I'm using a couple of macros to generate readers and writers (of files) of a bunch of number types that my server uses. I'm pretty pleased with the results, but feel like I just pulled a big hack. (I can already picture the hardass purists on ##c telling me off for doing it). And I noticed what I was doing reminded me of Haskell typeclasses.

Another problem for me—a controversial problem, seeing as you have these in C++ and Objective-C as well—is header files. I really hate having to write those. I hate having to wrap them in #ifndefs and the decisions of where other header #includes should go. I can't help thinking "Why can't these be generated? Or inferred? And why do I have to write /almost/ the same thing again?".

In response to all this, I decided to watch that hour-long talk on Go again. I had good intentions; I was looking for ideas to better my C programming. But instead, perhaps unsurprisingly, it showed me more places where C was less-than-great; the shortcomings of the C const keyword were mentioned, as was the silliness of typed constants. That talk increased my frustration with C, and now I'm considering using Go to write my server.

What does using Go mean for me? I'll be able to use channels (whatever they are) and concurrency will be a lot easier (a problem I had chosen to—cough—defer, whilst I was working with C). It also looks like that typeclass-thing I was using macros for is formally emboddied by Go's "interfaces". This all sounds great but there's a concern: Go is a very new language. In a brief session on #go-nuts, I exchanged with someone trying out Go's regular expressions. We concluded that there was quite a glaring bug in the regular expression parser, which is slightly alarming although perhaps not surprising.

So, you're about up to date now, and I ask: Has anyone on HN tried Go? What do you think? Is it too new or buggy for a serious project? I am a lone developer and I'm prepared to be experimental, but it's important that this server be reliable.

(I have already considered Erlang for this project but decided it wouldn't give me the low-level control I wanted, and dismissed Haskell for the same reason; I'm steering clear of C++ for all the reasons previously discussed on HN; Objective-C seems to compete more directly with Go but it's still a superset of C, so I imagine it suffers from similar problems).

Thanks for reading.