The most useful information about Go until now for me:
It was not made to replace C++, rather, it seems that it grew out of frustration of using C++ for some specific project inside of Google. That program needed 45 minutes to compile on a computer cluster!
However, Rob seems to wonder why more C++ users didn't pick up Go, but Python users did. But I believe it's more than obvious: I'm sure that he still can't use Go even as the part of the mentioned 45-minutes-on-cluster compiling C++ project. Go is a system, not something that can be linked to the existing C++ or C or Fortran project. To compare, note that C was made to be able to be linked with Fortran or assembly.
Moreover, I believe that even if he had all the time of the world for rewriting the mentioned 45-minute-on-cluster compiling C++ project in Go, his resulting program would certainly compile faster and most probably "look" nicer on the line lieve but would execute bad enough that nobody would like to switch to his variant, just for the speed and memory usage aspects.
And that's all that it's to be said about Go. Good wishes are one thing, but the execution matters. One the pure performance level, it pays out immensely to replace some project written in Python with Go, on the "what compiler does for you" level too. Python is awfully slow whenever the built-in C code inside of Python and libraries like numpy is not executed, and the errors which you can catch with compiler are much more convenient than the run-time errors. But when replacing C or C++, you simply don't get the execution-level control or memory footprint benefits with Go. "But it's easier to write, especially concurrent programs" argues Rob. Yes, you can read it for every language in existence: for people who are used to the language they talk about, when they write exactly that what they are used to write, it's the easiest language to write in. Erlang people would tell him that Erlang is easiest to write for concurrent programs. It's easy to find the scenario where any language is an optimal one.
But being better or as good as C is not an easy task. The only language which was often quoted to produce even faster code was Fortran. Not that Pascal didn't have the possibility to avoid aliasing problems inherent in C, for the given tasks, numerical computing, Fortran was for enough historical reasons more convenient than Pascal.
"The determined Real Programmer can write Fortran programs in any language." http://www.pbm.com/~lindahl/real.programmers.html For those who don't get it, it's a joke: I quote it in order to finish with: For decades, languages are marketed as the "silver bullets." Go ain't, just like most of them before. I'm old enough to know, some of the most successful aspects of Go: fast compilation, clean declarations and reduced syntax were present in the works of Niklaus Wirth: http://en.wikipedia.org/wiki/Modula-2
Wirth was obviously quite right from the start. And Object Pascal programmers know they had a lot of good sides of Go even twenty years ago. Including not being forced to have constructors.
Now, what would be the ideal language that would be "better than C" in my opinion? Let's call it X. In my opinion, X would be some modification of C with the following properties:
- no headers in C sense -- a limitation that would allow the definitions to be independent of text-based macros.
- the compiling/linking speed of ObjectPascal or Go. That area was the most ignored by "compiler designers" for years, because "hey we're compiler designers" and "linkers are not sexy, compiler are." In reality, the mentioned C++ monster that compiles 45 minutes could be reduced to be compiled to 4 and have all functionality of current C++.
- the full "linkability" to C. If I link a bunch of X files, I can get one OBJ which I can link to the C project. Or I can call from X to C. Both must work. Maybe I would need to link some run-time support additionally, but it must be enough.
- having in compiler "the introspective capabilities" as in D. That is fully ignored by most of compiler writers and I really believe D is on the right track, especially since Andrei Alexandrescu worked for some of such features. If at some point I have some expression and compiler know the type of it, I should be able to query it. If compiler knows the name of something, I should be able to query it and insert the name in my code! If compiler knows some dependency, I should be able to know it in the code, if I need it. Etc.
- built-in ways for decent strings (with counted sizes, not zero terminated), counted arrays, lists etc. I should be able to use them in the declarations/implementations without the overheads of the STL monster that it became. Again I should be able to link the runtime and access elements of these from C too.
So the logic would be: you can shoot yourself in the foot like with C, but you can have a "safer subset" (the compiler should have the switch "compile as unsafe" which would be off, in order to live you the chance to do low level when you must, but to keep most of the code "clean." When most of the "common" arrays, strings, maps, trees are part of the language, in most common cases, the whole programs could be "safe."
Etc. As you see this probably excludes some of cool features of Go like "segmented stack" and concurrency but it can give something much more convenient than C++ and still be as fast and "low-level-to-the-last-byte" usable like C.
I know, it wouldn't appear too creative, it would appear even less "interesting" than Go but I believe it would make a change: the C basis is sound, we still need the language that we know that it cleanly maps to the assembly.
Go is "something above," therefore not so attractive for those that need the "to-the-assembly" level.
It was not made to replace C++, rather, it seems that it grew out of frustration of using C++ for some specific project inside of Google. That program needed 45 minutes to compile on a computer cluster!
However, Rob seems to wonder why more C++ users didn't pick up Go, but Python users did. But I believe it's more than obvious: I'm sure that he still can't use Go even as the part of the mentioned 45-minutes-on-cluster compiling C++ project. Go is a system, not something that can be linked to the existing C++ or C or Fortran project. To compare, note that C was made to be able to be linked with Fortran or assembly.
Moreover, I believe that even if he had all the time of the world for rewriting the mentioned 45-minute-on-cluster compiling C++ project in Go, his resulting program would certainly compile faster and most probably "look" nicer on the line lieve but would execute bad enough that nobody would like to switch to his variant, just for the speed and memory usage aspects.
And that's all that it's to be said about Go. Good wishes are one thing, but the execution matters. One the pure performance level, it pays out immensely to replace some project written in Python with Go, on the "what compiler does for you" level too. Python is awfully slow whenever the built-in C code inside of Python and libraries like numpy is not executed, and the errors which you can catch with compiler are much more convenient than the run-time errors. But when replacing C or C++, you simply don't get the execution-level control or memory footprint benefits with Go. "But it's easier to write, especially concurrent programs" argues Rob. Yes, you can read it for every language in existence: for people who are used to the language they talk about, when they write exactly that what they are used to write, it's the easiest language to write in. Erlang people would tell him that Erlang is easiest to write for concurrent programs. It's easy to find the scenario where any language is an optimal one.
But being better or as good as C is not an easy task. The only language which was often quoted to produce even faster code was Fortran. Not that Pascal didn't have the possibility to avoid aliasing problems inherent in C, for the given tasks, numerical computing, Fortran was for enough historical reasons more convenient than Pascal.
"The determined Real Programmer can write Fortran programs in any language." http://www.pbm.com/~lindahl/real.programmers.html For those who don't get it, it's a joke: I quote it in order to finish with: For decades, languages are marketed as the "silver bullets." Go ain't, just like most of them before. I'm old enough to know, some of the most successful aspects of Go: fast compilation, clean declarations and reduced syntax were present in the works of Niklaus Wirth: http://en.wikipedia.org/wiki/Modula-2
Wirth was obviously quite right from the start. And Object Pascal programmers know they had a lot of good sides of Go even twenty years ago. Including not being forced to have constructors.