[bitc-dev] What is a "Systems Programming Language"
Jonathan S. Shapiro
shap at eros-os.org
Sat Jul 27 10:29:58 PDT 2013
Reading through the Rust blog entries, I'm starting to have the sense that
their definition of "systems programming language" doesn't match mine.
David Jeske has made some comments here that suggest *his* definition
doesn't match mine either. I think it's worth bringing that discussion out
into the open and making it explicit.
The Rust team's tacit definition of a systems language seems to be:
1. A language that permits prescriptive stack allocation, in which
2. Explicit storage management is preferred on the grounds that it *
allegedly* minimizes overheads.
I'm sure that I'm leaving some things out, and I don't mean to be unfair by
doing so. Heres how *I* would state the requirements for a systems language:
1. Is a *great* general-purpose language that
2. Supports prescriptive stack allocation
3. In which run-time expense of computing statements and expressions is
understandable to the experienced programmer
4. In which that run-time cost understanding is reasonably balanced
against compilation techniques like inlining and template expansion - C++
fails this test, not because it *has* these features, but because of the
way in which these idioms are commonly used.
5. In which certain types of safe, prescriptive storage management are *
possible* when algorithms are written by expert programmers.
The difference between these positions is admittedly subtle. The main point
is that no successful systems programming language can ever be *just* a
systems programming language. In order to be a successful systems
programming language, it has to be a successful language more generally. In
several places, that leads to different choices than the Rust team has made.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev