> if it compiles, then it’s correct … or at least, will not contain use-after-free or other memory safety errors
In a language with the `unsafe` construct and effectively no automated tooling to audit the uses of it. You have no guarantee of any significance. You've just slightly changed where the security boundary _might_ lie.
> There is a great amount of software already written in other languages.
Yea. And development of those languages is on going. C++ has improved the memory safety picture quite a bit of the past decade and shows no signs of slowing down. There is no "one size fits all" solution here.
Finally, if memory safety were truly "table stakes" then we would have been using the dozens of memory safe languages that already existed. It should be blindingly obvious that /performance/ is table stakes.
Cargo allows you to apply rustc lints to the entire project, albeit not dependencies (currently). If you want dependencies you need something like cargo-geiger instead. If you find unsafe that way, you can report it to the rust safety dance people, who work with the community to eliminate unsafe in crates.
All of this is worlds ahead of the situation in C++.
OP is wrong that there's no tooling. All the C++ tooling that I'm aware of (e.g. ASAN/UBSAN/MSAN/TSAN) is still available on Rust. Additionally, it has MIRI which can check certain code constructs for defined behavior at the MIR level which, unlike sanitizers, validates that all code is sound according to language rules regardless of what would be run by generated assembly; this validation includes unsafe code which still has to follow the language rules. C/C++ doesn't have anything like that for undefined behavior by the way.
However, if I can apply a nitpicking attitude here that you're applying to their argument about the ease with which unsafe can be kept out of a complex codebase. unsafe is pretty baked into the language because there's either simply convenient constructs that the Rust compiler can't ever prove safely (e.g. doubly-linked list), can't prove safely today (e.g. various accessors like split), or is required for basic operations (e.g. allocating memory). Pretending like you can really forbid unsafe code wholesale in your dependency chain is not practical & this is ignoring soundness bugs within the compiler itself. That doesn't detract from the inherent advantage of safe by default.
I do safety critical code. I would consider banning allocation (e.g. just using Core) or avoiding certain data structures a completely feasible strategy to avoid unsafe if I wanted to exclude it from my safety model. It's what I'm already doing in C++. The difference is that in C++, I can never prove the absence of undefined behavior from any part of the codebase, even if I review every single line. Even if I could, that proof might be invalidated by a single change anywhere.
Languages with unsafe don't just change where the security boundary lies. It shrinks the size of the area that the boundary surrounds.
C++ has artificially limited how much it can improve the memory safety picture because of their quite valid dedication to backwards compatibility. This is a totally valid choice on their part but it does mean that C++ is largely out of the running for the kinds of table stakes memory safety stuff the article talks about.
There are dozens of memory safe languages that already exist: Java, Go, Python, C#, Rust, ... And a whole host of other ones I'm not going to bother listing here.
The Java language specification is open and there are multiple implementations. OpenJDK is the official open-source reference implementation, and many of the alternative implementations pull from upstream, but OpenJ9 is a different JVM implementation (though does currently use OpenJDK's class libraries to form a complete JDK.)
Before Microsoft opened-up C#, Mono was a completely independent alternative implementation.
Python has CPython (reference open source implementation), but also PyPy, MicroPython and several others.
I'm not sure what you mean when you say the Java spec is open, but Oracle certainly took the position—and the Supreme Court confirmed—that they own copyright in the APIs.
Has Oracle dedicated those to the public domain in the meantime? Or at least licensed them extremely permissively?
More importantly, is there a public body that owns the spec?
>the Supreme Court confirmed—that they own copyright in the APIs.
To use your own terminology, this is clearly and objectively false. The US Supreme Court made no such finding.
What the court concluded was that even if Oracle had a copyright on the API, Google's use of it fell under fair use so that making a ruling on the question of whether the API was protected by copyright was moot.
Your point of order is partially accurate. It was the Federal Circuit that held APIs copyrightable. SCOTUS did not disturb that holding, but did not explicitly affirm it either. However, your contention that this makes copyrightability moot is a stretch.
The majority opinion in Google v Oracle did an involved fair use analysis for the reimplementation of the API that really makes it clear that it's hard for anybody to violate the copyright of an API by doing a clean-room implementation and not have it be covered by fair use.
But who cares if there's a public body who owns the specification? The Supreme Court ruled Google's use of the copyrighted APIs fell within fair use. That gives, within the US (other countries will have other legal circumstances) a basis for anyone to copy pretty much any language so long as they steer clear of the actual copyrighted source code (don't copy MS's C# source code, for instance) and trademark violations.
I don't understand your thought process. You seem to be arguing that whether something has a proprietor is irrelevant to the question of whether it is proprietary. I cannot fathom the kind of reasoning that would lead to such a conclusion.
If the language is owned—by control and by IP—by a single corporation, it is proprietary.
Anyone can implement a compiler or interpreter for C# if they want, and there is a link to the standard for it. Is this clear enough for you?
Also, from an earlier comment you made a false claim and a strange reference.
You claimed that "most of" Java, Rust, C#, Python, and Go have only a single implementation. This is false. There are multiple implementations of each.
Second, you make a bizarre reference to "fad[ing] away like Pascal." Why do you think Pascal faded? I'll give a hint: It had nothing to do with being proprietary. At best that reference is a non sequitur, at worst it demonstrates more confusion on your part.
It isn't my reading comprehension that is deficient. You are talking in circles and demonstrating a remarkable inability to think clearly. I was just being polite.
Something being proprietary means that it is owned. It means "relating to an owner or ownership"; "of, relating to, or characteristic of an owner or title holder"; "used, made, or marketed by one having the exclusive legal right"; "privately owned and managed and run as a profit-making organization."
All of these have implementations available under free software licenses so they are clearly and objectively not proprietary.
Trademarks are annoying but I can hardly imagine they're what anyone is worried about when picking a language in this context, they're not what's going to cause a language to disappear.
A trademark on the word "Rust" has nothing to do with whether the language itself is proprietary. Clearly and Objectively.
What you can call something and whether you can legally make the thing or have a permissive license to an existing implementation are two completely unrelated things.
For example, you also can't make a C compiler and name it the "microsoft C compiler" due to your lack of trademark right. Does that mean C is also proprietary?
> Proprietary software is software that grants its creator, publisher, or other rightsholder or rightsholder partner a legal monopoly by modern copyright and intellectual property law to exclude the recipient from freely sharing the software or modifying it, and—in some cases, as is the case with some patent-encumbered and EULA-bound software—from making use of the software on their own, thereby restricting their freedoms.[1]
> Proprietary software is a subset of non-free software, a term defined in contrast to free and open-source software; non-commercial licenses such as CC BY-NC are not deemed proprietary, but are non-free. Proprietary software may either be closed-source software or source-available software.[1][2]
The Python development team, via the LICENSE file in the GitHub repository, tells me
> All Python releases are Open Source (see https://opensource.org for
the Open Source Definition). Historically, most, but not all, Python
releases have also been GPL-compatible; the table below summarizes
the various releases.
Safe rust is a safe language. Yes, it is built upon unsafe rust. But I still consider Python to be a memory safe language despite it being built on C. I can still trust that my Python code doesn't contain such memory errors. Safe Rust is the same in terms of guarantees. That's all that anyone is claiming.
The main problem now is that there isn't a platform that has the tooling or infrastructure to prove, including through formal methods, that they are correct and free from bugs in the spirit of the seL4 project.
That's an extreme take now and maybe uncharitable. The safe parts of rust are simply no comparison to the whole c/c++ world: the tooling is eliminating vast swaths of "easy" errors. Unsafe parts might be comparable if they're calling the same libraries.
> It should be blindingly obvious that /performance/ is table stakes.
Nah, there's a famous WG21 (the C++ committee) paper named "ABI: Now or Never" which lays out just some of the ever growing performance cost of choices the committee has made to preserve ABI and explains that if this cost is to be considered a price paid for something the committee needs to pick "Never" and if they instead want to stop paying the price they need to pick "Now" and, if as the author suspects, they don't actually care, they should pick neither and C++ should be considered obsolete.
The committee, of course, picked neither, and lots of people who were there have since defended this claiming that this was a false dilemma - they were actually cleverly picking "Later" which that author didn't offer. Each time they've repeated this more time has passed yet they're still no closer to this "Later" ...
In a language with the `unsafe` construct and effectively no automated tooling to audit the uses of it. You have no guarantee of any significance. You've just slightly changed where the security boundary _might_ lie.
> There is a great amount of software already written in other languages.
Yea. And development of those languages is on going. C++ has improved the memory safety picture quite a bit of the past decade and shows no signs of slowing down. There is no "one size fits all" solution here.
Finally, if memory safety were truly "table stakes" then we would have been using the dozens of memory safe languages that already existed. It should be blindingly obvious that /performance/ is table stakes.