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.<p>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?<p>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.<p>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.<p>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?".<p>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.<p>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—<i>cough</i>—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.<p>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.<p>(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).<p>Thanks for reading.
Ask HN: Is Google's Go ready for serious projects?