> The only scenario I could see people using it is in the situation where speed is not of the essence but memory consumption is.
In the type of code we do (distributed systems programming) speed is almost always directly dependent on memory consumption and layout. For the parts of our codebase that are purely CPU bound Go is about 2x slower than C, fast enough that we haven't yet felt the need to rewrite in C and use GCC. For the rest of the system we get a nice flexible statically typed language that has good support for concurrency. Previously a similar project would have used Erlang/Python/C on the server side, now we can just use a single language.
YMMV, we (tinkercad) do data and computation intensive problems which fits the original design goal of Go pretty well. Plus we find that C/C++ programmers can transition to the language quite easily, which is a plus given the domain of graphics and computational geometry is still filled with a lot of people who have mainly used C++ for performance reasons.
In the type of code we do (distributed systems programming) speed is almost always directly dependent on memory consumption and layout. For the parts of our codebase that are purely CPU bound Go is about 2x slower than C, fast enough that we haven't yet felt the need to rewrite in C and use GCC. For the rest of the system we get a nice flexible statically typed language that has good support for concurrency. Previously a similar project would have used Erlang/Python/C on the server side, now we can just use a single language.
YMMV, we (tinkercad) do data and computation intensive problems which fits the original design goal of Go pretty well. Plus we find that C/C++ programmers can transition to the language quite easily, which is a plus given the domain of graphics and computational geometry is still filled with a lot of people who have mainly used C++ for performance reasons.