rain 🌦️I refuse to believe this was written by actual practitioners in the field
What kind of brain-dead response is "Vulnerabilities are found with any programming language, but it takes time to discover them"? This was actually written by the ISO C++ committee? What???
To be honest, Rust is a pretty clear example of why formal specifications are worth less than they first seem to be! I'm glad people are working on one, but Rust has been successful at its goals without them. The fundamental soundness of its mechanics is pretty clear to anyone who has written production code in it, even though there are edge cases that need nailing down.
Kyle StrandWhat is this talking about??? Python has the with keyword, Java has had AutoCloseable since 2011, and even PHP has refcounting so resources are released if you don't duplicate a reference (and everything's cleaned up at the end of the request in any case). Saying that most newer languages don't have "facilities for handling resource release automatically" is a bald-faced lie! The people who wrote this should have to face professional consequences.
Who wrote this anyway? The document just says "(identified below)" in the beginning but I couldn't find any names. The PDF title appears to be "DOE ISO C++ RFI" so did the entire ISO C++ committee sign on to it? That's exceptionally hard to believe, there are plenty of knowledgeable people on the committee
I don't know where these numbers are coming from. "optimistically" 2000 lines/developer-year?????
I just finished a year at Oxide and in the main repo I've worked on, to which I've dedicated around half of my time, GitHub says my contributions are +82,102/-50,485 lines. The rest of my time was spent in reviews, other repos, doing design work, written documents, presentations, and so on (all things that are part of the job with senior+ engineers).
Of course this varies a lot by role and job requirements, many principal-level engineers are probably going to be busy conducting external meetings and such. But if you're rewriting a 10 million line application I straight up do not believe that the average contribution of a "good" developer will be 0.04% of the codebase/year.
Alex Michael Berry 🐈🐩@rain Writing new code and porting code are really different tasks too. I don't write code very fast, but I can port code really fast.
@almibe Absolutely. There's no way whatsoever that a competent developer would only be able to port 0.04% of a 10MM line code base PER YEAR. Maybe per month.
jubilee@rain
"tested"
"production-quality"
I believe this is trying to say all that code is shit and shift the goalposts, therefore also ignoring the utility of certain programming language designs in increasing test coverage or preventing... "backsliding into bad code"
"tested"
"production-quality"
I believe this is trying to say all that code is shit and shift the goalposts, therefore also ignoring the utility of certain programming language designs in increasing test coverage or preventing... "backsliding into bad code"
Jeremiah Senkpiel@rain I have also sadly contributed well over 2000 lines of code to this world’s tech debt this year
systemd-jaded.timer@rain yeah those are strange numbers, i write 2k lines in a couple of weeks full time?
Federico Mena Quintero@rain That comment seems to assume that a port/rewrite is all-or-nothing? One of the killer features of Rust, for me, was that it allowed leaving a C project halfway-ported and it was always kept working. Porting first the most critical parts for memory safety - parsers - gave us peace of mind to continue porting the rest at leisure.
At least for librsvg, I'd say memory safety was nice and all, but the real benefits came from better tooling (cargo test!), and better data representation.
@federicomena Yep lol, no one in the field would commit to a 5 year rewrite with no incremental goals. yet more evidence that this wasn't written by practitioners
sabik
cliffle@rain FWIW this lifts a lot of language from this other document, which *does* have a byline: H. Hinnant, R. Orr, B. Stroustrup, D. Vandevoorde, M. Wong
I thought I recognized the "we at C++ do not advertise and that's why we're falling behind" crap from somewhere.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2759r1.pdf
@cliffle oh THAT article
@rain Yeah, that article also throws in
"Rust, originally from Mozilla, built on top of C++ became
the poster child of a safe browser language." Missing comma in original.
Rust: it's bad, but also we're going to insert a grammatically-incorrect clause taking some credit for it.
@rain here's a pretty good post that picks that apart the same way I would have, but is already written by someone else.
My Reaction to Dr. Stroustrup's Recent Memory Safety Comments
The NSA recently published a Cybersecurity Information Sheet about the importance of memory safety, where they recommended moving from memory-unsafe programming languages (like C and C++) to memory-safe ones (like Rust). Dr. Bjarne Stroustrup, the original creator of C++, has made some waves with his response. To be honest, I was disappointed. As a current die-hard Rustacean and former die-hard C++ programmer, I have thought (and blogged) quite a bit about the topic of Rust vs C++.
Ed Page@rain they make a passing reference to being the "ISO C++ Directions Group". Very easy to miss.
Biason::Julio::new();@rain Even knowledgeable people can bury their heads in the ground and ignore everything that's going outside their circle.
@rain I am wondering this as well.
mcc@rain ahh, but you see, other languages do scoped resource lifetimes using specifically-delineated blocks, whereas C++ is unique in doing it via *RAII*, which is better because it is wildly ambiguous and has awkward implications for compiler optimizations. *Why* has no other language chosen to use this idiom, you ask? Is it for a reason? Well, you see: Don't ask that question
@mcc haha, tbf Rust also uses RAII, as do other languages inspired by it (e.g. the Move smart contract language)
@rain Alas! Incidentally, this *does* make me worry: in a world without RAII, would the Rust/C++ compiler be free to release resources before the end of a block if it can guarantee that the variable will not be referenced by any code following the current point of execution? Does RAII inhibit this potentially useful optimization?
@mcc RAII definitely affects that, though I suspect LLVM can optimize frees into being in the middle of a block if there's no Drop impl/destructor.
@mcc @rain Temporaries have different drop rules (eg see https://blog.m-ou.se/super-let/), but also, if you need the optimization of dropping something early, you can just add an inner scope.
Rust Temporary Lifetimes and "Super Let"
The lifetime of temporaries in Rust is a complicated but often ignored topic. In simple cases, Rust keeps temporaries around for exactly long enough, such that we don’t have to think about them. However, there are plenty of cases were we might not get exactly what we want, right away. In this post, we (re)discover the rules for the lifetime of temporaries, go over a few use cases for temporary lifetime extension, and explore a new language idea, super let, to give us more control.
@BatmanAoD @rain This assumes your drop order happens to follow a strict hierarchal structure. But I think also you can just terminate a variable's scope early by manually calling std::mem::drop…?
@mcc @rain Doing this as a compiler optimization in C++ wouldn't be safe, since mutex locks are separate from what they protect, so the lock itself generally isn't accessed after it's acquired. In Rust, though, a mutex-protected value is actually accessed *via* its lock, so I can't think of a safety problem if the language had been designed to release values as early as possible. (That's not always an optimization, though.)
Ignas Kiela
Cappy Ishihara 
@rain Live
std::mem::drop reaction: