4 ms·

Go looks very cool but it solves only a subset of C++ better than C++. For example, I doubt very much Crysis, Battlefield or Modern Warfare could be written in

Go looks very cool but it solves only a subset of C++ better than C++. For example, I doubt very much Crysis, Battlefield or Modern Warfare could be written in Go on consoles assuming Go even existed on consoles. Similarly I'm not sure how great it is at client side apps where you need certain code for OSX and different code for Linux and yet different code for Windows. Or how about iOS and Android games, two places that use lots of C++? So at least for me, while I'd love to get the benefits of what Go is trying to achieve, until it solves the problems I personally need to solve it's unfortunately off my list. When I am on a project it fits I'm looking forward to checking it out.

luriel 14y ago
Go is certainly not (yet) ready for every task C++ has taken over during the last 25 years. But I would say that for most tasks, it is more than good enough already. > Similarly I'm not sure how great it is at client side apps where you need certain code for OSX and different code for Linux and yet different code for Windows. This is very easy in Go, just name your file foo_windows.go, foo_linux.go, etc. See for example: https://github.com/howeyc/fsnotify https://github.com/howeyc/fsnotify
- greggman 14y ago
  Define "most". It's not suitable for any app I've written in the last 25 years. But I don't do server work, I do client work. Native apps on Windows, Mac, Linux and consoles. It might be useful for some command line tools I've written but since nearly every command line tool I've written in the last 25 years has been to make data for my C++ client side apps there's a benefit to being able to share code. Of course I know that's just one anecdote, mine. If it fits most of your use cases awesome. For me, one thing that might go a long way to use Go is are cross platform client side libraries like WinForms. Once of the things that makes C# so popular with my crowd is how easy it is to make tools with GUIs. Of course C# also interfaces with native data pretty well. No idea how well Go handles that case
rubashov 14y ago
I don't see any reason to prefer Go to the D programming language. D achieves all the major claimed benefits of Go and yet has vastly more abstraction power and better type safety and error handling. The interest in Go is a mystery to me.
- luriel 14y ago
  The interest in a language with even more features than C++ is a mystery to me. If you read the linked article you will realize that the main benefits of Go are precisely from "features" that it omits. D takes almost exactly the opposite approach, and takes C++ and adds even more.
  - rubashov 14y ago
    The lack of generic programming in Go is a huge deal. It's vital for modelling complex systems without a mess of runtime checks, and generally leads to clean and reusable designs. With D, you can get very close to the generic ideal, "This is the last implementation of linear search I'll ever need to write." Or binary search. Or stable matching. Or Levenshtein distance. I searched around, and it looks like D is the only language offering Levenshtein distance on UTF strings without copying the input and without special-casing per encoding. D just has the abstraction power to deal with variable-width entities efficiently and within a unified definition (that works with many other inputs, such as linked lists of floating point numbers, if you want). It's really the last Levenshtein implementation I need to write. Now, you may not care about that particular algorithm, but there are benefits of that power for many structures, algorithms, and design artifacts that might be important to you. http://www.informit.com/articles/article.aspx?p=1621867 http://www.informit.com/articles/article.aspx?p=1621867
- gfodor 14y ago
  Is it really a mystery? It was created by some of the most well known computer scientists of the last several decades and was created by and for systems engineering at Google.

luriel 14y ago

Go is certainly not (yet) ready for every task C++ has taken over during the last 25 years. But I would say that for most tasks, it is more than good enough already. > Similarly I'm not sure how great it is at client side apps where you need certain code for OSX and different code for Linux and yet different code for Windows. This is very easy in Go, just name your file foo_windows.go, foo_linux.go, etc. See for example: https://github.com/howeyc/fsnotify https://github.com/howeyc/fsnotify

greggman 14y ago
Define "most". It's not suitable for any app I've written in the last 25 years. But I don't do server work, I do client work. Native apps on Windows, Mac, Linux and consoles. It might be useful for some command line tools I've written but since nearly every command line tool I've written in the last 25 years has been to make data for my C++ client side apps there's a benefit to being able to share code. Of course I know that's just one anecdote, mine. If it fits most of your use cases awesome. For me, one thing that might go a long way to use Go is are cross platform client side libraries like WinForms. Once of the things that makes C# so popular with my crowd is how easy it is to make tools with GUIs. Of course C# also interfaces with native data pretty well. No idea how well Go handles that case

rubashov 14y ago

I don't see any reason to prefer Go to the D programming language. D achieves all the major claimed benefits of Go and yet has vastly more abstraction power and better type safety and error handling. The interest in Go is a mystery to me.

luriel 14y ago
The interest in a language with even more features than C++ is a mystery to me. If you read the linked article you will realize that the main benefits of Go are precisely from "features" that it omits. D takes almost exactly the opposite approach, and takes C++ and adds even more.
- rubashov 14y ago
  The lack of generic programming in Go is a huge deal. It's vital for modelling complex systems without a mess of runtime checks, and generally leads to clean and reusable designs. With D, you can get very close to the generic ideal, "This is the last implementation of linear search I'll ever need to write." Or binary search. Or stable matching. Or Levenshtein distance. I searched around, and it looks like D is the only language offering Levenshtein distance on UTF strings without copying the input and without special-casing per encoding. D just has the abstraction power to deal with variable-width entities efficiently and within a unified definition (that works with many other inputs, such as linked lists of floating point numbers, if you want). It's really the last Levenshtein implementation I need to write. Now, you may not care about that particular algorithm, but there are benefits of that power for many structures, algorithms, and design artifacts that might be important to you. http://www.informit.com/articles/article.aspx?p=1621867 http://www.informit.com/articles/article.aspx?p=1621867
gfodor 14y ago
Is it really a mystery? It was created by some of the most well known computer scientists of the last several decades and was created by and for systems engineering at Google.