You should use a language based on how well it performs for your problem and domain, and the community around it. Not based on one article or because google is maintaining it.

I think his fear of google's stewardship of the language is the fear of what it'll do to the community around it.

Its incredibly unlikely that Google would take decisions for the language that would make it less effective at what it does.

No, but it's very likely that they'll make decisions that'll alienate the community and thereby cause it's ecosystem to lose more and more relevance. It has done that with other open source projects they stewarded.

If they alienate the community, the community can fork it, right?

In practice it's hard to fork out from the main contributers and keep the branch alive without resources on par with the main branch.

Then you rather do some new language.

Only if there are major contributing developers who do not work for Google. Is that the case with Go?

If there are no major non-Google contributors to Go, then the fork may not be successful due to lack of familiarity with the code base.

It depends on what you mean by "the community". If it's a community of contributors, and Google pulls it into a direction the contributors don't want, then they can fork it and continue contributing to it. If it's a community of users, then they have no choice but to follow whatever the contributors decide. I agree you need to have major contributors on board with a fork.

There's more nuance to it though. Users eventually become contributors (at least some percentage are), they become and stay contributors when they feel heard and feel like they have the ability to influence development. That's what nurturing an open source community means. If you start alienating your non-core contributors they'll stop contributing, if you nurture and support your non-core contributors they might become core contributors. No body wants to work voluntarily on a project they can't influence - that's not a contributor, that's an employee.

Empirically speaking, how did they do with dart?

It seems you misunderstood my post, like some others in this thread. I did not decide against Go because of the linked article, but rather because I have the same view on the language that is outlined in the article. I have a big problem with Google. And the fact that Google practically own Go is a red flag for me.

I'll suggest elixir. It's fun to build in and the community is growing (at least two companies with very large scaling demands use it). Don't get hung up about performance benchmarks, they're biased towards numerical algorithms; in practice if you are web focused your tasks will be IO bound and things like uptime process restart semantics and robust concurrency are more important.

If you want performance and garbage collection, Java (and its family), C#, and Go are the major options.

I'd pick Go among those every day of the week, but it's not perfect.

By "major options", I guess you mean popular/mainstream options?

What you learn from dedicating time to a new language, should not be the ability to program in it in 10 years, but to solve a problem you have now and hopefully learn some new concepts. Pick what will keep you engaged - it's the "learning something" that matters if you're not explicitly trying to solve something.

There really isn't any with a substantial community.

Python is good for algorithmic stuff and things that need specific libraries (tensorflow, NumPy etc)

But if you want a garbage collected language for moving bits from place to place over the network, it's kinda hard to beat Go.

Are you saying that there aren't garbage collected languages suitable for network development ("moving bits from place to place") with a substantial community except Go?

I mean, Java and all the JVM based languages comes to mind. Python, Ruby, Node.js (assuming performance isn't at the top of your list, which for many it isn't).

Go has a small community compared to all of the other popular languages.

C#, F#, Kotlin, TypeScript/Node (someday Deno)

I wouldn't worry much about "performant" though.

F# and Haskell are two very nice languages if you want to try something truly different.

... and if you are ok with investing to adapt newcommers coming to your team and fine with lack of people actively using it

Both have helped myself and many other people write better code in "enterprise" languages. I don't mind my team using different languages for small bits and pieces that are one off things, or can be replaced without must effort. It keeps developers happy to have some autonomy. I only demand that it's well documented how to build it.

you shouldn’t let an article decide what language you learn.

How many do you consider enough?

none. articles on the web are made for clicks. judge a language on its own merits, not via what someone on the web said.

Kotlin

This is a very bad reason to not learn a language imho...

I'd say it depends on what you want to do with it. Go is, as far as I understand, mostly a systems programming language. A replacement for C, basically. That means it competes mostly with Rust I guess. (I'm not familiar with Go or Rust, though.)

Python is mostly an application programming language. It competes with Java, Ruby, C# and those kind of languages. Python also has tons of excellent libraries for a wide variety of specific domain areas, like Machine Learning (perhaps most famously at the moment), but also many others.

If you want specifically web-focused, Javascript or Typescript are the obvious places to go. Nothing is more web-focused than those two.

I wouldn't call Go a systems programming language. Having a GC alone sort of removes it from that category.

That sounds logical, and I'm no expert on either Go or systems programming, but I've often heard of Go being referred to as a systems programming language, and on their own blog[0] they list it in third place at 37% as popular use of the language. Well after web development, admittedly, so apparently it is more a web development language than a systems programming language. I was clearly wrong on that part.

[0] https://blog.golang.org/

Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, D, Swift, Sing#, System C#, Common Lisp, Interlisp-D, StarLisp, Real Time Java beg to differ.