Aye, that's because being written in Python, C or Go is - in my eyes - a strike against the project in an absolute sense, because it will be more buggy and difficult to maintain due to lacking the functional-programming abstractions and powerful static-type system of a good ML descendant such as Rust or OCaml. (Or of Haskell, but it tends to lack the practicality of the ML family.)
So of course one does not trumpet that one's project is written in Python, C or Go.
n.b. I said "absolute sense" because all of this this is, of course, inapplicable when searching for libraries specifically for a language such as Python, C, or Go.
I don't buy it. People say, "X (written in Foo)" because there is fundamentally an interest in the fact that something is written in Foo (and this may indeed depend on the nature of X). Back when Go was new and shiny, it was the same situation.[1] :-)
> there is fundamentally an interest in the fact that something is written in Foo (and this may indeed depend on the nature of X).
That speaks to a deficit in human cognition, that slapping Foo's name on something makes it interesting only based on Foo's "shininess" rather than Foo's technical merits. Neophilia, perhaps?
Anyway. Go has been in roughly the same state of "another purposefully-boring Java-like, but instead of generics it has a different shade of OO and a full gamut of integer machine-types" for its entire life thusfar, which is why I've never understood most of its hype.
Rust, on the other hand, actually has some serious motivation to its learning curve and its developing ecosystem.
I'd say there are two (positive) reasons to it, since it only really appears for newer languages that are just gaining popularity
1. An improved tool was made, and presumably was made easier by the language somehow.
2. The tool serves as example of larger product written in that language
Both facilitate further usage of the language (by evangelism), show the language as being up-to-snuff (production-viable), and the existence of this codebase acts as an example for others within that language community.
It's not so much the language makes this tool better, but for that particular community, that the language was used is important, possibly more so than the tool itself.
> and presumably was made easier by the language somehow.
Right, and outside a few very narrow domains that are helped by the bolted-on concurrency, Go generally fails to deliver on those presumptions, for the same reasons that Java wouldn't if it were invented when Go was.
