3 ms·

> Both languages were designed to replace C++ AFAIU Go was designed to replace C++/Java/Python as _the_ language to use at Google, not as languages themselves.

by rakoo 12y ago

> Both languages were designed to replace C++ AFAIU Go was designed to replace C++/Java/Python as _the_ language to use at Google, not as languages themselves. Which is why there is so much focus on simplicity, tooling, productivity (like compile speed and easy deployment). Criticizing Go for not having enough features is missing the whole point: Go was created in part because C++ has too many features. To my understanding, it was built for systems creators, not for programmers; it was built as a goto language who have to write program that is both efficient and simple to write and maintain. OTOH, I do see Rust as a C++ replacement, which makes it complementary to Go's focus (sadly it seems that D is lost in the middle, though...)

doorhammer 12y ago
This is the feeling I get. I don't write much Go (I'm just now getting into it) but all of the major features I hear about seem to be directed at creating code and projects that are tractable at "Google Scale". Everything has been designed for massive teams, from fast compile times, or having a standard formatting scheme, to choosing syntactically insignificant whitespace (specifically the podcast mentioned finding instances where python snippets were embedded in another language somewhere which would shoot the whitespace to crap). The language being dead simple also seems to be to that end, with things like removing ternary operators or not having the pre-increment being smaller sacrifices, and no generics being a larger one. All in all it seems like the underlying philosophy of Go is focused on Google specific context and engineering goals, and it's a happy accident when they work out well for programmers in the general case, whereas something like C++ or Rust isn't catering to those specific parameters (though they're obviously capable of working in that role, perhaps just not in the "ideal" way that the Go language maintainers would prefer).
- threeseed 12y ago
  > Everything has been designed for massive teams Weird. Because I see the opposite. Go would be fantastic for microservices or targeted applications. But features like exceptions are critical when you have 100+ developers spread across the world working on the one codebase and you want to ensure consistent error handling behaviour across the application.
  - kyllo 12y ago
    Well, Google's C++ Style Guide[1] disallows exceptions, so it makes sense that they wouldn't put exceptions in Go either. Come to think of it, Go does seem pretty similar to the subset of C++ that Google allows their developers to use. If you think of it that way, it starts to make sense to think of Go as an intended replacement for C++ at Google. [1]http://google-styleguide.googlecode.com/svn/trunk/cppguide.html http://google-styleguide.googlecode.com/svn/trunk/cppguide.h...
    - tomp 12y ago
      The Style Guide also says that the decision is mostly due to large amounts of existing Google code that is not exception-safe. > Things would probably be different if we had to do it all over again from scratch.

by rakoo 12y ago

doorhammer 12y ago

This is the feeling I get. I don't write much Go (I'm just now getting into it) but all of the major features I hear about seem to be directed at creating code and projects that are tractable at "Google Scale". Everything has been designed for massive teams, from fast compile times, or having a standard formatting scheme, to choosing syntactically insignificant whitespace (specifically the podcast mentioned finding instances where python snippets were embedded in another language somewhere which would shoot the whitespace to crap). The language being dead simple also seems to be to that end, with things like removing ternary operators or not having the pre-increment being smaller sacrifices, and no generics being a larger one. All in all it seems like the underlying philosophy of Go is focused on Google specific context and engineering goals, and it's a happy accident when they work out well for programmers in the general case, whereas something like C++ or Rust isn't catering to those specific parameters (though they're obviously capable of working in that role, perhaps just not in the "ideal" way that the Go language maintainers would prefer).

threeseed 12y ago
> Everything has been designed for massive teams Weird. Because I see the opposite. Go would be fantastic for microservices or targeted applications. But features like exceptions are critical when you have 100+ developers spread across the world working on the one codebase and you want to ensure consistent error handling behaviour across the application.
- kyllo 12y ago
  Well, Google's C++ Style Guide[1] disallows exceptions, so it makes sense that they wouldn't put exceptions in Go either. Come to think of it, Go does seem pretty similar to the subset of C++ that Google allows their developers to use. If you think of it that way, it starts to make sense to think of Go as an intended replacement for C++ at Google. [1]http://google-styleguide.googlecode.com/svn/trunk/cppguide.html http://google-styleguide.googlecode.com/svn/trunk/cppguide.h...
  - tomp 12y ago
    The Style Guide also says that the decision is mostly due to large amounts of existing Google code that is not exception-safe. > Things would probably be different if we had to do it all over again from scratch.