Brad Fitzpatrick on the future of Go
Well, it's good to have a hard-compiled language that's (almost) memory safe. Three problems with Go:<p>- The Go mantra is "share by communicating, not by sharing". Then look at all the thread examples in "Effective Go".  They all share memory, while trying to construct locks using message passing.  Multi-threaded Go programs are not memory-safe. That's why Google won't let you use them on their AppEngine.  Compare Erlang, which takes message passing seriously.<p>- The lack of exceptions is resulting in hacks using the "panic" mechanism to create an exception mechanism.  This is where we were with "longjmp" in C.  I know someone at Google who has constructed a language on top of Go mostly to deal with exceptions.<p>- The lack of generics is resulting in hacks using the reflection mechanism to create generics. This is painful and slow. Go has generics for built-in objects; channels and maps are parameterized types, so there's already syntax for instantiating a parameterized type.  Extending that to user-defined types would not be too bad. Fear of the C++ template mess seems to have been the problem.