I'm not talking about either syntax nor use case, but about language philosophy, the approach to problem solving embodied in the language - the "paradigm" as you called it. As that post points out, even inside Google, the C++ committee members had a vastly different vision than Rob Pike on what makes a language good. C++11 is essentially universally loved in the C++ community as a giant step forward, as are most subsequent revisions. Rob apparently hates them.
Even the article shows that Go and C++ are fundamentally at odds philosophically, in terms of their paradigm:
> Jokes aside, I think it's because Go and C++ are profoundly different philosophically.
> C++ is about having it all there at your fingertips. I found this quote on a C++11 FAQ:
> The range of abstractions that C++ can express elegantly, flexibly, and at zero costs compared to hand-crafted specialized code has greatly increased.
> That way of thinking just isn't the way Go operates. Zero cost isn't a goal, at least not zero CPU cost. Go's claim is that minimizing programmer effort is a more important consideration.
If you want to compare them on use cases, Go is far too slow and memory hungry to be used in most domains where C++ is actually necessary. That is, for any C++ program that could be re-written in Go, you could also re-write it in Java or C# or Haskell, bar a few problems around startup times and binary sizes.
And that is what has been seen, again as the post points out: C++ programmers are not switching to Go. Ruby and Python and (Java and C#) programmers are.
Also, the designers of C++ have never made any effort to think about how easy the language is to learn, unlike the designers of Go, Java and C#. In fact, all of these languages share a common heritage: they are all designed as answers to C++, in slightly different ways.
> That is, for any C++ program that could be re-written in Go, you could also re-write it in Java or C# or Haskell, bar a few problems around startup times and binary sizes.
Nearly any program can be written any language. I can write in functional programming using Ruby, but why on earth would I do that when Haskell is "out of the box" useful for an application where functional programming makes the most sense.
> Ruby and Python and (Java and C#) programmers are.
Dynamic, object orientated based programmers are switching to Go when the use case suits. My understanding is that the syntax and philosophies are much more aligned to people of those backgrounds (Erlang -> Elixir is a great example of this) and gives them access to a lower-level language without having to learn many of the common more "computer sciency" things that are involved with those languages (C++/C).
> Nearly any program can be written any language. I can write in functional programming using Ruby, but why on earth would I do that when Haskell is "out of the box" useful for an application where functional programming makes the most sense.
That's only true in theory. In practice, you can't write a program that has soft realtime constraints for example (e.g. a game engine) in Go or Java, you have to write it in C++ or C or maybe Rust. This is true in general when you need utmost performance: while in general it's easier to write the same functionality in Go or Haskell or Java than in C++, the opposite is true when you need to extract as much performance as possible: it becomes easier to work in C or C++ or Rust than in Go or Haskell or Java (of course, this is a generalization; there are exceptions, though the rule holds pretty well overall).
> My understanding is that the syntax and philosophies are much more aligned to people of those backgrounds (Erlang -> Elixir is a great example of this) and gives them access to a lower-level language without having to learn many of the common more "computer sciency" things that are involved with those languages (C++/C).
Yes, because Go is is much closer to this paradigm than to the the paradigm of (Modern) C++. The only programming languages whose vision is similar to C++'s in my opinion are Rust and Common Lisp (even though of course Common Lisp is applicable to different hardware constraints, it being garbage collected and dynamic, it still has a very similar philosophy at its core).
Even the article shows that Go and C++ are fundamentally at odds philosophically, in terms of their paradigm:
> Jokes aside, I think it's because Go and C++ are profoundly different philosophically.
> C++ is about having it all there at your fingertips. I found this quote on a C++11 FAQ:
> The range of abstractions that C++ can express elegantly, flexibly, and at zero costs compared to hand-crafted specialized code has greatly increased.
> That way of thinking just isn't the way Go operates. Zero cost isn't a goal, at least not zero CPU cost. Go's claim is that minimizing programmer effort is a more important consideration.
If you want to compare them on use cases, Go is far too slow and memory hungry to be used in most domains where C++ is actually necessary. That is, for any C++ program that could be re-written in Go, you could also re-write it in Java or C# or Haskell, bar a few problems around startup times and binary sizes.
And that is what has been seen, again as the post points out: C++ programmers are not switching to Go. Ruby and Python and (Java and C#) programmers are.
Also, the designers of C++ have never made any effort to think about how easy the language is to learn, unlike the designers of Go, Java and C#. In fact, all of these languages share a common heritage: they are all designed as answers to C++, in slightly different ways.