Go still hasn't found a niche to be useful to. Nobody's giving up 30 years of C for systems programming, nobody's going to use Go for web apps when higher level languages are clearly more practical, nobody will give up Haskell for scientific and massive parallel programming. All in all I think Go is an interesting experiment but it serves no purpose that I can use right now
Go fills the same niche as node.js: high performing API servers talking to some frontend: a "proper" webserver, thick in-browser webapp, a mobile app, etc. And it's a pretty damn good alternative when you compare the clarity of goroutines with the typical mess of Javascript callbacks.
Oddly enough, I know several people who are giving up 30 years of C and Fortran programming to use Go because they find its features sufficiently compelling--and they're changing minds throughout the organization.
For about two years, many of the people I work with have been using Go almost exclusively because, while simple and fast like C, the things it adds are so useful we can't imagine trying to hack similar functionality together with C libraries. Things like built-in maps, slices, multiple returns, lambda functions, channels, goroutines... these are all things you can accomplish in C, but it's so much more painful (see: homebrewed hashtables, do-it-yourself pointer management on a big array, returning structs, function pointers, some sort of mutex abomination to replicate channels, pthreads)
Go was designed for the above-OS, networked systems programming niche at Google: new database engines, distributed filesystems, web servers (as opposed to web apps), and other similar projects. I would not write a wiki app in it, but certainly the next Apache or Nginx replacement.
And although I haven't tried it out myself yet, it does seem very promising for such use cases. You don't have to "give up" 30 years of existing C code if you are just using it as libraries and OS calls, not rewriting it.
> I would not write a wiki app in it, but certainly the next Apache or Nginx replacement.
I wouldn't. Nondeterministic garbage collection in a web server like nginx (as opposed to an application web server like Jetty) makes me very nervous. The HTTP (or pick-your-other-TCP-protocol) lifecycle is well-understood enough that you should be able to handle your own memory management.
There are lots of things in Go I like, but for me they're coupled with questionable abstractions that make it difficult to rationalize over C++.
Actually Go GC is quite easy to control. If you know your butt from your elbow you can write code that doesn't GC at all.
I really don't have a problem with GC though. Its easier to optimise a GC than to fix memory and reference counting bugs. Memory management is not a problem I want to be dealing with after 60-odd years of computers being around.
> Its easier to optimise a GC than to fix memory and reference counting bugs.
I don't agree. If you are competent enough to be needing to write your own web server, memory management should be utterly trivial.
There are many use cases where you do not need to really balance bleeding performance against programmer conveniences. Something like "Apache or nginx" is without question one of them.
I'm curious, why do you think higher level languages are more practical? Other languages at present have better tooling and libraries for this, but there's really nothing in the language itself that makes it hard to do web dev, quite the reverse, in fact having played around with a few personal projects and given the use it has had so far at google, I suspect golang may well find its niche as a server side language. Have you tried it?
I will gladly give up C for systems programming for new projects. Go would have made an interesting choice over Python for the non-performance-critical parts of BIND10; I would certainly have studied the source closely. I can see myself writing things like Postfix policy daemons in Go. Heck, if I had a side project named "write a SMTP/IMAP server", Go would be my first choice.
I do have a side project of writing a DNS server, and my scribbled notes for it say to use Erlang for the protocol speaker and Go for the control plane.
I suggest that what Go needs is some kind of killer project that everyone can learn from. C had UNIX.
The niche I think go appeals to is Python/Ruby/NodeJS developers who are intimidated by systems programming (eg: C-style threads, manual garbage collection) but still want to work in a statically typed environment.
Goroutines and channels in particular are an interesting and useful abstraction away from threads and communication between those threads.
A higher level language would've been worse for developing my web app, niflet.com. I did the prototype in PHP and found Go to be easier to code in, much less coding overall, and at least 10X better performance. I didn't have to deploy a separate web server either.
> One can easily program is if [sic] it were C, using templates to avoid ugly macro mess for generic algorithms and types.
Did you mean "as if"? If so, that's exactly what Torvalds objects to -- the things about C++ that supposedly represent improvements over C. He goes on about how many of the conveniences of C++ -- like the STL -- aren't as wrung out as most people think and don't actually work as intended.
I don't necessarily agree with his position in all respects, but some of the enhancements in C++, aren't actually enhancements.
For scientific computing, you have an insanely well designed languaged, with it you can run extremely fast computations, optimally tuned for your hardware even on multicore systems. The language is Fortran.
Yeah, C/C++ or Python/NumPy, Haskell is still a niche language that some people like to talk about, but all numbers and statistics on the matter seem to indicate it's never actually been preferably used to solve problems in any domain.
Couldn't you also say "I don't see how C was ever aimed at replacing assembly for systems programming, heck the C runtime and compiler is written in assembly."
This argument is getting old. What was the first, the egg or the chicken? Was the first C implementation passed down on stones drawn from the void of the Universe? At some point bootstrapping was needed for the implementation to be self hosted. That goes for every supported platform.
Of course. But for the moment, being self hosted is just reinventing the wheel when there's so much existing infrastructure. That being said, it is difficult, probably impossible, for Go to be a C replacement, but you're using the wrong argument (the current canonical implementation).
