> I suspect you've pulled this figure out of nowhere Actually, out of job postings, which, however imperfect, is the best metric we have: https://www.devjobssc

> I suspect you've pulled this figure out of nowhere Actually, out of job postings, which, however imperfect, is the best metric we have: https://www.devjobsscanner.com/blog/top-8-most-demanded-languages-in-2022/ https://www.devjobsscanner.com/blog/top-8-most-demanded-lang... The numbers are in line with older numbers (i.e. showing some growth), obtained by other people: https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/ https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/ > Oh yeah, I guess Objective-C peaked in 1993, Python peaked in 2001, and Java, PHP, Ruby and JavaScript peaked in 2005. Objective-C is irrelevant (as its adoption is tied to that of another product, kind of like VBA), and with the exception of Python, pretty much yes (I said neared or reached, not reached). Other than Python, no language showed surprising growth after a decade, including C (1983) and C++ (1995). > but it will steadily entrench itself as foundational building block of everything that surrounds you, as it has already started. The evidence suggests otherwise, but things could change. I'm not saying Rust will never succeed, just that current performance and the historical trend don't bode well. Of course, other languages -- Zig, Odin, JAI, and those that don't exist yet -- will also enter the game, and it's not unreasonable to expect that the low-level programming world will experience a similar fragmentation to that of the applications world, where no new language is particularly dominant. I think it is quite possible that Rust will achieve similar success in the low-level world as Go reached in the applications world. Anything beyond that is not out of the realm of possibility, but there are no current indicators to support that. Rust's adoption rate, in its target domain, is -- today -- lower than that of languages that have achieved unusual popularity in that domain or in others. > to bash the language I don't bash the language at all. I bash unfounded claims about it, such as those made in this discussion: that it's achieved extreme success, that all other designs are "fringe", and that it's well established as the best way to achieve correctness. None of these things are known to be true. As for the language itself, I find it too complex and reliant on implicitness for my taste, but I've said over and over that that design is certain to appeal to others. Moreover, I think Rust's "grand idea" of the borrow checker and type-checked lifetimes is nothing short of genius, although I wish it came in a simpler language. I also don't understand people who become so attached to languages that they deny reality. Clojure is one of my favourite languages, but it's silly to deny that its adoption is low; obviously, it's not many people's cup of tea. I find TLA+ to be one the most useful tools for me, but clearly many don't. I don't understand why people who like Rust need make believe that it's doing well, inevitable, or the only reasonable choice, when the truth -- as we know it today -- is that it's none of those things, yet that shouldn't stop anyone from enjoying it, just as Clojure or TLA+'s lack of popularity has no impact on my enjoying them. Why can't people say, "I use Rust because I enjoy it, I find it convenient, useful, interesting, and beautiful?" Why the need to also make up stuff about it? > that they spent such a significant amount of their comment activity on HN This one gave me pause, but I think you'll find that what mostly triggers my HN comments is not so much Rust but claims related to software correctness. I've spent years on this subject, I care deeply about it, and misleading claims about it abound. It's just that recently they've been coming with great frequency from Rust folk (just as before we heard similar claims about Haskell, that triggered me just as much). Sadly, we don't know the most effective approach (or, more likely, a combination of approaches) for software correctness, and incorrect claims to the contrary drive me crazy. It is such a complex topic, with often surprising and perhaps unintuitive realisations (Tony Hoare was certainly surprised and changed his mind on some matters), and the truth is that we simply don't know whether an approach like Rust's or like Zig's lead to more correct software than the other.