Isn't that just his typical MO? It's always seemed to me he was more of a hanger-on looking for glory (or perhaps an essayist and advocate, if we want to be a charitable) than a really significant contributor.

There's a lot I can say about ESR, but I'm trying to contain my comments to the stuff germane to his blog post here, which I actually did read.

I, for one, am interested.

Your post does not address Raymond's arguments, but instead primarily just attacks the messenger as supposedly not being qualified to comment on language trends.

While it may be true that ESR is not a superstar programmer in the image of a John Carmack or a Bill Gates, he has been a working C developer for over 30 years, and has contributed to numerous open-source projects, including systems projects, over that period of time. The examples he lists in the article are some pieces of software which he is currently a maintainer for.

Actually I think the fact that he is not a superstar programmer with a signature project possibly makes him a bit more qualified to comment on language trends. After all, most of the developers in the industry are by definition about average, and if average (or even somewhat above average) developers are finding their productivity much higher in Python and Go than they do in C, then they will start doing more work in those languages and less in C. In fact, that transition is exactly what ESR is describing in the article.

Certainly it seems that Go is usable for certain classes of problems that would formerly have been C's domain.

If by productivity you count the number of programs written, Python is not even close to Java.

I'd by productivity you count time to solution, a lot of applications written in python do not have performance requirements, which makes the comparison very unfair.

I cannot say for Golang.

> Raymond claims that Python is suitable largely for single-user applications operating "at human speed". This is so far outside the reality of how Python is used in industry as to call pretty much everything else Raymond writes in the article into question.

Could you elaborate? Are you talking about e.g. numpy and scipy? Python is good at calling C libraries but that doesn't make it good for writing an IP stack or a device driver or an OS. Are you arguing against the "single-user" point or the "human speed" point?

He didn't say "Python doesn't work well for IP stacks" (although: for special-purpose userspace IP stacks, people have done it). He said "Python only works for single-user human-speed use cases". Which, obviously, ignores the fact that every 3rd west coast SaaS tech company has Python at the core of their stack.

I predict that C++ will lose more ground to Rust and Go than C.

It's hard to find programming language that will cover as much low level programming needs as C. If some aspiring hacker turns 14 today and wants to get into the low level systems programming/embedded programmer career learning C well is a must. They may use some other language more, but they need to know C unless they want to limit themselves.

Some processors have stack size just 2-8 and memory available can be something like 128B - 8KB. Any replacement must have programing model that is very low level. Any replacement for C must have very low level and simple programming model.

Go... isn't really a system programming language. I don't get why people group Rust and Go together.

C++ may lose some ground to Rust but it may just end up saturated like Ruby, PHP did. Ruby is basically in steady state now. NodeJS jump in on a crowded market and got no where let alone it's crazy threadless model.

C++ btw have been pumping out new versions, C++17 was just completed by GCC and Clang is almost done. C++ is really trying to modernize.

Google whole backend is most likely C++... it ain't going no where.

Rust is a beautiful language but it still have a long way to go. And also resources such as books to help people jump on board not just general books either but books in different domain (scientific computing, data structure, web dev, etc.. whatever).

Plenty of people are working in node, for whatever reason. Just yesterday I was reading someone on HN saying backend JavaScript is the only way to make any money. Not that I think he's right, but if there are people out there thinking that I figure it has to have healthy enough marketshare.

How about FreePascal?

I haven't used it for very low level work, more for things like command line utilities (and with Lazarus for some light GUI app work). But the EXE/binary sizes are fairly small (without any optimization or stripping or compression). Also had used Turbo Pascal heavily much earlier. And I've read that Pascal at one time was used for systems programming; Apple may have been one company that used it (much earlier), and that their OS APIs were in Pascal. Windows API's (in Win32 at least) also may have had (not sure) some support for Pascal, viz. keywords like "long far pascal" in Win32 API code.

Side note: I wonder how many people use those abbreviations like viz. these days.

https://en.wikipedia.org/wiki/Viz.

Apple was not the only one, there were a few companies using Pascal dialects as their primary OS systems language.

And there are still some companies selling Pascal compilers for the embedded space, like this one https://www.mikroe.com/

They also sell Basic compilers.

Seems like an interesting and successful company.

In some ways, Rust fits that sort of ultra-tiny niche even better than C++. It doesn't have the POD/non-POD split that C++ has, it has a lot of built-in data layout optimizations, idiomatic code does far less copying, you can package up platform hardware definitions in crates, etc.

Of course C++ can just revert to being mostly C in these cases, and C is lightyears ahead in tooling and documentation here, but as a language I think Rust has a decent shot at that space.

I don't think so, just because modern C++ can coopt almost all Rust features with trivial style and tooling changes.

One of the benefits of being a truly actively developed language, as opposed to fossilized Java.

C++'s Core Guidelines have been worked on for the last two years, and weren't even trying to get full compatibility with Rust's guarantees, and still aren't really done yet. It's great work, but it's far from "trivial". If it were trivial to turn C++ into Rust, we wouldn't have bothered making Rust.

That's... not true at all. Even aside from the memory safety stuff steveklabnik mentioned in a sibling comment, C++ is struggling to get things like concepts, pattern matching, or modules, and had to do a lot of non-trivial work in the past to get things like move semantics.

And even then none of that solves the problems I mentioned in the comment you replied to.

Java is only fossilized on Google's Android fork.

Who knows, maybe it even gets value types before the C++ community can agree what modules are supposed to be.