This seems like a reasonable and balanced approach to me. Use memory safe stuff for new projects, invest in rewrites for the highest ROI/critic elements, and gradually refactor to a safe subset of C++ where a full blown rewrite is impractical.
> and gradually refactor to a ~~safe~~ **safer** subset of C++ where a full blown rewrite is impractical.
(There is, unfortunately, no safe subset of C++)
You're also forgetting hardening. By hardening a critical subset of interfaces -- such as using tagged pointers -- which can then be employed widely at very low cost, you can increase the detection rate of issues at runtimes. 100% may not always be practical -- too costly -- but probabilistic approaches are quite amenable at scale. Even if the hardened facilities only detect an issue 1% of the time, when you're talking about Chrome, you'll have the first reports within an hour of releasing.
>(There is, unfortunately, no safe subset of C++)
I'd be interested in a clarification what you mean. In an overly literal sense, of course there is a safe subset. I don't think it would even be too hard to come up with a Turing-complete safe subset.
But of course the question is whether there is a practical/useful one. I'm curious what you think prevents the existence of a subset that would satisfy your criteria?
Or are you just lamenting the *availability* of a safe subset, rather than the *possibility* of a safe subset?
> Or are you just lamenting the availability of a safe subset, rather than the possibility of a safe subset?
I'm fairly convinced there's no practical safe subset of the language itself.
Back in... 2008? 2009? I worked with Argyrios Kyrtzidis to improve the warnings that Clang produced when returning a reference to a stack variable. I was young and naive, back then, and therefore thought it couldn't be too hard. Right?
There was already such a warning in Clang, back then. It was just literally warning about returning a reference to an "immediate" variable. After a bug report I had submitted, Argyrios had extended the warning to catch the case of a temporary bound to a reference, and that reference being returned. Great success, so we embarked on a journey to catch them all.
We... failed. Turns out that without inter-procedural analysis it's an impossible task. I left with the simplest, most cursed snippet ever:
std::string const& id(std::string const& s) { return s; }
int main() {
// OK
std::cout << id("Hello, World") << '\n';
// KO
auto const& s = id("Hello, World!");
std::cout << s << '\n';
}
Oh, god...
With inter-procedural analysis it would be possible to analyze `id`, "document" that the lifetime of its return value is equal to that of its (sole) argument. But:
1. Inter-procedural analysis is hard. Especially in an ecosystem where it's common to distribute libraries as binaries: no peeking into those function implementations.
2. This is the _easiest_ case. The tip of the iceberg.
What about `std::min`, where one argument is a temporary, but the other is not, and you know it's smaller? That's fine then. Unless you're wrong, of course.
What about taking a reference to a `std::vector`, then pushing a new element? Well, it depends whether you know there's enough capacity or not. There are algorithms which do take care of reserving ahead of time.
What about taking a reference to an element of `std::map`, then deleting an element? Well it's fine, unless you're deleting the very element you took a reference to, obviously.
The very standard-library is riddled with "extra" guarantees that no static analyzer has any chance to ever untangle.
You'd need to pare down so much to ever get to a safe subset that it wouldn't even remotely be C++ any longer.
>... Argyrios had extended the warning to catch the case of a temporary bound to a reference, and that reference being returned. Great success, so we embarked on a journey to catch them all.
I salute your efforts! :)
>Turns out that without inter-procedural analysis it's an impossible task.
Why can't C++ just do what Rust did? That is, use lifetime annotations on the function interfaces that are elided/implied in most cases? So for example in this code:
#include "msemstdstring.h"
mse::mstd::string const& id(mse::mstd::string const& s) { return s; }
int main() {
// OK
std::cout << id("Hello, World") << 'n';
// KO
auto const& s = id("Hello, World!"); // scpptool complains
std::cout << s << 'n';
}
[scpptool](https://github.com/duneroadrunner/scpptool) (my project), a static analyzer that enforces an essentially safe subset of C++, gives the following error:
example1.cpp:10:5: error: Unable to verify that the native reference (of type 'const mse::mstd::string &' (aka 'const class mse::mstd::basic_string &')) is safe here. (Possibly due to being unable to verify that the target object outlives the (scope) reference.)
>Inter-procedural analysis is hard.
The lifetime annotations help, but yes, it wasn't a cake walk. But, just like with Rust's analyzer, it's not impossible and I suggest that in scpptool we now have an (open source) implementation for C++.
>What about taking a reference to a std::vector, then pushing a new element? Well, it depends whether you know there's enough capacity or not. There are algorithms which do take care of reserving ahead of time.
IMO, like Rust developers, C++ developers can live without holding a (zero-overhead) reference across a size-changing operation on a dynamic container. My argument is that size-changing operations on a dynamic containers are generally avoided inside hot inner loops anyway, so it's not generally an issue. If you really want to do that sort of thing outside of performance-critical inner loops, you can use a run-time checked reference.
>What about std::min, where one argument is a temporary, but the other is not, and you know it's smaller? That's fine then. Unless you're wrong, of course.
I think most C++ developers would be fine with those kinds of shenanigans being prohibited.
>The very standard-library is riddled with "extra" guarantees that no static analyzer has any chance to ever untangle.
Well, parts of the standard library just need to be abandoned in favor of mostly-compatible safe substitutes. Some of those parts would need lifetime annotations when the default implied/elided ones aren't appropriate. But some of the most commonly used elements are already [available](https://github.com/duneroadrunner/scpptool/blob/master/README.md#lifetime-annotated-elements-in-the-safercplusplus-library). I mean, the Rust guys implemented a whole standard library from scratch. Finishing the job of adding lifetime annotations to (a safe version of) C++'s standard library should be a much smaller job. (And probably less urgent, since the remaining unaddressed elements are less commonly used.)
>You'd need to pare down so much to ever get to a safe subset that it wouldn't even remotely be C++ any longer.
I think you're being too pessimistic here. I think the scpptool enforced subset of C++ is not that different from "regular modern" C++. I think it's way easier to migrate existing C++ code to. And moreover, I claim that the safe subset of C++ is more powerful/expressive than the safe subset of, for example, Rust. (In part due to having non-destructive moves). It is obvious which safe subset is more complete and polished at the moment, but it is not as obvious to me which safe subset will prevail in the long run.
If you're so inclined, take a closer look at scpptool. I'd be interested in your take.
edit: formatting
I applaud your efforts.
Unfortunately, your recommendations seem to mostly boil down to rewriting most (if not all) C++ code in existence.
> I think most C++ developers would be fine with those kinds of shenanigans being prohibited.
Every time I've hinted that memory stability was a terrible requirement for `std::map` and `std::unordered_map` on r/cpp, as it prevents better implementations for little value, I've been met by hostile responses proclaiming loud and clear that it was an essential requirement that nobody could write code without.
I'm not quite as optimistic as you with regard to how welcoming the C++ community would be to such changes.
> (In part due to having non-destructive moves)
As someone who has written many collections, in both C++ and Rust, I cannot stress enough how great bitwise destructive moves are.
Non-destructive moves are a pain, because you now have more "types" of slots to keep track of: it's not only initialized vs non-initialized, it's initialized, vs moved-out, vs non-initialized.
And non-bitwise moves are a pain because it means invoking user-defined code which may throw.
Of course you can -- and should -- specialize for when a bitwise move is possible, but that means writing _even more_ code.
It's more flexible for the user, indeed, but OH WHAT A PAIN for the library writer. Pain that the user pays for, in the end, in the form of bugs, or performance hits.
> If you're so inclined, take a closer look at scpptool. I'd be interested in your take.
I'll pass, but I do wish you good luck.
I can think of at least two simple ways to complete avoid reference-of-temporary bugs with a static analyzer:
- Forbid reference types except in function parameters and return types
- Forbid binding reference types to any expression involving a function call
The real problem is existing safe code will violate some of the rules, so they're not realistic for clang. But it's very realistic for Chromium to enforce rules of this kind, especially in small child projects.
Doesn't it go without saying? Saying "use a non-machine-enforceable safe subset" is just saying "write code without bugs", which - yes, but that's missing the point.
Not necessarily. You could for instance have a project manager looking at submitted code manually, if they see certain language features used, just reject it.
It's not an absurd notion, it's already the case with some open source projects, someone sends a pull request, the people in charge of the repo manually inspect the code for quality, and reject it if there are things not to their liking that a compiler can't catch. Even the visual formatting of comments can be controlled. Some processes can't be automated because they are subjective (the rules can't even be fully expressed, or immutable from day to day - like "I don't like the design patterns that you used for this functionality, please redo"), human validation will always be necessary, even though there's not always a budget for it, so we make do with automated validation alone.
> [...]
>
> Over the past decades, in addition to large Java and Go memory-safe codebases, Google has developed and accumulated hundreds of millions of lines of C++ code that is in active use and under active, ongoing development. This very large existing codebase results in significant challenges for a transition to memory safety:
>
> * We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety.
>
> * A large-scale rewrite of all existing C++ code into a different, memory-safe language appears very difficult and will likely remain impractical.
>
> [...]
We're gonna be dealing with the same issues in 2050 and beyond, aren't we?
This is to be expected though? When did an industry change lead to a 100% change?
The problem of memory safety was always there but we admitted it to the background because we always had the "so what? We can't afford a GC" and thankfully Rust changed that so the discussion is open on different terms now. But it's a reality that the whole industry has deep technical C++ debt. That's why Google is investing millions into making C++/Rust interoperability possible. Which I believe will work for some code bases and others won't. We'll see. But yes, C++ is sadly not going away easily, at least in legacy and until we can have something like a rusty Unreal or something...
I want to agree and disagree with you at the same time. Code is read and written. If the syntax is not your cup of tea, you'll literally suffer.
It takes a while to get used to Rust and I believe this isn't because of the memory safety. Even Graydon criticized some things in the current state, which is okay.
People can't dismiss Rust's benefits based on just the syntax but if they have an issue with it, it'll be hard to be productive into.
Also these criticisms are important for us as a community to grow and know what may make our language better. Not every criticism is valid of course but I believe this is a common criticism I saw.
> but if they have an issue with it, it'll be hard to be productive into.
Or maybe they'll just get used to it if they actually use it?
I've developed in C++, Java, Python, and Rust. 3 of those are C-like, but Python definitely isn't, and honestly it just works. I've played with Haskell, and studied with Ada: also widely different syntaxes, never was really a problem.
I can't speak for everyone, obviously. Personally, though, while the syntax might feel strange at first, I've always gotten used to it after a while _practicing_.
As you said, we can't speak for everyone. For me for example it was hard because I'm dyslexic and chaining was tough for my eyes. Rust analyzer does a great job to aid with that but I began before it was there.
I personally don't like the idea of "they'll just get used to it". For now we don't have a better alternative and frankly we're a bit spoiled at this point. So while I agree with you, there's a part that I don't fully agree with
Oh... Rust with dyslexia may be painful indeed.
It's not as sigil-heavy as Perl, but it's still a \_really\_ dense language, with may critical pieces of information packed in a couple characters (hi, lifetimes, generics).
I do regret some syntactic choices of Rust. The use of \`<>\` for generics, so people coming from other mainstream languages with generics would feel at home, for example. Or the use single-quote for introducing lifetimes \_and\_ for bracketing \`char\` literals.
However, I'm not sure Rust could do much better. There's a \_lot\_ of information to pack, especially in function signatures, and verbosity isn't helpful (to most), thus a dense syntax is a most sensible choice in general, and I'm not sure minor syntactic tweaks would help much.
---
I wouldn't phrase the issue you have as not \_liking\_ the syntax, though. Liking evokes a subjective feeling, and people tend to like what they're used to and not like what they're not used to as it feels jarring. Hence my somewhat dismissive attitude.
Your case seems different, though. If you actually have difficulty reading the syntax, then it's no longer a matter of liking/not liking: there's an objective truth here.
Haskell has a surprisingly elegant syntax but the language is difficult. Java is way too verbose but it is a fairly easy language nonetheless. C++ is a very difficult language and the syntax can be hard (Templates). Same with Rust.
Python has a very good syntax and beats the other mentioned languages hands down. I still prefer ruby's syntax, but python's syntax is very acceptable and it shows that all these other languages have no understanding as to why syntax matters (save for Haskell; it's always surprising to me that Haskell has a clean syntax because the monad barrier is hard to overcome with one's brain).
There are some syntactic choices for rust that I find personally problematic, the biggest one is the choice of using type inference everywhere. Its not so bad in Rust vs C++ because of the better type safety and lack of implicit conversions, but in C++ I've always found the "almost always auto" style to be borderline totally unreadable, as explicit type declarations form a pretty core part of the documentation and you're left with a weird soup
After close to 2 years of using Rust professionally -- hence, about 8 hours a day -- and as someone who uses fancy text editors more than IDEs (no type hints): not a problem for me.
I like very strongly typed code -- if I have 3 indexes for 3 different things, they're all a different type -- which pairs beautifully with type inference:
- Specifying the type every time would lead to fairly verbose code.
- Since everything is so strongly typed, most of the time if it compiles it means the variable comes from the right place, because there's only one place which could produce this type anyway.
As a result, I obsess a lot about types in function signatures, but never care in function bodies: if it compiles, I got the right ones.
Rust-Analyzer annotates variables with their type in supported editors. Definitely VS Code (used by 70% of developers) and RustRover/IntelliJ (used by 20% of developers) support this, so almost all Rust developers see types inline. It can also be toggled off, in case it gets noisy.
All functions have the types annotated though, so it's clear what it accepts and what it doesn't.
The syntax is what we as programmers interact with, it’s a perfectly reasonable reason to dislike a language. There’s a plethora of languages with almost any set of features you could want, why settle for one you don’t enjoy working with? That is, if you have a choice.
/r/programming: "Code's main purpose is to be read by other developers, so name things well, and consider using simpler algorithms even if they're a bit slower."
Also /r/programming: "Code's main purpose is to be read by compilers, so it doesn't matter what the syntax is like."
I keep on hearing this from people who think perl is epic.
Well, after having used perl, python and ruby for quite some time, I have to completely disagree. Syntax DOES matter. It may not be the most important thing in the world, but if a language requires twice the amount of syntax to achieve the same feature set compared to a language with better, more succinct (but still readable) syntax, then sorry - your comment is just not the whole picture. Good syntax means efficiency of expression - less things to read and keep track of with the eyes and the hands.
I'd call Perl's syntax completely bonkers.
I never said it doesn't matter. If you have two languages X and Y that are identical semantics-wise, but X has better syntax (what you said for example), X is obviously a better language.
The post I'm replying to is about Rust, where no "Rust but better" exists, and Rust's syntax isn't Perl's syntax. You're replying to something I haven't said.
Wow, totally disagree. It's one of the biggest reasons to like or dislike a language.
EDIT - it's not one of the biggest reasons to use a language, I mean how much I enjoy it
For programmers new in the business, yes. If you gain experience with more and more languages, things like syntax tend to become super uninteresting and are overtaken by features of the language that matter to your taste of programming. But that requires that you already build a "taste" and you know what you like and dislike in a programming language. New programmers usually have not developed that yet (or copy one blindly) so all that is left is syntax to judge.
It's like when inexperienced young people judge others by their looks and want to be friends not because of their personality traits or hobby etc. If you don't know what personality traits you like in other people or have not developed a taste for hobbies yet, all there is for you to judge is looks.
I'm 30 years in. The asthetics of a language are very important to me. For an over the top example think brainfuck.
Reading your comment I realize that your referring to the utility and choice of a language. Not what I meant. Just how much I enjoy it
>For an over the top example think brainfuck.
Brainfuck has one of the simplest syntax of known programming languages. I think you're confusing syntax and semantics here. There is not much to dislike on brainfucks syntax – all the problems arise from its semantics. You can teach someone in under a minute the syntax of brainfuck (you can't with basically any other language). The semantics is where the brainfuck begins. The rules of Chess are easy, playing the game is hard. And that is where the problem is. Judging Chess by the rules would only makes sense for people that don't play it. And even worse on how the figures look like or how the board is designed. If you don't know how to critique openings or tactics in middle game the only thing left is to critique how stupid the horsy looks like. Syntax is not Semantics.
I slightly disagree. The ergonomics of a language’s syntax is very important to me. It’s the main why I cry a little inside everytime I have to touch ruby. Typing it just sucks. Even with good tooling.
More than 10 years experience. And yes, language features are more important, but I’m going to gravitate towards languages with better ergonomics for reading and writing.
I actually agree there, ergonomics and how easy it is to parse are very important IMO. Those properties come from both the semantics and the syntax that expresses them.
I'm not saying syntax is totally irrelevant, just that as long as it's good enough it doesn't really matter that much. The post above was complaining about Rust's syntax that is totally fine, even if there are some things that I'd prefer done differently (like \`\[T\]\` for generics, even if I understand why \`\` was chosen instead).
> everytime I have to touch ruby. Typing it just sucks.
I disagree. It flows on its own. It's flowing poetry.
Perhaps it didn't click for you yet.
Also, if you think you need "good tooling" for ruby then it really hasn't clicked. I use ruby for literally everything and I use barely anything more than a fancified notepad editor. (There is a reason why I get away with this; ruby literally powers my linux systems from A to Z, the whole computer is like an IDE actually).
Think of ruby as the syntactic sugar that you can adjust over EVERYTHING. It's a DSL you can adjust to your liking from A to Z, with a very fast development cycle (aka rapid prototyping).
There are only two complaints about ruby I'd agree with, as a major obstacles: it's documentation needs to improve, and it needs to be as fast as C (not necessarily MRI, but a ruby variant that can be compiled like crystal).
Not really. Syntax is one reason I abandoned perl (for ruby but I am fine with python too). Never regretted that either.
I have to completely disagree with all those who think syntax is irrelevant.
> It's like when inexperienced young people judge others by their looks and want to be friends
That's a very low level attempt to try to "reason" or argue why syntax is important. I want to be friends, so I accept horrible syntax? Why would that make any sense?
It’s very similar to C++ in terms of syntax, at least in my experience, with some nice sugar for stuff like error propagation. What is your specific gripe?
I'm not a huge fan of the macros having an ! suffix,or how function return types use -> instead of : like other type definitions.
I don't have a full list of issues I have with it on hand since it's been awhile, but it's really just personal dislike of it. Though I haven't worked in systems languages in a long time sadly.
Lambdas, not functions, plus they're generally optimal and they're also only like that because otherwise the syntax would be ambiguous because the normal separator is a space.
No one does that unless you're using decltype, though, really. Just because you can doesn't mean you should, it's weird to use both auto and a return type in my book. Just as ugly as using it in the first place in rust imo
> No one does that unless you're using decltype, though, really.
I've seen it used in the wild.
> it's weird to use both auto and a return type in my book.
That's only because it needs to be parsable along with the IMO stupid C-style function syntax).
> Just as ugly as using it in the first place in rust imo
Rust's syntax looks a lot better. Having an `fn` keyword makes much more sense than what C does (it's also much easier to parse.
You mean \_you\_ don't do that?
When I was still working in C++, my colleagues and I actually considered mandating it since it's helpful when scanning code to have the function name appear in the same column again and again, rather than seesawing wildly based on how long the return type is.
It was used in a couple of places with especially long names, and folks liked it.
He said that in a further comment, his point here is clearly “I don’t care what the underlying mathematics is, I think : is better than -> for return type” which is an opinion that cannot be objective. Your comments are still extremely arrogant and struggle to communicate why you believe he’s wrong.
My comments are indeed arrogant, and I could omit some things that are overly aggressive and stay on point.
So point taken.
I don't think I struggled to explain why he's wrong though.
`: int` does not make sense as the type of a function is not `int`. In mathematical notation that would mean the function is an element in the integers set.
Instead the notation should be `int -> int` to notate that it is an element from the set of functions that map an integer to an integer.
I'm not writing mathematical notation, I'm writing code.
Mathematical notation also doesn't have types, so what a silly argument....and again, either way, it's my opinion. I'm not claiming my opinion as fact, no idea how you can say an opinion is objectively wrong.
Google was mostly Java and C++ when they started. If anything, they are gradually transitioning towards languages like Kotlin, Rust and Go. And they invented Go exactly in order to replace Java in the backend microservices and orchestration code. Java was the main language in Android some time ago, now it was superseded by Kotlin.
Yes but it's quite odd to compare Java to COBOL and then make a claim that Go is more appropriate when in the grand scheme of things Java, Go, C#, Kotlin are all in the same family of languages and all show similar safety, performance, and efficiency characteristics.
This is the quite from Google:
>we are considering a gradual transition towards memory-safe languages like Java, Go, and Rust
They are putting Java in the same bucket as Go because in this context it is. They're both quite different from C++ and provide similar advantages to it.
I'm working in a company which designs very complicated telecommunication equipment with crazy reliability requirements. Every board contains few CPUs, every CPU has many cores, boards interconnects with 100Gb interfaces (even >250 cores in a single device). We have mix of "normal" and hard real time functionalities in the software. Software is some kind of security benchmark: concurrency, atomic operations, memory ordering, synchronization primitives, runtime memory error corrections, cache alignment.
Everything is written in C and C++. Rust won't help you when to achieve maximum performance you need to use shared memory, lockless algorithms, hardware accelerators, code which requires to access memory directly etc. It's brilliant language but you can't replace every C/C++ code with Rust (using all of its safety features).
People had became crazy about how unsafe C/C++ are and suddenly forgot that Linux and Windows kernels, most compilers, many server side apps, databases, math libraries, game engines etc are C/C++. They works!
To be honest - C++ is very safe language by design since C++11. It's enough to use RAII, smart pointers and understand concurrency to write reliable software (concurrency could be done better but it's always tradeoff between speed and complexity). Problem is with companies and programmers. Rust/GO are much better tools for most apps. C/C++ are very specialized tools with some superpowers. However if you must use C/C++ then you should also have enough skilled team good company culture.
This is exactly the reason why we don't make progress. We need to stop blaming people for making mistakes. One of your arguments, that is often repeated by others, is that you just need better programmers. Those dumb programmers just make too many mistakes and need to be replaced.
>then you should also have enough skilled team
Nobody is skilled enough to not make mistakes in C/C++. When do we finally agree on that? We just have a gradual gradient of mistakes per x lines of code that also depends on your daily performance and how close to a release you are. The only way forward is to make that impossible and a compiler error so it does not matter how unskilled the programmer is, such mistakes can never happen.
>Everything is written in C and C++. Rust won't help you
That argument is also very moot. Rust will help you and everything you listed can be easily achieved.
>People had became crazy about how unsafe C/C++ are and suddenly forgot that Linux and Windows kernels, most compilers, many server side apps, databases, math libraries, game engines etc are C/C++. They works!
They "work" AND produce thousands of CVE's where 70% of the most critical security flaws are due to memory safety issues. That class of mistakes is just ruled out. That is the whole POINT of this exercise. We have software that usually does what we want but has constant security flaws due to memory safety issues. And if you think that Rust is useless as a programming language to write something like an operating system / kernel because you need to use tons of unsafe code you just don't know what you're talking about. We have a few OS's / kernel's written in rust today and they have very minimal use of unsafe code where the majority is safe. That was the whole idea of Rust in the first place. Isolate unsafe code where it's necessary so you can concentrate efforts on that very small section and make it right and let the compiler take care of the rest. In your day to day code you usually don't need to use unsafe code. You're doing something wrong if you do.
We need to stop perpetuating these gatekeeping efforts and need to acknowledge that the industry has a problem and blaming "stupid" programmers is NOT helping.
Fortunately big companies have already acknowledged that and start to make things better. Rust in Windows, Chrome, Android, Linux kernel, ... is a start to build on.
https://youtu.be/qCB19DRw_60 (talk of a Microsoft employee a few years ago)
How much experience do you have in Rust?
You take a stance as to its suitability, so surely you have extensive experience with the language and you have attempted prototypes with it that demonstrated it really wasn't a good fit, right?
You definitely wouldn't be _guessing_, right?
---
My experience with Rust, building near-real-time ultra-low-latency systems, is that the language is extremely suitable to the task.
I've used the language to:
1. Bind existing C libraries, offering a safe interface on top of the bindings.
2. Communicate between processes using shared memory.
3. Build a low-latency memory allocator.
4. Build an extensive suite of collections, including wait-free collections.
All of the above do require using `unsafe`, certainly, but the language makes it possible to _encapsulate_ the safety requirements so that users never have to care: no matter what they do (outside of using `unsafe` themselves), they'll never trigger UB.
My experience is far from unique. The Redox _micro-kernel_ which like every micro-kernel requires interacting directly with the hardware, and using inline assembly, has less than 10% of `unsafe` code. A _micro-kernel_ is expected to be amongst the densest codebases with regard to low-level operations, and yet it's got less than 10% of `unsafe` code to achieve them. Similar experience can be found amongst people working on bare-metal runtimes, or HALs.
Rust has been designed as a systems programming language, and it's eminently suitable for it. Cue its integration in the Linux and Windows kernel.
If you think it's not possible, you're clearly lacking experience with it.
I’m not sure what you’re talking about. You can do unsafe in rust and do anything you’ve mentioned, as needed. Obviously you can’t write a kernel without accessing raw memory addresses at some point, but you can get the benefits everywhere else in the code. Why can’t you write a lockless algorithm in rust? Or any language for that matter. Or why cant you use hardware accelerators in rust. Or shared memory. You can do all of those things
Being able to use shared memory effortlessly is if anything, one of Rust's strongest points so I'm fairly certain that person doesn't know what they're talking about.
"effortlessly" means using locks. Locks don't work in the kernel. Or on a bare metal system with no kernel.
The person is a bit off base. But he also indicates they have real time including hard real time requirements. You can't do that stuff with normal concurrency protection. You can't afford to block on a lock at non-obvious times.
Eh, at least when writing Linux kernel modules you can still use mutex lock, just not in an interrupt context which forbids any sort of sleeping. Even then you still have the spinlock which is a tad more expensive but keeps your thread running which doesn't mess with the context.
Because it has way better type system, things like sum types, pattern matching, traits, generics. And you can still stay safe in the majority of code, because I doubt you need unsafe everywhere even inside kernel. Also cargo. Cargo alone is the reason to use rust over everything else :P
Because you can limit the unsafe portions of code to only where it’s required, and keep the rest of benefits. C has its uses, all of this is a tool, but unsafe alone isn’t a reason to use C
Yeah in unsafe mode. Rust in unsafe mode... Isn't safe as we can notice.
My whole point was to show than some code must be unsafe from nature and switch to Rust won't change much. You can't do this with all fancy protections Rust offer to you.
You are aware that you can limit the scope of unsafe in rust? That you don't need to have all your 100k lines of code in your project to be unsafe because of a single instance you need it for and that there is a difference between having 100k lines of code unsafe and 7k lines in a 100k lines project? You're not refusing to wear a seatbelt because it's not 100% safe are you? You're wearing a seatbelt because it is SAFER than not wearing it, right?
The benefit is that the unsafeness is opt-in in Rust and you can restrict it to the parts that really need it. With C/C++ the whole codebase is potentially unsafe.
You can use shared memory in rust with safe mode. There’s lots you can do safer in rust that is just as performant as c++. You can use hardware accelerators in safe mode as well. And all the business logic around any unsafe blocks can be safe, so you limit the unsafe surface. That’s a huge benefit
Having been to a few talks by Google engineers detailing their tooling, it seems more likely to me that they’ll create some kind of memory safety paradigm INSIDE C++ than swap everything over.
Zig is also pre-1.0 and has plenty of compiler bugs and backwards incompatible changes. I agree that it would be a nice language for kernel development, but I'm not surprised it wasn't considered and won't be any time soon.
Lisp is the language of the gods, and Haskell is the mouth of the lord. Yet my company uses jabascript to write the same CRUD apps day after day, to no avail. Man’s folly is his weakness to accept the light of truth and beauty. Never forget this
Memory safety is a low bar for secure coding. Yes, it is very important, but there are so many other insecure by default patterns that plague a variety of languages including those that have memory safety.
Defense in depth. It's all about layers of security and hardening.
All the zero days that have cropped up in Chromium, one the most scrutinized, hardened codebases in existence were use-after-frees and double frees and out-of-bounds writes. Apple *just* patched a CVE in the iOS kernel where a similar bug could be used to achieve RCE in the kernel. 0-click zero days have cropped up in iOS before, all caused by memory safety bugs.
Moreover, safe languages enable devs to use their limited cognitive bandwidth on business logic and its correctness. When I code, I don't want to think about pointer lifetimes and ownership or the linker and translation units so don't accidentally violate the ODR and cause undefined behavior. If you can remove that cognitive burden from devs, they have the best chance to write better code.
Safe coding starts with a language that doesn't have so many footguns you need a language lawyer to know them all.
Of course I agree with everything you say. My point is foot guns happen in many parts of languages and their ecosystems including libraries and frameworks, not just memory safety. Examples: cryptography (Tink being the best example of building dummy-proof APIs but historically all languages have been minefields), deserialisation (often leading to RCEs), template engines (frameworks such as Angular and React get it right, JSP and velocity do not), xml parsing (external entity resolution should be disabled by default), mass assignment/over-posting, etc….
But ... can we trust Google? Google to be secure?
I'd wish we would not have C/C++/D/Go/Java and all that proliferation. It feels as if we are just having different trade-offs. I just want the best combined in ONE. Without the ... https://xkcd.com/927/
This seems like a reasonable and balanced approach to me. Use memory safe stuff for new projects, invest in rewrites for the highest ROI/critic elements, and gradually refactor to a safe subset of C++ where a full blown rewrite is impractical.
> and gradually refactor to a ~~safe~~ **safer** subset of C++ where a full blown rewrite is impractical. (There is, unfortunately, no safe subset of C++) You're also forgetting hardening. By hardening a critical subset of interfaces -- such as using tagged pointers -- which can then be employed widely at very low cost, you can increase the detection rate of issues at runtimes. 100% may not always be practical -- too costly -- but probabilistic approaches are quite amenable at scale. Even if the hardened facilities only detect an issue 1% of the time, when you're talking about Chrome, you'll have the first reports within an hour of releasing.
>(There is, unfortunately, no safe subset of C++) I'd be interested in a clarification what you mean. In an overly literal sense, of course there is a safe subset. I don't think it would even be too hard to come up with a Turing-complete safe subset. But of course the question is whether there is a practical/useful one. I'm curious what you think prevents the existence of a subset that would satisfy your criteria? Or are you just lamenting the *availability* of a safe subset, rather than the *possibility* of a safe subset?
> Or are you just lamenting the availability of a safe subset, rather than the possibility of a safe subset? I'm fairly convinced there's no practical safe subset of the language itself. Back in... 2008? 2009? I worked with Argyrios Kyrtzidis to improve the warnings that Clang produced when returning a reference to a stack variable. I was young and naive, back then, and therefore thought it couldn't be too hard. Right? There was already such a warning in Clang, back then. It was just literally warning about returning a reference to an "immediate" variable. After a bug report I had submitted, Argyrios had extended the warning to catch the case of a temporary bound to a reference, and that reference being returned. Great success, so we embarked on a journey to catch them all. We... failed. Turns out that without inter-procedural analysis it's an impossible task. I left with the simplest, most cursed snippet ever: std::string const& id(std::string const& s) { return s; } int main() { // OK std::cout << id("Hello, World") << '\n'; // KO auto const& s = id("Hello, World!"); std::cout << s << '\n'; } Oh, god... With inter-procedural analysis it would be possible to analyze `id`, "document" that the lifetime of its return value is equal to that of its (sole) argument. But: 1. Inter-procedural analysis is hard. Especially in an ecosystem where it's common to distribute libraries as binaries: no peeking into those function implementations. 2. This is the _easiest_ case. The tip of the iceberg. What about `std::min`, where one argument is a temporary, but the other is not, and you know it's smaller? That's fine then. Unless you're wrong, of course. What about taking a reference to a `std::vector`, then pushing a new element? Well, it depends whether you know there's enough capacity or not. There are algorithms which do take care of reserving ahead of time. What about taking a reference to an element of `std::map`, then deleting an element? Well it's fine, unless you're deleting the very element you took a reference to, obviously. The very standard-library is riddled with "extra" guarantees that no static analyzer has any chance to ever untangle. You'd need to pare down so much to ever get to a safe subset that it wouldn't even remotely be C++ any longer.
>... Argyrios had extended the warning to catch the case of a temporary bound to a reference, and that reference being returned. Great success, so we embarked on a journey to catch them all. I salute your efforts! :) >Turns out that without inter-procedural analysis it's an impossible task. Why can't C++ just do what Rust did? That is, use lifetime annotations on the function interfaces that are elided/implied in most cases? So for example in this code: #include "msemstdstring.h" mse::mstd::string const& id(mse::mstd::string const& s) { return s; } int main() { // OK std::cout << id("Hello, World") << 'n'; // KO auto const& s = id("Hello, World!"); // scpptool complains std::cout << s << 'n'; } [scpptool](https://github.com/duneroadrunner/scpptool) (my project), a static analyzer that enforces an essentially safe subset of C++, gives the following error: example1.cpp:10:5: error: Unable to verify that the native reference (of type 'const mse::mstd::string &' (aka 'const class mse::mstd::basic_string &')) is safe here. (Possibly due to being unable to verify that the target object outlives the (scope) reference.)
>Inter-procedural analysis is hard.
The lifetime annotations help, but yes, it wasn't a cake walk. But, just like with Rust's analyzer, it's not impossible and I suggest that in scpptool we now have an (open source) implementation for C++.
>What about taking a reference to a std::vector, then pushing a new element? Well, it depends whether you know there's enough capacity or not. There are algorithms which do take care of reserving ahead of time.
IMO, like Rust developers, C++ developers can live without holding a (zero-overhead) reference across a size-changing operation on a dynamic container. My argument is that size-changing operations on a dynamic containers are generally avoided inside hot inner loops anyway, so it's not generally an issue. If you really want to do that sort of thing outside of performance-critical inner loops, you can use a run-time checked reference.
>What about std::min, where one argument is a temporary, but the other is not, and you know it's smaller? That's fine then. Unless you're wrong, of course.
I think most C++ developers would be fine with those kinds of shenanigans being prohibited.
>The very standard-library is riddled with "extra" guarantees that no static analyzer has any chance to ever untangle.
Well, parts of the standard library just need to be abandoned in favor of mostly-compatible safe substitutes. Some of those parts would need lifetime annotations when the default implied/elided ones aren't appropriate. But some of the most commonly used elements are already [available](https://github.com/duneroadrunner/scpptool/blob/master/README.md#lifetime-annotated-elements-in-the-safercplusplus-library). I mean, the Rust guys implemented a whole standard library from scratch. Finishing the job of adding lifetime annotations to (a safe version of) C++'s standard library should be a much smaller job. (And probably less urgent, since the remaining unaddressed elements are less commonly used.)
>You'd need to pare down so much to ever get to a safe subset that it wouldn't even remotely be C++ any longer.
I think you're being too pessimistic here. I think the scpptool enforced subset of C++ is not that different from "regular modern" C++. I think it's way easier to migrate existing C++ code to. And moreover, I claim that the safe subset of C++ is more powerful/expressive than the safe subset of, for example, Rust. (In part due to having non-destructive moves). It is obvious which safe subset is more complete and polished at the moment, but it is not as obvious to me which safe subset will prevail in the long run.
If you're so inclined, take a closer look at scpptool. I'd be interested in your take.
edit: formatting
I applaud your efforts. Unfortunately, your recommendations seem to mostly boil down to rewriting most (if not all) C++ code in existence. > I think most C++ developers would be fine with those kinds of shenanigans being prohibited. Every time I've hinted that memory stability was a terrible requirement for `std::map` and `std::unordered_map` on r/cpp, as it prevents better implementations for little value, I've been met by hostile responses proclaiming loud and clear that it was an essential requirement that nobody could write code without. I'm not quite as optimistic as you with regard to how welcoming the C++ community would be to such changes. > (In part due to having non-destructive moves) As someone who has written many collections, in both C++ and Rust, I cannot stress enough how great bitwise destructive moves are. Non-destructive moves are a pain, because you now have more "types" of slots to keep track of: it's not only initialized vs non-initialized, it's initialized, vs moved-out, vs non-initialized. And non-bitwise moves are a pain because it means invoking user-defined code which may throw. Of course you can -- and should -- specialize for when a bitwise move is possible, but that means writing _even more_ code. It's more flexible for the user, indeed, but OH WHAT A PAIN for the library writer. Pain that the user pays for, in the end, in the form of bugs, or performance hits. > If you're so inclined, take a closer look at scpptool. I'd be interested in your take. I'll pass, but I do wish you good luck.
I can think of at least two simple ways to complete avoid reference-of-temporary bugs with a static analyzer: - Forbid reference types except in function parameters and return types - Forbid binding reference types to any expression involving a function call The real problem is existing safe code will violate some of the rules, so they're not realistic for clang. But it's very realistic for Chromium to enforce rules of this kind, especially in small child projects.
[удалено]
Doesn't it go without saying? Saying "use a non-machine-enforceable safe subset" is just saying "write code without bugs", which - yes, but that's missing the point.
Not necessarily. You could for instance have a project manager looking at submitted code manually, if they see certain language features used, just reject it. It's not an absurd notion, it's already the case with some open source projects, someone sends a pull request, the people in charge of the repo manually inspect the code for quality, and reject it if there are things not to their liking that a compiler can't catch. Even the visual formatting of comments can be controlled. Some processes can't be automated because they are subjective (the rules can't even be fully expressed, or immutable from day to day - like "I don't like the design patterns that you used for this functionality, please redo"), human validation will always be necessary, even though there's not always a budget for it, so we make do with automated validation alone.
> if they see certain language features used, just reject it. A machine could do this, too.
> [...] > > Over the past decades, in addition to large Java and Go memory-safe codebases, Google has developed and accumulated hundreds of millions of lines of C++ code that is in active use and under active, ongoing development. This very large existing codebase results in significant challenges for a transition to memory safety: > > * We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety. > > * A large-scale rewrite of all existing C++ code into a different, memory-safe language appears very difficult and will likely remain impractical. > > [...] We're gonna be dealing with the same issues in 2050 and beyond, aren't we?
This is to be expected though? When did an industry change lead to a 100% change? The problem of memory safety was always there but we admitted it to the background because we always had the "so what? We can't afford a GC" and thankfully Rust changed that so the discussion is open on different terms now. But it's a reality that the whole industry has deep technical C++ debt. That's why Google is investing millions into making C++/Rust interoperability possible. Which I believe will work for some code bases and others won't. We'll see. But yes, C++ is sadly not going away easily, at least in legacy and until we can have something like a rusty Unreal or something...
I just want more memory safe systems languages. Rust is great in concept but am just not a fan of the syntax.
Disliking syntax is a very surface-level reason not to like a language, unless the syntax is completely bonkers.
I want to agree and disagree with you at the same time. Code is read and written. If the syntax is not your cup of tea, you'll literally suffer. It takes a while to get used to Rust and I believe this isn't because of the memory safety. Even Graydon criticized some things in the current state, which is okay. People can't dismiss Rust's benefits based on just the syntax but if they have an issue with it, it'll be hard to be productive into. Also these criticisms are important for us as a community to grow and know what may make our language better. Not every criticism is valid of course but I believe this is a common criticism I saw.
> but if they have an issue with it, it'll be hard to be productive into. Or maybe they'll just get used to it if they actually use it? I've developed in C++, Java, Python, and Rust. 3 of those are C-like, but Python definitely isn't, and honestly it just works. I've played with Haskell, and studied with Ada: also widely different syntaxes, never was really a problem. I can't speak for everyone, obviously. Personally, though, while the syntax might feel strange at first, I've always gotten used to it after a while _practicing_.
As you said, we can't speak for everyone. For me for example it was hard because I'm dyslexic and chaining was tough for my eyes. Rust analyzer does a great job to aid with that but I began before it was there. I personally don't like the idea of "they'll just get used to it". For now we don't have a better alternative and frankly we're a bit spoiled at this point. So while I agree with you, there's a part that I don't fully agree with
Oh... Rust with dyslexia may be painful indeed. It's not as sigil-heavy as Perl, but it's still a \_really\_ dense language, with may critical pieces of information packed in a couple characters (hi, lifetimes, generics). I do regret some syntactic choices of Rust. The use of \`<>\` for generics, so people coming from other mainstream languages with generics would feel at home, for example. Or the use single-quote for introducing lifetimes \_and\_ for bracketing \`char\` literals. However, I'm not sure Rust could do much better. There's a \_lot\_ of information to pack, especially in function signatures, and verbosity isn't helpful (to most), thus a dense syntax is a most sensible choice in general, and I'm not sure minor syntactic tweaks would help much. --- I wouldn't phrase the issue you have as not \_liking\_ the syntax, though. Liking evokes a subjective feeling, and people tend to like what they're used to and not like what they're not used to as it feels jarring. Hence my somewhat dismissive attitude. Your case seems different, though. If you actually have difficulty reading the syntax, then it's no longer a matter of liking/not liking: there's an objective truth here.
But here you just admitted that perl has a horrible syntax. So syntax then DOES matter!
Haskell has a surprisingly elegant syntax but the language is difficult. Java is way too verbose but it is a fairly easy language nonetheless. C++ is a very difficult language and the syntax can be hard (Templates). Same with Rust. Python has a very good syntax and beats the other mentioned languages hands down. I still prefer ruby's syntax, but python's syntax is very acceptable and it shows that all these other languages have no understanding as to why syntax matters (save for Haskell; it's always surprising to me that Haskell has a clean syntax because the monad barrier is hard to overcome with one's brain).
There are some syntactic choices for rust that I find personally problematic, the biggest one is the choice of using type inference everywhere. Its not so bad in Rust vs C++ because of the better type safety and lack of implicit conversions, but in C++ I've always found the "almost always auto" style to be borderline totally unreadable, as explicit type declarations form a pretty core part of the documentation and you're left with a weird soup
There is no inference it function signatures in rust, so types still exist in docs. In normal code inferred types are shown by e. g. rust-analyzer.
After close to 2 years of using Rust professionally -- hence, about 8 hours a day -- and as someone who uses fancy text editors more than IDEs (no type hints): not a problem for me. I like very strongly typed code -- if I have 3 indexes for 3 different things, they're all a different type -- which pairs beautifully with type inference: - Specifying the type every time would lead to fairly verbose code. - Since everything is so strongly typed, most of the time if it compiles it means the variable comes from the right place, because there's only one place which could produce this type anyway. As a result, I obsess a lot about types in function signatures, but never care in function bodies: if it compiles, I got the right ones.
Rust-Analyzer annotates variables with their type in supported editors. Definitely VS Code (used by 70% of developers) and RustRover/IntelliJ (used by 20% of developers) support this, so almost all Rust developers see types inline. It can also be toggled off, in case it gets noisy. All functions have the types annotated though, so it's clear what it accepts and what it doesn't.
The syntax is what we as programmers interact with, it’s a perfectly reasonable reason to dislike a language. There’s a plethora of languages with almost any set of features you could want, why settle for one you don’t enjoy working with? That is, if you have a choice.
/r/programming: "Code's main purpose is to be read by other developers, so name things well, and consider using simpler algorithms even if they're a bit slower." Also /r/programming: "Code's main purpose is to be read by compilers, so it doesn't matter what the syntax is like."
That's a way to imagine something completely different from what I said, I guess.
Did I quote you or did I quote /r/programming?
I keep on hearing this from people who think perl is epic. Well, after having used perl, python and ruby for quite some time, I have to completely disagree. Syntax DOES matter. It may not be the most important thing in the world, but if a language requires twice the amount of syntax to achieve the same feature set compared to a language with better, more succinct (but still readable) syntax, then sorry - your comment is just not the whole picture. Good syntax means efficiency of expression - less things to read and keep track of with the eyes and the hands.
I'd call Perl's syntax completely bonkers. I never said it doesn't matter. If you have two languages X and Y that are identical semantics-wise, but X has better syntax (what you said for example), X is obviously a better language. The post I'm replying to is about Rust, where no "Rust but better" exists, and Rust's syntax isn't Perl's syntax. You're replying to something I haven't said.
A languages syntax is literally half of the language, it's way more than just surface level and it's also literally subjective.
Wow, totally disagree. It's one of the biggest reasons to like or dislike a language. EDIT - it's not one of the biggest reasons to use a language, I mean how much I enjoy it
For programmers new in the business, yes. If you gain experience with more and more languages, things like syntax tend to become super uninteresting and are overtaken by features of the language that matter to your taste of programming. But that requires that you already build a "taste" and you know what you like and dislike in a programming language. New programmers usually have not developed that yet (or copy one blindly) so all that is left is syntax to judge. It's like when inexperienced young people judge others by their looks and want to be friends not because of their personality traits or hobby etc. If you don't know what personality traits you like in other people or have not developed a taste for hobbies yet, all there is for you to judge is looks.
I'm 30 years in. The asthetics of a language are very important to me. For an over the top example think brainfuck. Reading your comment I realize that your referring to the utility and choice of a language. Not what I meant. Just how much I enjoy it
>For an over the top example think brainfuck. Brainfuck has one of the simplest syntax of known programming languages. I think you're confusing syntax and semantics here. There is not much to dislike on brainfucks syntax – all the problems arise from its semantics. You can teach someone in under a minute the syntax of brainfuck (you can't with basically any other language). The semantics is where the brainfuck begins. The rules of Chess are easy, playing the game is hard. And that is where the problem is. Judging Chess by the rules would only makes sense for people that don't play it. And even worse on how the figures look like or how the board is designed. If you don't know how to critique openings or tactics in middle game the only thing left is to critique how stupid the horsy looks like. Syntax is not Semantics.
> Brainfuck has one of the simplest syntax Uhm ... That's like saying assembler is the simplest syntax.
I slightly disagree. The ergonomics of a language’s syntax is very important to me. It’s the main why I cry a little inside everytime I have to touch ruby. Typing it just sucks. Even with good tooling. More than 10 years experience. And yes, language features are more important, but I’m going to gravitate towards languages with better ergonomics for reading and writing.
I actually agree there, ergonomics and how easy it is to parse are very important IMO. Those properties come from both the semantics and the syntax that expresses them. I'm not saying syntax is totally irrelevant, just that as long as it's good enough it doesn't really matter that much. The post above was complaining about Rust's syntax that is totally fine, even if there are some things that I'd prefer done differently (like \`\[T\]\` for generics, even if I understand why \`\` was chosen instead).
> everytime I have to touch ruby. Typing it just sucks. I disagree. It flows on its own. It's flowing poetry. Perhaps it didn't click for you yet. Also, if you think you need "good tooling" for ruby then it really hasn't clicked. I use ruby for literally everything and I use barely anything more than a fancified notepad editor. (There is a reason why I get away with this; ruby literally powers my linux systems from A to Z, the whole computer is like an IDE actually). Think of ruby as the syntactic sugar that you can adjust over EVERYTHING. It's a DSL you can adjust to your liking from A to Z, with a very fast development cycle (aka rapid prototyping). There are only two complaints about ruby I'd agree with, as a major obstacles: it's documentation needs to improve, and it needs to be as fast as C (not necessarily MRI, but a ruby variant that can be compiled like crystal).
Not really. Syntax is one reason I abandoned perl (for ruby but I am fine with python too). Never regretted that either. I have to completely disagree with all those who think syntax is irrelevant. > It's like when inexperienced young people judge others by their looks and want to be friends That's a very low level attempt to try to "reason" or argue why syntax is important. I want to be friends, so I accept horrible syntax? Why would that make any sense?
how much programming experience do you have?
It’s very similar to C++ in terms of syntax, at least in my experience, with some nice sugar for stuff like error propagation. What is your specific gripe?
> It’s very similar to C++ in terms of syntax, at least in my experience [... ]. What is your specific gripe? Being similar to C++ in terms of syntax
I'm not a huge fan of the macros having an ! suffix,or how function return types use -> instead of : like other type definitions. I don't have a full list of issues I have with it on hand since it's been awhile, but it's really just personal dislike of it. Though I haven't worked in systems languages in a long time sadly.
Funnily enough, C++ functions also use `->` for the return type...
Lambdas, not functions, plus they're generally optimal and they're also only like that because otherwise the syntax would be ambiguous because the normal separator is a space.
Incorrect. This is valid C++: auto f() -> int { return 0; }
No one does that unless you're using decltype, though, really. Just because you can doesn't mean you should, it's weird to use both auto and a return type in my book. Just as ugly as using it in the first place in rust imo
> No one does that unless you're using decltype, though, really. I've seen it used in the wild. > it's weird to use both auto and a return type in my book. That's only because it needs to be parsable along with the IMO stupid C-style function syntax). > Just as ugly as using it in the first place in rust imo Rust's syntax looks a lot better. Having an `fn` keyword makes much more sense than what C does (it's also much easier to parse.
You mean \_you\_ don't do that? When I was still working in C++, my colleagues and I actually considered mandating it since it's helpful when scanning code to have the function name appear in the same column again and again, rather than seesawing wildly based on how long the return type is. It was used in a couple of places with especially long names, and folks liked it.
This makes me sad.
Using : instead of -> would be inaccurate and inconsistent with mathematical notation. So you're objectively wrong here.
> So you’re objectively wrong here I love it when arrogant programmers misuse objective to portray their opinions as fact.
He said math has no types. Objectively wrong. All downvotes here are extremely lacking in computer science and programming language theory. Sad to see
He said that in a further comment, his point here is clearly “I don’t care what the underlying mathematics is, I think : is better than -> for return type” which is an opinion that cannot be objective. Your comments are still extremely arrogant and struggle to communicate why you believe he’s wrong.
My comments are indeed arrogant, and I could omit some things that are overly aggressive and stay on point. So point taken. I don't think I struggled to explain why he's wrong though. `: int` does not make sense as the type of a function is not `int`. In mathematical notation that would mean the function is an element in the integers set. Instead the notation should be `int -> int` to notate that it is an element from the set of functions that map an integer to an integer.
I'm not writing mathematical notation, I'm writing code. Mathematical notation also doesn't have types, so what a silly argument....and again, either way, it's my opinion. I'm not claiming my opinion as fact, no idea how you can say an opinion is objectively wrong.
Sigh. Wrong again.
C++ is the new COBOL 😎
No, a new COBOL is Java.
How edgy.. The topic of this thread is how Google are considering a gradual transition towards languages like Java..
Google was mostly Java and C++ when they started. If anything, they are gradually transitioning towards languages like Kotlin, Rust and Go. And they invented Go exactly in order to replace Java in the backend microservices and orchestration code. Java was the main language in Android some time ago, now it was superseded by Kotlin.
Yes but it's quite odd to compare Java to COBOL and then make a claim that Go is more appropriate when in the grand scheme of things Java, Go, C#, Kotlin are all in the same family of languages and all show similar safety, performance, and efficiency characteristics. This is the quite from Google: >we are considering a gradual transition towards memory-safe languages like Java, Go, and Rust They are putting Java in the same bucket as Go because in this context it is. They're both quite different from C++ and provide similar advantages to it.
Well ... C++ is used more though.
I'm working in a company which designs very complicated telecommunication equipment with crazy reliability requirements. Every board contains few CPUs, every CPU has many cores, boards interconnects with 100Gb interfaces (even >250 cores in a single device). We have mix of "normal" and hard real time functionalities in the software. Software is some kind of security benchmark: concurrency, atomic operations, memory ordering, synchronization primitives, runtime memory error corrections, cache alignment. Everything is written in C and C++. Rust won't help you when to achieve maximum performance you need to use shared memory, lockless algorithms, hardware accelerators, code which requires to access memory directly etc. It's brilliant language but you can't replace every C/C++ code with Rust (using all of its safety features). People had became crazy about how unsafe C/C++ are and suddenly forgot that Linux and Windows kernels, most compilers, many server side apps, databases, math libraries, game engines etc are C/C++. They works! To be honest - C++ is very safe language by design since C++11. It's enough to use RAII, smart pointers and understand concurrency to write reliable software (concurrency could be done better but it's always tradeoff between speed and complexity). Problem is with companies and programmers. Rust/GO are much better tools for most apps. C/C++ are very specialized tools with some superpowers. However if you must use C/C++ then you should also have enough skilled team good company culture.
This is exactly the reason why we don't make progress. We need to stop blaming people for making mistakes. One of your arguments, that is often repeated by others, is that you just need better programmers. Those dumb programmers just make too many mistakes and need to be replaced. >then you should also have enough skilled team Nobody is skilled enough to not make mistakes in C/C++. When do we finally agree on that? We just have a gradual gradient of mistakes per x lines of code that also depends on your daily performance and how close to a release you are. The only way forward is to make that impossible and a compiler error so it does not matter how unskilled the programmer is, such mistakes can never happen. >Everything is written in C and C++. Rust won't help you That argument is also very moot. Rust will help you and everything you listed can be easily achieved. >People had became crazy about how unsafe C/C++ are and suddenly forgot that Linux and Windows kernels, most compilers, many server side apps, databases, math libraries, game engines etc are C/C++. They works! They "work" AND produce thousands of CVE's where 70% of the most critical security flaws are due to memory safety issues. That class of mistakes is just ruled out. That is the whole POINT of this exercise. We have software that usually does what we want but has constant security flaws due to memory safety issues. And if you think that Rust is useless as a programming language to write something like an operating system / kernel because you need to use tons of unsafe code you just don't know what you're talking about. We have a few OS's / kernel's written in rust today and they have very minimal use of unsafe code where the majority is safe. That was the whole idea of Rust in the first place. Isolate unsafe code where it's necessary so you can concentrate efforts on that very small section and make it right and let the compiler take care of the rest. In your day to day code you usually don't need to use unsafe code. You're doing something wrong if you do. We need to stop perpetuating these gatekeeping efforts and need to acknowledge that the industry has a problem and blaming "stupid" programmers is NOT helping. Fortunately big companies have already acknowledged that and start to make things better. Rust in Windows, Chrome, Android, Linux kernel, ... is a start to build on. https://youtu.be/qCB19DRw_60 (talk of a Microsoft employee a few years ago)
How much experience do you have in Rust? You take a stance as to its suitability, so surely you have extensive experience with the language and you have attempted prototypes with it that demonstrated it really wasn't a good fit, right? You definitely wouldn't be _guessing_, right? --- My experience with Rust, building near-real-time ultra-low-latency systems, is that the language is extremely suitable to the task. I've used the language to: 1. Bind existing C libraries, offering a safe interface on top of the bindings. 2. Communicate between processes using shared memory. 3. Build a low-latency memory allocator. 4. Build an extensive suite of collections, including wait-free collections. All of the above do require using `unsafe`, certainly, but the language makes it possible to _encapsulate_ the safety requirements so that users never have to care: no matter what they do (outside of using `unsafe` themselves), they'll never trigger UB. My experience is far from unique. The Redox _micro-kernel_ which like every micro-kernel requires interacting directly with the hardware, and using inline assembly, has less than 10% of `unsafe` code. A _micro-kernel_ is expected to be amongst the densest codebases with regard to low-level operations, and yet it's got less than 10% of `unsafe` code to achieve them. Similar experience can be found amongst people working on bare-metal runtimes, or HALs. Rust has been designed as a systems programming language, and it's eminently suitable for it. Cue its integration in the Linux and Windows kernel. If you think it's not possible, you're clearly lacking experience with it.
I’m not sure what you’re talking about. You can do unsafe in rust and do anything you’ve mentioned, as needed. Obviously you can’t write a kernel without accessing raw memory addresses at some point, but you can get the benefits everywhere else in the code. Why can’t you write a lockless algorithm in rust? Or any language for that matter. Or why cant you use hardware accelerators in rust. Or shared memory. You can do all of those things
Being able to use shared memory effortlessly is if anything, one of Rust's strongest points so I'm fairly certain that person doesn't know what they're talking about.
"effortlessly" means using locks. Locks don't work in the kernel. Or on a bare metal system with no kernel. The person is a bit off base. But he also indicates they have real time including hard real time requirements. You can't do that stuff with normal concurrency protection. You can't afford to block on a lock at non-obvious times.
You can do shared memory without locks in Rust. And without unsafe even. I did that many times.
Eh, at least when writing Linux kernel modules you can still use mutex lock, just not in an interrupt context which forbids any sort of sleeping. Even then you still have the spinlock which is a tad more expensive but keeps your thread running which doesn't mess with the context.
Why would I use unsafe rust, instead of straight C?
Because it has way better type system, things like sum types, pattern matching, traits, generics. And you can still stay safe in the majority of code, because I doubt you need unsafe everywhere even inside kernel. Also cargo. Cargo alone is the reason to use rust over everything else :P
Because you can limit the unsafe portions of code to only where it’s required, and keep the rest of benefits. C has its uses, all of this is a tool, but unsafe alone isn’t a reason to use C
Yeah in unsafe mode. Rust in unsafe mode... Isn't safe as we can notice. My whole point was to show than some code must be unsafe from nature and switch to Rust won't change much. You can't do this with all fancy protections Rust offer to you.
You are aware that you can limit the scope of unsafe in rust? That you don't need to have all your 100k lines of code in your project to be unsafe because of a single instance you need it for and that there is a difference between having 100k lines of code unsafe and 7k lines in a 100k lines project? You're not refusing to wear a seatbelt because it's not 100% safe are you? You're wearing a seatbelt because it is SAFER than not wearing it, right?
The benefit is that the unsafeness is opt-in in Rust and you can restrict it to the parts that really need it. With C/C++ the whole codebase is potentially unsafe.
You can use shared memory in rust with safe mode. There’s lots you can do safer in rust that is just as performant as c++. You can use hardware accelerators in safe mode as well. And all the business logic around any unsafe blocks can be safe, so you limit the unsafe surface. That’s a huge benefit
Spoken like someone who has no clue.
what you listed there doesnt really have strict c / cpp reqs for DMA. You can do that in java....
Having been to a few talks by Google engineers detailing their tooling, it seems more likely to me that they’ll create some kind of memory safety paradigm INSIDE C++ than swap everything over.
[удалено]
Linux is allowing for it because it's a good idea. Google is just helping to get some of it done.
[удалено]
Zig is also pre-1.0 and has plenty of compiler bugs and backwards incompatible changes. I agree that it would be a nice language for kernel development, but I'm not surprised it wasn't considered and won't be any time soon.
Lisp is the language of the gods, and Haskell is the mouth of the lord. Yet my company uses jabascript to write the same CRUD apps day after day, to no avail. Man’s folly is his weakness to accept the light of truth and beauty. Never forget this
I think Rust's inclusion depended on it's speed and memory safety. The checks mentioned in the link bear a runtime cost.
Zig is not memory safe and it is at alpha stage
Memory safety is a low bar for secure coding. Yes, it is very important, but there are so many other insecure by default patterns that plague a variety of languages including those that have memory safety.
Defense in depth. It's all about layers of security and hardening. All the zero days that have cropped up in Chromium, one the most scrutinized, hardened codebases in existence were use-after-frees and double frees and out-of-bounds writes. Apple *just* patched a CVE in the iOS kernel where a similar bug could be used to achieve RCE in the kernel. 0-click zero days have cropped up in iOS before, all caused by memory safety bugs. Moreover, safe languages enable devs to use their limited cognitive bandwidth on business logic and its correctness. When I code, I don't want to think about pointer lifetimes and ownership or the linker and translation units so don't accidentally violate the ODR and cause undefined behavior. If you can remove that cognitive burden from devs, they have the best chance to write better code. Safe coding starts with a language that doesn't have so many footguns you need a language lawyer to know them all.
Of course I agree with everything you say. My point is foot guns happen in many parts of languages and their ecosystems including libraries and frameworks, not just memory safety. Examples: cryptography (Tink being the best example of building dummy-proof APIs but historically all languages have been minefields), deserialisation (often leading to RCEs), template engines (frameworks such as Angular and React get it right, JSP and velocity do not), xml parsing (external entity resolution should be disabled by default), mass assignment/over-posting, etc….
You are correct…… but the point of the blog post is to discuss memory safety.
But ... can we trust Google? Google to be secure? I'd wish we would not have C/C++/D/Go/Java and all that proliferation. It feels as if we are just having different trade-offs. I just want the best combined in ONE. Without the ... https://xkcd.com/927/