Ask HN: Is Google's Go ready for serious projects?
3 comments
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.
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.
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.
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.
It's almost like you didn't read a single word beyond the title of the initial post.
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.
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.
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 ...
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
Thanks! I quoted this one as it is very simple (about 10-12 lines of code) and hence crying to be extended :)
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?
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.