Comparison of programming languages in Stackoverflow Survey

In several speeches at conferences, I saw Rust presented as the most loved language and the most wanted in '22. I got curious, what about Go, the main competitor. (And yes, I think it is a competitor, because at every company when you say "hey, let's rewrite this in Rust", you hear "why not Go?" in response.)

So I decided to compare several languages. I put in Java (an easy to use compiled language), Python (easy to learn and use, but slow), PHP (was one of the most popular, and easy-entry one), and 2 flavors of C (C# and C++).

Most Used

  • Java, both Cs and PHP are losing their share, but I can't tell whether their absolute audience shrinks or grows. It's just the share, and also SO has some audience bias.

This is the most interesting chart for Rust community:

My data as CSV to build a pivot table if someone wants.

1 Like

Go is definitely not a competitor to Rust, and usually only gophers (not even all of them) treat it as such one. C# and C++ definitely not flavors of C. IMHO popularity of language doesn’t matter. Only performance, beauty and safety.


I wouldn't say that popularity doesn't matter, but I just want to point out that we were there before.

History doesn't repeat itself, but it rhymes.

If you want to see what would happen with languages in the future — just read 30-40 years old computer magazines and do the following replacements:

BASIC ⟹ Python
Pascal ⟹ Go
C++ ⟹ Rust

Heck, even small things are similar. Like Pascal back then had two branches: more-or-less part of the wider ecosystem one (that's GccGO today) and the one that people actually used (that's the official Go compiler today).

C++ only had one compiler initially but it never tried to be a separate entity, it was always easy to combine C++ modules with C modules, Java modules and even Pascal modules while Turbo Pascal was it's own thing not compatible with anything else.

That's the biggest difference between Go and Rust and, eventually, it would prove to be the deciding factor: Rust can be used together with any other language, but Go wants to live in it's own process.

This would mean that Go would forever be confined to the certain niche (like Pascal eventually have become just a backend for a certain RAD tool), while Rust would coexist with many other languages.

Long-term they are not competitors because everything Go can do Rust can do either (although Go have superb async runtime and when your task demands the use of said runtime it can be better than Rust), while there lots of things which Rust can do, but Go can not (GC would prevent it).

Have you seen Go libraries in Android apps, in iOS apps, in the web apps? Technically these are not impossible, you know. Just so much hassle that in practice these never happen.


C# and C++ aren't competitors either, really. C# is just Microsoft Java, and targets a very different market than C++ does.

Ignorant managers don't make it a competitor, though. There's two big reasons Go and Rust aren't competitors:

  • Technically, Go is in the Java/C# level of stuff. Runtime, extra friction at the FFI barrier, quite fast but not 100% fast.

  • But more importantly to me, Go and Rust have totally opposite values. Go is for people "not capable of understanding a brilliant language", according to one of its designers. Whereas Rust is "Technology from the past come to save the future from itself" by actually taking advantage of a bunch of stuff the was learnt about programming languages over the decades. (For example, Rust didn't ignore the lesson of Java and C# that, yes, statically-typed languages really do need generics, no matter how many times you say object or interface{}.)

If you really don't need the control that Rust offers, and aren't in a domain where its concurrency help is valuable, then by all means, use Python or Java or Node or …. But that's different from them being really a competitor.


All the arguments here purporting to claim that golang isn't a Rust competitor are actually arguments that it shouldn't be. Normative claims do not refute empirical ones. Rust and golang don't compete in all of their respective domains of use, but they clearly do in some. Both, for example, are often considered and used for cli tools.

Yes they do. Whether things compete is a part of the reality of the physical world, of which managers are a part (and often a more influential part than programmers, certainly more influential than forum and SO posts). "Winning" in the Platonic realm happens only in the imagination.


Guys, I trust the facts that you all point out here, and yes, C# isn't C/C++, and I know it's easy and slow as Java, and maybe Python is an equivalent of Basic (I'd put PHP in that role, but whatever).

But what you're saying is that Rust is objectively superior to Go, and it's other people's problem that they don't see it.

Well, the other people make their own mind based on facts and trade-offs, not by searching for an objective ideal. Go or other language may come with lower reliability, other come with much slower speed, but it's a trade-off some people will be ready to pay.

What I see from my side, there are companies that work with big data (statistics, heavy geospatial data, etc.) and they consider rewriting some pipelines in faster languages. And they may look at some blog posts and see the selling point of another language: "we've got things done quickly with this one".

And if many of them choose other languages, there'll be nobody to maintain crates here on this side.


I'm not a manager, and I'm certainly not ignorant of either Rust or Go. Several years ago, we did a bake-off between Rust and Go to decide which language to use for some new projects. Both were suitable to the task. We did a comparison of the two competing languages.

It is difficult for me to even understand why people say that Rust and Go aren't competitors, especially when it's phrased as a fact or a certainty. As far as I'm concerned, even Rust and Python are competitors. I have taken some programs I've written previously in Python and rewritten them in Rust. I've also written some programs in Rust that I might have previously written in Python. See? They compete. It is trivially true that they compete. (This is my descriptive rebuttal.)

Like, it doesn't even make sense to me to even debate this point. What does it even mean to say that Rust and Go aren't "competitors"? Surely there must be some more concrete specific and meaningful thing to be said. Like, even if I agreed with you or anyone that "Rust and Go aren't competitors," what does that actually mean? Does that mean I'm not allowed to compare Rust and Go? Does it mean I've made some critical error in understanding either of the languages? ¯\_(ツ)_/¯ (This is my prescriptive rebuttal.)

Now I can see some folks saying, "Rust and Go don't compete in my mind's eye because if Go is suitable to the task at hand, then that's the language I use. Therefore, there are never any overlapping use cases for me personally." I could see plenty of folks saying that. I don't, certainly, but it's a reasonable position. However, there is no statement of fact there. It's just an opinion that is likely based on numerous trade offs, one of which is, as you hint at, values.


No way are C# and C++ "flavours" of C.

I don't care about language popularity. Except in as much that it has attracted a critical mass of developer community to ensure its survival and growth into the future. Luckily enough really smart people have seen the benefits of Rust and thrown themselves into it.

First criteria is can the language do what I want? Without going into details that means it cannot be Python, PHP or other such lumbering interpreted language.

Close second criterial is does it run on the platforms I want to use? And can I cover the widest range of platforms with it (including micro controllers). That rules out the above and also Go, Java, C# and others. However it pretty much dictates use of Javascript/TypeScript in the browser. (Yes I know Rust and WASM are coming along).

That pretty much leaves C, C++, Rust, Ada, even Pascal.

I love C, especially for small micro-controller projects, but for bigger applications it becomes a pain fiddling around at that low level. C++ is out for me on account of it's ever growing complexity, nobody understands all of C++ features and how the interact. Ada is interesting but I would not expect the world of support in terms of libraries, frameworks, or even just community support.

That pretty much leaves me with Rust. Also a pretty huge and complex language, a lot of which I still don't understand. However not understanding has not stopped me getting what I want done and Rust's type and lifetime checking ensure that my lack of understanding is not going to lead to programs that randomly crash or produce wrong results.


But golang is not a competitor in many important areas. One is not going to be writing an operating system in Go. As far as I know one cannot use Go on little micro-controllers. Can we use Go in the browser yet?

Presumably they do see it when given a task that Go cannot do. See above.

Potentially that could happen. Or some new language pops up that attracts all the Rust developers to it. My observation is that enough highly skilled developers are attracted to Rust, for it's beauty and unique capabilities, that I'm not going to worry about them jumping ship.


See above. Of course you are right, for a wide range of application both Go and Rust will get them done competently, as will many other languages.

It's like the "are Netflix and Fortnite competitors?" question. It has nothing really to do with either company, but is almost entirely on the definition you choose to apply:

  • "Yes" is correct, because they're both competing for your time.
  • "No" is also correct, because they're in different markets.

I prefer to define the term such that "essentially all programming languages are competitors with each other" isn't true, because I think it draws more interesting distinctions that way.



Some of the conversation here (not you @ZiCog) reminds me a little of What killed Haskell, could kill Rust, too · GitHub. Fortunately I do think there's enough pragmatism in the Rust community to avoid that fate, and I don't see a great deal of that kind of snobbery at large, so if it seemed a danger when that article was written, I doubt it is now.


It's not objectively superior. It all depends on your goals.

If your goal is go impress the investors then it's not “objectively superior”.

Because you don't need “reliable and efficient” software for that.

If they don't even have time to do a proper research why do you expect that they would find time to maintain any crates?

That's easy: if there are some area where one language can be used and the other language can not be used then they are, fundamentally, are not a competitors.

Or if there are area where one or the other language don't even try to compete.

You can write any of that stuff in a Brainfuck but does that mean Brainfuck is a competitor for Go or Rust?

This means that one can not kill the other, more-or-less.

Go have it's extremely clever async engine and if that's the only thing you need Rust is not a good replacement.

Rust have “reliability and efficiency” and if that's what you need Go is not an option.

Yes, there are some overlap where both are valid choice but that's not what would be deciding their future.

Niches where languages overlap, surprisingly enough, are not that important. Languages need niches which they completely own to survive.

1 Like

Yes I figured as much, but I still don't get why people say "Rust and Go aren't competitors." It's a colloquially broad statement that you mean to have folks interpret narrowly, but you don't say how broad or how narrow. So it just invites endless and IMO pointless disagreements.

Well, this is the exact opposite of @scottmcm's clarification, because this interpretation essentially means that no language competes with another because "some area where one language can be used" can be interpreted arbitrarily narrowly.

This is a misrepresentation of what I said. I didn't say "can." I didn't say, "since I can write program foo in A and B, therefore A and B are competitors."

Popping up a level, you are reinforcing my point that such broad discussion about whether two languages are competitors or not is borderline pointless. Namely, you are not addressing my central point. My central point is to focus on something more concrete and specific.

I don't know what it means to "kill" a programming language.

This is an opinion, not a fact. And I do not agree with it. Not even close.


Well, at some point we need some definition of some words which can be used for something.

Do you consider PL-I alive or not? There are still some folks who develop it, but is it alive?

Well, that's something, at least. Can you name one language which can be easily replaced with something else — yet wasn't.

Although… if you consider ALGOL or PL-M “alive” then I don't think we can arrive at any conclusion.

I reject the dichotomy. I'll note that "kill" and "alive" are not opposites. So even if you could convince me what it means for a programming language to be "alive," that doesn't also tell me what it means for one language to "kill" another.

It would be helpful I think for you to pop up a level here. This line of discussion is getting lost in the weeds and missing the bigger point. I'm not seeking to have a sprawling Internet debate on the definitions of terms absent any specific context.

I should clarify where my brain went with my original statement.

When I see the response mentioned in

my brain hears "Have you tried JavaScript?".

There are reasonable "I don't know details about Rust yet" questions, like "what's the interoperability story?" or "does the rust code need to be a separate shared library?" or "does it fit our existing debugging workflows?", to use some I saw recently. And of course there's always the "is a rewrite even a good idea?" and "can we not introduce a language we don't use at the company yet?" issues.

Are there situations where an informed manager might justifiably consider using either Rust or Go for a project? Absolutely. But if my manager replied to my "I think we should use Rust for this" proposal with "why not Go?", it would lower my respect for and trust in that manager. Unless I was already at a Go-only shop, but that's not "every company".


It is quite common to speak of "dead" languages, certainly in the context of human languages. Some languages have been really dead, as in nobody knew how to speak or read them any more. See The Rosetta Stone. But generally it means there are so few users it may as well be dead.

Given that we can have dead languages presumably one can kill them. Rather than actually kill all the users of these languages perhaps a new language can come along which everyone adopts and the language they were using becomes dead. Ever hear of the Coral language? That was killed by the arrival of Ada. Ever hear of PL/M? That was killed by the arrival of C into the embedded controller space. What about the mother of all modern languages ALGOL? Perhaps killed by the arrival of C and others.

So when VorfeedCanal says "Languages need niches which they completely own to survive." I take that to mean that if a language is used in some domain but no other language can reasonably be used in that domain, then the language will continue to be used there, the others cannot displace and kill it, it will survive.

An example is perhaps C in small micro-controllers, Java and Go and the like cannot go there, cannot displace it, cannot kill it.

Javascript has its niche in the browser platform. It owns that space and nobody can kill it....yet.

1 Like

I do not care about the classification of "dead programming languages" for the purposes of this discussion.

I wouldn't. I think the answer to such a question is highly likely to be extremely edifying and an avenue for further exploration of the problem space.

I'll try to be really clear: I am taking issue with the communicative tactic of declaring two programming languages as "not competitors" without any additional clarification or context that makes the more narrow interpretation you intended clearer.

Sadly, my intent was to reduce the chances of wasting time in what I think is senseless navel gazing without a clear objective. But that is exactly what happened with all sorts of random tangents now cluttering up this thread. I did this because I see this exact conversation and exact arguments playing out all the time and everyone is mostly just talking past one another.

I'll mute the thread and bow out.

1 Like

It's socio-psychological phenomenon. The question is not about whether some other language can or can not be, technically, used there, but whether said language associated with certain niche so tightly that other languages need special justification to be even considered.

Like Go and network microservices, Java and enterprise monsters, C and microcontrollers, Python and machine learning.

Even PHP have it's own niche! “Programmer language for computer illiterates which makes it possible to hire programmers for cheap” doesn't sound like a very attractive niche, but it's definitely something Rust or even Go can not ever hope to cover.

Languages can be killed even if they occupy some niche, but that takes years, decades even, and that's only possible if the alternative language have some other niche which it uses to survive.