I've slowly built up some personal thoughts about this subject that I think would be worth writing up more formally. For now, I'll provide a very high-level critique of this article.
>memory-safe languages that are usable for low-level programming like web browsers and operating systems, such as Rust and Swift, are only just starting to achieve popularity.
A web browser is not low-level - it is an application. A software component is low-level if it is primarily used by other applications. If you consider a web browser low-level, you must also consider a video games, text editors, audio players, etc low-level. I'm not saying that these things are easier or harder to develop, I'm just stating the fact that they are not low-level. Hence, a language like Rust which may very well be more appropriate to implement a web browser may not be the right choice for low-level software.
Operating systems, obviously, are low-level. But an OS is composed of many components working together - init systems, audio managers, application service buses, package managers, etc. I argue that Rust, Go, Swift, etc. are not suitable replacements for C and C++ in these areas.
The fundamental problem with these new languages is that it is difficult to expose system functionality as an external library. Notice - I state difficult, I am fully aware that in some languages it is technically possible. This has led to the implementation of primitive functionality through system daemons. For example, Ubuntu's Snap package management system now exposes its behavior through a daemon. These daemons use more energy than traditional libraries, more computational resources, and have a larger attack area.
My argument is that, even though some of these new languages may be appropriate for some applications, there is still a large class of software where C/C++ is the only practical choice.
I'm interested in looking at the impact of this effect on system reliability and performance for a more scientific analysis of this situation. To my knowledge, such a study has not been done.
Web Browsers are a platform that implements processes and process isolation, threading, networking, graphics, audio, all for other applications to use.
That’s a very good point. The modern web browser must be a low-level application.
Still, a web browser somehow seems different from other pieces of software on your system. This is because everything you just described is traditionally provided by the operating system. Hence, the browser has replaced the role of the operating system.
I believe my original critique still applies, but with some modifications. It may be appropriate to implement a particular low-level component (like a web browser) in one of these new languages. But that does not imply that all uses of C are inappropriate.
An interesting question is which complements are suitable for implementation in these languages?
To clarify: I’m reacting to what seems to be an umbrella recommendation by certain people to replace all software written in C with software in some other language, or that it’s inappropriate to use C for any new system components.
> Hence, the browser has replaced the role of the operating system.
Yup, I think this is becoming both metaphorically and literally true (I'm an ex-Chromebook user)
> I believe my original critique still applies, but with some modifications. It may be appropriate to implement a particular low-level component (like a web browser) in one of these new languages. But that does not imply that all uses of C are inappropriate.
Sure. I don't think one implies the other, personally.
> An interesting question is which complements are suitable for implementation in these languages?
Rust can be used to do anything C can do, with some small exceptions like "support 1970s hardware" or some practical exceptions like "this proprietary chip comes with a c compiler only" or "there's no port to my platform yet even if there could be."
The web browser does not implement. It delegates. There is a difference. It provides a layer through which a webpage or client can access those resources, but it is not, nor will it ever be low-level. It sits astride the fundamental subsystems that make the computing machine usable.
Don't get me wrong; browsers are impressive. Computers have far more that goes into them than network traffic rendering. Most people just enjoy the luxury of abstracting it away.
>memory-safe languages that are usable for low-level programming like web browsers and operating systems, such as Rust and Swift, are only just starting to achieve popularity.
A web browser is not low-level - it is an application. A software component is low-level if it is primarily used by other applications. If you consider a web browser low-level, you must also consider a video games, text editors, audio players, etc low-level. I'm not saying that these things are easier or harder to develop, I'm just stating the fact that they are not low-level. Hence, a language like Rust which may very well be more appropriate to implement a web browser may not be the right choice for low-level software.
Operating systems, obviously, are low-level. But an OS is composed of many components working together - init systems, audio managers, application service buses, package managers, etc. I argue that Rust, Go, Swift, etc. are not suitable replacements for C and C++ in these areas.
The fundamental problem with these new languages is that it is difficult to expose system functionality as an external library. Notice - I state difficult, I am fully aware that in some languages it is technically possible. This has led to the implementation of primitive functionality through system daemons. For example, Ubuntu's Snap package management system now exposes its behavior through a daemon. These daemons use more energy than traditional libraries, more computational resources, and have a larger attack area.
My argument is that, even though some of these new languages may be appropriate for some applications, there is still a large class of software where C/C++ is the only practical choice.
I'm interested in looking at the impact of this effect on system reliability and performance for a more scientific analysis of this situation. To my knowledge, such a study has not been done.