3 ms·

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

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.

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.