

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

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.
======
mahmud
A better option might be to use Twisted Matrix for Python, iolib for Lisp, or
whatever high-performance networking library you can find for your dynamic
HLL.

Learning Go means learning a whole new language, learning the (still
primitive) tool chain, and scrambling for examples, documentation and support.

High performance network programming is a solved problem. You can do it in any
high level language that interfaces with C efficiently. Half a page of Unix
system call, some discipline, and you're on your way.

~~~
dkersten
Nevermind a lack of libraries.

How about erlang, haskell or clojure? If you must stick with a C-like
language, I second Twisted and Python, or maybe just use C.

~~~
olliesaunders
It's almost like you didn't read a single word beyond the title of the initial
post.

~~~
dkersten
Its completely like I read everything but the last paragraph.

If mahmuds suggestion of Python is Ok, then I don't see why mine isn't either.
The languages I listed are great for parallel/concurrent programming, much
more so than Go and if you need low level access, you can write C extensions
for just those parts that require low level access.

Go's concurrency support is weak, at best. Sure, its better than C (without
libraries), but compared to other concurrency oriented languages, it doesn't
really provide much. Other disadvantages are that Go is new and still under
heavy development. If they decide to change something, then you're code gets
obsoleted. You also have to use an immature toolchain, learn the intricacies
of a totally new language and compiler and live without existing Go libraries.
You could use C libraries, of course, but IMHO I don't see the value of using
Go. Maybe in the future it can take on its role as "better C", but I don't
believe its ready yet. If you want a "better C", try the D programming
language.

By the sounds of things, you don't like the archaic C-ness of the C/C++
languages. Honestly, I don't see Go as much of a step up (yet! I'm optimistic
that it could fill in its role as a better, safer C in the future), hence
suggesting languages with some top-notch concurrency support which have been
proven (well, not Clojure afaik) to work well in highly concurrent networked
environments. If you were to use erlang, you would get all its fault tolerance
and code hot swapping facilities almost for free too.

So.. no, I personally do not believe Go is ready for a serious project.

------
yannis
It is difficult to comment without knowing more as to why you need to _write_
a server, perhaps you care to give a few of the reasons. However, the way you
explained it, you need low level control. How about Lua, it has a beautiful
syntax, small footprint is ultrafast and interfaces very well with C (in many
ways you can think of it as a Library for C). (See
<http://code.google.com/p/lua-web-server/>). I know a lot of people consider
Lua only for games but ...

~~~
mascarenhas
There are more full-featured web servers written in Lua, too:
<http://github.com/keplerproject/xavante> and
<http://dev.alt.textdrive.com/browser/HTTP/HTTP.lua>

~~~
yannis
Thanks! I quoted this one as it is very simple (about 10-12 lines of code) and
hence crying to be extended :)

------
skybrian
There's no way to answer this question unless you say what the server is
supposed to do. Why do you need "low-level control"? How do you plan to deploy
the server when you're done? Who will maintain it?

