I don't think tossing out the name of a popular alternative really contributes anything. I especially don't see what's 'reddit' about downvoting such a comment.
His comment was one made in good faith and included a sincere suggestion. Responses to his comment can educate him, the participants and the lurkers, which is where the contribution appears. Just because a comment doesn't instantly add to the conversation doesn't mean that it won't, given the good-natured participation of others.
Drive-by downvoting is what doesn't contribute anything in this case.
The thing is, there wasn't really an insightful question either. Just "Go. Discuss."
Perhaps if someone actually makes a detailed post on that subject then the post can be undownvoted. But at the moment there is no contribution, and the drive-by downvoting sorts it to the bottom, which is a good thing.
So you have the knowledge to judge the question uninsightful, but you don't lend your own insights. And instead of taking the trouble, you're content with the question being knocked down the page, which reduces the chances of anyone else doing it. Like I said, very Reddit. Would that we had a community more interested in illuminating than mercilessly judging.
I'll do it.
@aosmith: It's interesting, because Go's creators explicitly aimed it at the "systems" niche, which is what C was created to do, but C programmers don't seem to have picked up the baton the way Pike/etc hoped.
I think it comes down to a handful of things, in no particular order. YMMV, of course.
(1) Control. C gives you minute control over memory, Go of course does not. That's very satisfying and useful to many C programmers. Also, it's often helpful to have a good idea what your code is mapping to in terms of assembly instructions.
(2) Speed. Go still isn't anywhere near as fast as C in many, many cases.
(3) Portability. Lots of C programmers need (or get satisfaction from) the ability to compile C on a zillion platforms. Go supports only a few.
(4) Garbage collection. (Sorta a revisiting of point #1). Many C programmers don't want GC in their code. Now, while I wouldn't mind if my copy of 'less' used GC, some programmers would. I know I don't want GC freezing my game. So this is an issue, not one that will ever go away.
(5) Libraries. Go's made strides but can't touch C's library selection. Of course, you can use C libs from Go, but that has its own complications, and if the author already prefers C, why pick Go?
(6) Newness. In the context of systems languages, Go is still very new. Nobody's built an entire userspace out of it, ya know? Not that that's necessary, but certainly when the Unix programmer sits down and selects C, s/he knows anything can be built with it. It's long since passed into respectability. Go's on its way, but isn't there yet.
I'm sure there are a few other things. Don't think there's a way to run a runtime-less Go. As Damien mentioned, C has a bevy of tools, Go's selection is much more limited. I'm sure others can think of some more.
Thank you for the insightful response. I think you're mostly correct here, though there are, of course, subtleties.
Other than C and C++, Go is one of the best languages for controlling memory. Not freeing, of course, but making it very clear where there are allocations, where there are copies, exactly how much memory is being used by any particular data structure.
Portability - you can run binaries created by gccgo in many many places beyond amd64/x86/arm. No, certainly not as many as C... but probably as many as anyone would ever want to support. So unless you're targeting a specific embedded application, then Go is probably fine.
GC is getting a big push in Go and in 6 months they're going to make hard real time guarantees about the GC... i.e., no more than 10ms pause every 50ms, and the GC will be hybrid stop-the-world/concurrent, so some memory may be collected while other code continues to run.
Otherwise, yes, you're right, there are (of course) some limitations to using Go over C.
However, there are some huge benefits to using Go over C as well... such as memory safety. There will never be a buffer overflow in your code. Also, concurrent code will be a thousand times more readable and easier to reason about.
That's not to say that C isn't the right choice sometimes... I just think the places where C is the best choice are becoming more and more rare, and not just due to Go, but Rust as well.
Interesting. I didn't know about gccgo, and it'll be fun to see what problem domains Go ends up in with a predictable GC. Thanks for expanding on the topic.
> Other than C and C++, Go is one of the best languages for controlling memory. Not freeing, of course, but making it very clear where there are allocations, where there are copies, exactly how much memory is being used by any particular data structure.
It doesn't matter. I'm not going to start a new project at work in either language. But I might conceivably start one in Python, Ruby, go, JavaScript, java, Scala, or another well-used language.
I don't have enough knowledge of Go to answer it. And I'm perfectly content pointing out a problem without fixing it myself.
I think you're taking downvotes far too seriously. I might even call caring about karma a reddit attitude ;) And as far as illumination, I think you have it backwards. Posts that actually have illuminating answers should be brought to the top, so that many people can learn from them. Posts that only have a chance of getting such an answer should lie further down. There's probably also a positive correlation between people likely to form a detailed illuminating response and people that read further down the page on a particular subject.
