Rust developers at Google are twice as productive as C++ teams Echoing the past two years of Rust evangelism and C/C++ ennui, Google reports that Rust shines in production, to the point that its developers are twice as productive using the language compared to C++. Speaking at the Rust Nation UK Conference in London this week, Lars Bergstrom, director of engineering at Google, who works …
of an existing package?
Assuming that much of the conversion is using translations of existing functions, algorithms, and methodologies. Which would have been well debugged in the earlier implementation.
I'll still guess that Rust may be slightly easier to develop for new projects given its very good error checking during compilation.
I was thinking the opposite way, the code has been rewritten, and this has cleaned up the code base. Basically, the technical debt has been reduced. The code is again clean, lean, fast and actually maintainable.
That's possible also, but I think and hope that much of the original code has been refactored many time over the past years.
I know one of my more pleasant tasks (really!) is to go back and look at my older code base that is still in use and see if I can make it cleaner, more effective, more error-proof.
Absolutely. The opportunity to rewrite a project from scratch with an already working reference implementation can't do anything but clean and optimize it. Otherwise, what else are you doing?!
I imagine they'd notice a similar improvement in quality if they rewrote C++ software in...C++.
He addresses this, his statement is not just a quick shot off the hip he has put some though and analysis into it. For once it is also compared to rewrites in C++, the speech was quite interesting.
Bergstrom is a Director and the Chair of the board of the Rust Foundation.
It is even gets better, the NSA report references a series of blogs where Google, Microsoft and others just give common knowledge (without any real data) that C/C++ has memory issues. They present no statistics to back up their claims.
Having worked on several C/C++ projects, these memory issues generally stem from type issues - for example, the returned of a function is either an error code or the length of an array. This is the type of error that can impact most languages where someone misinterprets what the function returns and misuses that returned value.
As I see it, Rust advocate at Google references the White House/NSA who, in turn, references Google.
Google reports its own actual experience with the Android code base: the incidence of memory-safety errors did come down.
Eight-five percent of people believe that their Rust code is more likely to be correct than the other code within their system.
Said the group who have chosen to do it.
I'm, not convinced that programmer's views on how good their code is tallies that well with how good it actually is. How many said "gee, my code was crap today but no concerns" and kept gong?
Was thinking along the same lines.
(1) "decreased defect rate over time in those services that have been rewritten in Rust – so increasing correctness"
That's the sort of thing that gives confidence.
(2) "how confident do you feel that your team's Rust code is correct?"
That one is tricky. If you say your code is incorrect, I am likely to believe you. But if you say your code is correct, I am more hesitant. Maybe you know some objective metric like (1) and it's all fine, or maybe there is nothing objective behind your answer. At which point I start to wonder why I even asked the question...
For me switching to Rust the big surprise was not so much confidence in code I'd written but how much less stressful the act of writing code that you feel confident in is. I don't think Google's survey really captures that but it's a sort of consequence of confidence, probably one big factor behind the productivity improvement, and that in turn backs up that the confidence is not misplaced.
As it happens this week after 2 years using Rust I had to return to C++ for a bit. In just 2 days I made one horribly embarrassing integer overflow bug which passed all unit tests - Bjarne Stroustrup might argue the bug was in testing I suppose - of the kind that Rust's compiler would have flagged up immediately and forced me to make the stupidity explicit in the code to easily see, or else fix it.
I've got decades experience writing C++, reviewing other's C++, finding bugs, exploiting vulnerabilities, reversing binaries C++ compilers generate, watching each bug type unfold in full low-level glory in debuggers. And despite all that or maybe because of it I just don't feel confident writing C++ code. It's taken Rust to make me properly realise that, or at least to realise that the constant coding anxiety about subtle bugs (or even just stress about whether you're using enough of the right tooling to make safe your dangerous language) isn't necessary in order to write high-performance software.
"I made one horribly embarrassing integer overflow bug which passed all unit tests"
Did your compiler not warn about narrowing or somesuch?
"of the kind that Rust's compiler would have flagged up immediately"
Which makes me wonder, is Rust really that much better, or is it down to the compiler being able to spot a lot more potential problems and warn about them?
Plus, I guess, a system that will check memory accesses rather than just blindly reading/writing to whatever the pointer is set to (or however long the array is). I don't know why nobody ever added that to C so it could be made to behave better.
Which makes me wonder, is Rust really that much better, or is it down to the compiler being able to spot a lot more potential problems and warn about them?
Isn't it a combination of that though? You design a language with modern computers, and you can build all the safety checks in from the get go that you couldn't when C was designed. Plus, knowing these checks are now possible you can specify the language to include them.
Plus, I guess, a system that will check memory accesses rather than just blindly reading/writing to whatever the pointer is set to (or however long the array is). I don't know why nobody ever added that to C so it could be made to behave better.
Because then it wouldn't be C, it'd be another (similar) language. (and everyone here would be telling us how if you only wrote good 'C' or 'C++' you wouldn't need <your new language>).
C and C++ aren't going away, but they are old now, it's fine that we're designing something new. If you want to write C and C++ that's okay. If you're a skilled developer you'll probably write C and C++ that is memory safe and less error prone. Not every developer is a good developer though, so in those cases, perhaps tooling that helps them out isn't a bad idea.
Modern industrial machinery is much less maimy than the older stuff, but there are still people happily using a scythe, and long may they continue to do so. Both are fine.
Even highly experienced, intelligent and cunning software engineers will have bugs in their code then and now. Valgrind and checkers such as PC Lint are demonstrating this. So do plenty of CVE exploits in Linux, Windows, Apache or VxWorks.
Memory Safety is an additional layer of safety and security. Just like ABS brakes help even the most experienced drivers.
"Because then it wouldn't be C, it'd be another (similar) language."
Call it "Csafe" or something. It can compile C code but will include bounds checking and all that guff to make it a little bit slower but a lot safer. After all, C++ exists and didn't replace C...
"If you're a skilled developer"
Everybody screws up from time to time. Lack of sleep. Lack of caffeine. And for those of us "on the spectrum", co-workers that won't STFU and let us get on with things (especially management and their pointless status reports where they expect a "percentage completed" because they think writing software is like painting a room or something).
"perhaps tooling that helps them out isn't a bad idea"
It's probably a good idea anyway. Far too many CVEs under the bridge to justify playing fast and loose with pointer magic.
"Call it "Csafe" or something. It can compile C code but will include bounds checking and all that guff to make it a little bit slower but a lot safer. After all, C++ exists and didn't replace C..."
Various efforts have been made and even more proposed over the years. (eg. the splint linter has been able to enforce a surprisingly large subset of what Rust can do via annotations for 20 years now and I remember seeing at least one mentioned on LWN years ago) ...the problem is getting actual interest from programmers.
Hell, some of them, like Cyclone, were direct inspirations for Rust.
What really makes Rust special is successfully achieving critical mass.
"Call it "Csafe" or something. It can compile C code but will include bounds checking and all that guff to make it a little bit slower but a lot safer. After all, C++ exists and didn't replace C..."
Most of the time, that would work, but there would be some compatibility differences. For example, if I do go out of bounds, what happens? If I can catch and report on that error, then anything I write that does that isn't compatible with C. Basically all you can do is crash the program on any out of bounds access if you want to be as compatible with C as you can, and even that won't necessarily work on everything. For example, if you have a typical string ending in \0, and I write something else over the \0, is that out of bounds? From the perspective of a string, it is, because it will break all the string functions. From the perspective of an array, it isn't. If you write your language to check for that, then someone will use it in that way and your language will not be compatible with their thing.
So yes, you can do it, but it would end up being a different language. It is hard for a language that is effectively the same as another language to get adopted, whereas building that into a new language that can introduce other changes that people think are useful has a better chance of being adopted.
If you think about it, the damage done by a nicely debuggable core file is much less than undetected memory cancer. Or Undetected Program Subversion By Cybernetic Attacker.
In some applications such as realtime control of cars, airplanes, rockets a software crash might be fatal. But even in those cases, a memory safe language will stop your system inside the V-Shaped development methodology. If you have sufficient test cases, that is. Plus you will use various static test techniques (e.g. PC Lint or SPARK Ada) to find as many bugs as possible early. In some cases, even more static checking is required.
The key point is that memory safety will find the bug when it occurs, instead of silenty soldiering on and then Failing Mysteriously three minutes later.
Everybody screws up from time to time. Lack of sleep. Lack of caffeine. And for those of us "on the spectrum", co-workers that won't STFU and let us get on with things (especially management and their pointless status reports where they expect a "percentage completed" because they think writing software is like painting a room or something).
An upvote and one of these for you, my friend - - - ->
"Plus, I guess, a system that will check memory accesses rather than just blindly reading/writing to whatever the pointer is set to (or however long the array is). I don't know why nobody ever added that to C so it could be made to behave better."
valgrind(https://valgrind.org) does a great job of finding memory errors. I have also used a bounds checker on Windows and purify on sun os.
Some lint tools are also capable to a more limited extent.
Three points about these rumtime memory checkers:
1.) Very valuable tools for finding memory errors during debug and testing time.
2.) Slowing down the program by a factor of 100. Too slow for most productive use cases. Sappeur and Java slow down by a factor of three. (e.g. https://github.com/DiplIngFrankGerlach/SieveOfEratosthenes)
3.) Do not find the memory bugs triggered by an attacker's Specially Crafted Input. Unlike Sappeur, Rust, Java, Go.
Did your compiler not warn about narrowing or somesuch?
It was multiplication of two variables which I then accumulated in a 64-bit int. I knew the 64 bit was always going to be big enough but C++ silently promoting the result caused me to gloss over that the original variables were only 32-bit and the promotion happened after the operation by which time it could already have overflowed. Rust would have forced me to do the coercion explicitly and I'd have realised it needed doing before the mult.
I'm not sure it's the best example because Rust still has dangerous integer overflow behaviour if you're reckless, and it's a bit of controversial issue in the community how much to compromise performance detecting these things and what even to do about them when you do. I'd say almost all Rust's other correctness features are more robust. But it was the example I had. (I did also do a very brief stupid involving keeping a reference into a vector which was being resized - of the kind Rust's borrow checker would have given a firm but exceedingly intelligible 'Nope' to. That was less consequential but illustrates how easy it is to do).
As it happens this week after 2 years using Rust I had to return to C++ for a bit. In just 2 days I made one horribly embarrassing integer overflow bug which passed all unit tests - Bjarne Stroustrup might argue the bug was in testing I suppose - of the kind that Rust's compiler would have flagged up immediately and forced me to make the stupidity explicit in the code to easily see, or else fix it.
Wait...wha'?
All this time, the evangelists (read: zealots) were singing hosannas about Rust's memory safety -- that memory safety is all you ever have to worry about to write correct, secure code, yadda, yadda, yadda. I've never heard once that Rust also compiles away integer overflows. When did that become a feature of the language?
I've never heard once that Rust also compiles away integer overflows
It does an awful lot:
- Forces you to write primitive/literal type conversions explicitly
- Debug builds have runtime integer overflow detection on
- checked_ functions make it trivial to do release build overflow detection if you want the cost
- Overflow behaviour is well defined so if you do want it or want to detect it and plan for it you can
- wrapping_ & saturating_ functions give you control over wrapping behaviour
- Forces you to deal with floating point edge cases
- Bounds check on collections/everything so when your integers do overflow unintentionally it's a logic error and doesn't cause memory unsafety
You need formal verification in order to entirely eliminate integer overflows at compile time (or you use infinite precision data types and trade-off integer overflows for out-of-memory bugs).
My grandmother says not the case, she does not like rust, but she is thinking rust on metal.
This is Rust developers talking about if they like Rust.
It's like asking professional Java developers if they like using Java. Maybe that's a bad analogy as they all go on to then try Scala in some failed project, then Kotlin, etc.
I finally got around to watching the talk itself. The question wasn't "How confident are you that your code is correct?", it's "How confident do you feel that your team's Rust code is correct?"
...that is, it's asking "Having experienced reading and reviewing your teammates' code, do you feel more or less confident that they've done it properly when they write in Rust?"
Still not saying whether they did do it properly, but Rust appears to make reviewers feel better about what they're reading from other people at least.
It really depends on what you're doing in C/C++ vs Rust. Things like linked lists and other structures are harder to do in Rust with patterns like vectors already in place to help you with less cognitive overhead.
Idiomatic Rust can be very different from C/C++. Usually when learning a language I'll rewrite something I'm more familiar with in the new language. Getting a good grasp of the language Dynamics will often have you doing certain parts very differently.
So as someone who has written large systems in C++ for 20 years (including servers, GUI apps, and embedded) and has been using C# for 10 years, Python for 15, Rust for 1, the latter three really are easier to write, read, and maintain (with one exception I'll get to) for one simple reason: C#, Python, and Rust are written with some thought to readability. C++ is performance uber alles, even if it makes the code hideously ugly and the compile errors nigh unreadable (once you add in templating).
C++ isn't perl levels of write only, but it's up there. I can go back to Python code I haven't looked at in two years (I did just last week) and oh hey, I can tell what it's doing and make changes, no problem, because it's readable. I go back to two year old C++ and it's just a slog. Part of this is the hideousness of C++'s .h files, which require you to pre-declare everything external in the .cpp file *in a slightly different syntax*, so you're tediously maintaining two slightly different sets of declarations. Part of this is because C++ is just too damn verbose. Not Java levels, but the fiddly syntax requires you to spend way too long describing *how* to do something and not *what* you're doing, even using STL. And of course there is a ton of room for accidents, because you're so focused on the detail you miss the bigger picture or vice versa and the language certainly isn't helping much. You spend inordinate amounts of time making sure you're not doing something other languages just make sure doesn't happen by default.
Now yes, you can write amazingly beautiful and readable code in perl (I've seen it) and you can write perl in python (ditto), so I'm sure you can write safe code in C++ - I certainly have non-leaky and non-crashy C++ programs (or at least they appear that way), but they took a lot of work. What really matters is what the language encourages and C++ just doesn't encourage readability or writeability - you will always have the problem where you have to look at both the cpp files and h files simultaneously for instance. And that's critical when you have more than one person working on something. And guess what? You who haven't looked at your own code for six months is 'another person'! So I find Python, C#, and Rust far more maintainable than C++. What I've done for 8 years or so is just save C++ for the very very few extremely tight and fast operations (less than .01% of the code), and everything else is C# or Python and calls the C++ when it's needed. This has been a 10x boost in productivity. Well Rust is blurring the line. I can use it for what I used to use C++ for *and* it's expressive and capable enough that I can use it for higher level stuff too. It's not good for GUIs but is just fine in the middle.
Sorry this was so long, but I've actually been in the thick of this. And what was the one exception? Well, python's lack of compile time checks makes it awkward for large systems - I'd much rather have things fail at compile than at runtime. I still love it for small to medium stuff though. tl;dr if it didn't pay so well I would never touch C++ again.
Totally agree with your points. I have written way too much code in B (predecessor to C), C/C++, and Perl (along with many years of various assemblers.)
All of the languages that require a separate set of definitions that are independent of the implementations are a real PITA.
I'm writing mainly Python now because of the very rich ecosystem. When I see most of the libraries/frameworks available in Rust, I'll start my move.
Ditto for me. Traditionally writing in C as the "universal assembler" as mostly i wrote hardware-specific stuff, or low level number crunching, but in recent times python is my choice as its pretty good at many things (with handy libraries in numpy, scipy, and matplotlib) and safe-ish.
As the OP said, the main issue is it is interpreted so you don't always find errors until a code branch takes them, which sucks. And yes, you should have test routines that cover every branch but in the real world that often is lacking.
They could have meant any of three things by that:
1. Rust isn't good for making GUIs because the ecosystem is particularly immature there.
2. Rust isn't good for making GUIs because Rust doesn't do classical inheritance and the big-name widget toolkits tend to be based on that type of OOP, so the bindings aren't as nice-feeling. (See, for example, how gtk-rs does it.)
3. Rust isn't good for making GUIs because existing toolkits have their own conceptions of object lifecycles which need to be adapted in any bindings written.
All three are true to some degree... but then I'd also say that Rust isn't the best for the niche that the Django framework for Python fills, because it's got a gigantic ecosystem of reusable components already written.
Keep an eye on the Iced toolkit. It's what's System76 is using to develop the COSMIC desktop for Linux.
ssokolow had some good thoughts on this, but for me it's really that there is nothing at all for rust that makes a GUI as trivial as Visual C# does.
Right now, rust is a medium to low level focused language. GUIs are an afterthought, as with python.
There are some semi-decent options, like slint and tauri. There's also iced, but I don't really like the elm model, but YMMV - some people like it a lot!
For now I'd rather write a GUI in rust than C++, but I'd much much rather just write a C# GUI and call into rust. I hope this will change soon.
I think I generally agree - my eyes tend to glaze over when looking at C++ code - though that may be partly because different authors tend to use their own personal subsets and you have to read yourself into their mindset. C rather has the opposite problem - the syntax is so terse you can't immediately be sure that what you think you've read is what is actually going on.
While Rust at first sight seems quite readable, I'm not amongst those who would feel confident about being able to gauge its correctness - for one very simple reason: macros.
In order to have that confidence, you need to know that the code you are looking at is the code that will actually execute. It's just about possible in C/C++ which have relatively simple macro languages - you have to do some textual substitution in your head. Rust macros, on the other hand, are code that generates arbitrary other code and can easily - intentionally or otherwise - conceal flaws. And it's not as if we don't have a recent example of macro hacking.
Whereas Metaprogramming may be very flexible, adding layers of obfuscation does not, to my mind, contribute to the production of safe code.
What you say about macros is true: you feed them some input and can't be sure what will happen. Remind me: how again was this different from passing some input to a function?
However Rust crates are distributed as source code. This is good for optimising them to your needs and your processor, rather than some decades old almost 8088 least common denominator. And the source is just one click away for you to study.
And even better, this (admittedly weird command, that requires nightly, gladly installed by rustup) gives you the produced code, so no hidden surprises: RUSTFLAGS=-Zunpretty=expanded cargo +nightly build
Yes, there are different levels of 'do I trust this?' but
1) Rust macros will still not generate code that will crash from memory access errors.
2) Yes there can still be logic errors - as when you call any functions or any libraries.
3) It's still way down the horror scale from C++'s macros and templates.
The big difference is that macros generate the code inline, functions all the same code elsewhere. And macros let you do things more succinctly and clearly than you could do otherwise (as in c/c++). Of course you can abuse it and make your code actually less comprehensible. But still better than C++.
Any new language at Google is more productive. You rewrite problems that were already solved. There are no banned features (yet). There's no hyper-complicated style and consistency guide. The reviewers are your buddies.
Rumor is that Golang was popular at Google because it avoided a lot of bureaucracy, not because it was a good technical fit.
In addition to the "refactoring" comments above, I wonder if this is in part because the same people writing the are also maintaining it. Once the codeset is passed down a few generations we might start to hear it creak - oh the joys of maintaining someone elses code...
I don't want to be too cynical, but over 40-odd years I remember the nice same things being said about every new language and methodology.
Hard to get some new whiz-kid to look at a COBOL-68 program, though.
I'm guessing you could ask some AI engine to examine the whole corpus of a mainframe inventory/billing/HR system and have it spit out at least the basic functions that the system was supposed to provide written in some high-level pseudo code to be turned into Rust, Go, whatever.
Cobol programs perform tax, banking, accounting and other critical stuff. Stuff that affects millions of people.
We do not want a 99,9%( due to AI phantasizing) correct version of these programs. Rather, we want a 100% correct translation using proven, robust compiler technology. The translated programs will look quite cobolish, but all new code can be rust-style, go-style, sappeur-style etc.
COBOL is a particularly difficult language to parse, for historical reasons. There are many dialects. The standard allows major differences in behavior, for such basic situations as nested PERFORMs. Transforming COBOL to another language is very far from trivial; you can see this just by e.g. using OpenText1 Visual COBOL to compile to IL, then view the output with a decompiler such as .NET Reflector. The compiler goes to considerable effort to produce reasonable IL output, but the generated code has to jump through all sorts of hoops to maintain COBOL semantics.
That said, of course using an LLM to do the translation, or even interpretation, is madness. It will go wrong in precisely the worst ways.
1Formerly Micro Focus, soon to be Rocket.
Any new language or framework tends to be like this. And then come the templates, modules, new features, newer features that do the same better but not in case of xyz, etc. And by then it's time for a new language that's elegant and clear. And the whole cycle starts again. That's not to say I don't think Rust in particular has a lot of things going for it.
In Rust, the general answer is "If you don't recognize the syntax, assume it's from Ocaml". Rust is more or less a GC-less ML derivative wrapped in some borrowed C++ syntax to make it friendlier. (Right down to rustc originally having been written in Ocaml.)
In that specific case, 'a is the Ocaml equivalent to <T>, because, abstractly, lifetimes are a special kind of generic type parameter.
How many times have we read this sort of thing. First with C++, then with Java, then C#, and on and on. The people who work with these new languages tend to be people who disliked the "old way" of doing things. People who volunteered at their company to start working with Java back when that was the new hotness fell into two categories. One, people who disliked C++ and wanted ANYTHING that wasn't C++. Two, people who thought that Java was going to be the next trend and they wanted to get Java experience to help them get hired into a new job for more money.
Both classes of Java early adopters had reason to talk it up and hail its successes, and as the company experts in the language were the people responsible for figuring out how C++ vs Java was evaluated, and we all remember those claims of how much faster Java development was and how it was more maintainable, had fewer security holes, less compatibility headaches, etc. Sound familiar?
Give it a few years and something new will come along and the hype will start building as it has with Rust the last few years and we'll see a Reg article claiming that NewLang devs are twice as productive as Rust devs. If developers really were doubling their productivity and slashing bugs every 5-10 years when the next $language paradigm comes along that sure would be nice, but it does not fit reality at all.
I see no evidence of progress on the code quality or security front.
Languages are mostly irrelevant. An implementation detail. The difficulty in writing new software (either a whole program or new functionality) comes before a single line of code is ever written. Gathering requirements, deciding how the various pieces will interface, etc. No language makes that easier, because that's not done in a programming language.
A better language should in theory make it easier to write secure code, but other than removing certain classes of memory related bugs (which are just the tip of the overall iceberg) there has been zero progress. Because, again, that's not a computer language issue but a program design issue.
Even the most experienced developers with the nicest requirements documents, the nicest design documents etc will produce implementation errors then and now. 70% of those errors can be caught by Memory Safe Languages. That means 70% of exploits do not work.
See http://sappeur.di-fg.de/Sappeur_Cyber_Security.pdf
So if one implementation would have 100 exploits this would have "only" 30?
You know what they call a program with 70% less exploits than another? Insecure.
It is quite possible to avoid those memory exploits even with a language like C, if you are smart about limiting the use of stuff like strcpy(), sprintf() etc. that relies solely on null string indicators. I agree that a language that FORCES safety is better for producing secure code from the average programmer, but the average programmer has plenty of ways to screw up and leave giant gaping holes in their wake - often through poor design rather than poor programming which is a lot harder to fix (i.e. requires a rewrite)
My curiosity is if Rust will have the same fate as Java: Being more idiot proof allows companies to use cheaper idiots.
I really like Java as a general purpose language for mid to large projects. Cheap Java coders, on the other hand, are an addictive and fatal poison to companies. C++ is self-limiting, in that bad coders can't write much of it before it quits working.
There exist many industrial-strength, high quality Java based systems. Heavily used in finance, accounting, logistics, airlines and other commercial data processing.#
Also, lots of C and C++ developers use the Java-based Eclipse IDE. It's almost the standard in C++ development on Linux. Not perfect, but the others are worse.
Well, if he's pushing Rust and denigrating C++, it's more of a surprise that 100% of the Google engineers didn't agree with him, seeing as the way to advance your career there will be, like everywhere else, to agree with the boss.
A disciplined programmer, with thought and experience, can use a sensible subset of C++ to write very safe and readable code, that doesn't throw pointers around with abandon, and manages them carefully when they're used by storing them in containers.
An inexperienced Rust programmer, can and will write plenty of unsafe code. And the problem with the survey is that it only concerns translating finished applications from one language to another. A more useful comparison would be time taken when starting from scratch. I don't knock Rust : if it works for you and your application that's great, but as someone with nearly 30 years C++ experience, the fact that you can write unsafe code doesn't mean you invariably will, and I find it a very productive language, with superb performance and reusability.
Billions of software developers' hours are lost due to not well-thought base platform development. Some languages start as an experiment, suddenly pick up, and go mainstream.
HTMX, for example, is now proving the whole range of JavaScript frameworks was likely huge waste of time. While object-oriented programming was probably one of the biggest mistakes of all.
Another problem is that top programmers could also be the brightest, thus assuming everyone else is as capable to understand their language/framework in every detail, and are as able to keep all the complexities in memory while juggling the code parts.
Newer languages have proven simplicity matters. Especially for security.
While object-oriented programming was probably one of the biggest mistakes of all.
Only if you don't understand the difference between contracts and implementation - which usually means you don't have a clear model of what you're building - you did say JavaScript at the same time - so I rest my case.
Given that most human invention over the millennia has consisted of combining multiple objects together to make a new easier to use and/or more powerful object it seems strange that people criticise OOP. My experience is that nearly everything can be described as a collection of interacting simpler things.
Or maybe I'm strange.
Clearly some people do struggle with the concept of contracts and implementations and with inheritance but I've always found it easy and obvious. It suits the way I think.
* This is what things like me can do.
* You tell me what you expect me to be able to do and I will do it.
* I'm like one of those/these but I can also do these things.
I think where OOP seems to fall apart is that a lot of developers don't like the constraints it imposes. They want to be able reach inside an object and get information from it. They want to look at it and understand how it does what it does instead of just using it. I think it's a similar instinct that leads to excessively long functions and lower productivity. A lot of software developers just seem to have an aversion to black boxes. The idea of having a function just do the one thing its name says it will bothers them. Such programmers prefer to have all the code in one place.
It almost amazes me sometimes how some of them can even use a computer without having first opened case then reverse engineered the PCBs and chips therein.
I'm not saying 'trust my code because I'm a programmer' but if I claim to implement a contract then at least wait until something has gone wrong and can be indisputably traced to my implementation before you start digging. And FFS if the implementation doesn't expose internal data then don't go ferreting around for it. Oh and contracts should be almost sacrosanct. If one doesn't provide what you need then consider the possibility that you might be going about things the wrong way. Contracts are what I often use to 'encode' (probably the wrong word - maybe 'embody' is better) the application logic. I design using contracts. Follow the contracts and you won't go far wrong.
"And FFS if the implementation doesn't expose internal data then don't go ferreting around for it."
Thats exactly it. So many people I work with just totally fail to grok objects and want to add accessors for absolutely everything. It'd be so much easier if I could get hold of... No, its none of your business, learn to use the interface or even *extend* the interface if absolutely necessary, but stay on your own side of the fence because tomorrow I might change the implementation.
The thing I find most satisfying is when we end up with objects that mimic the real things in our problem domain. The article talks about confidence in the correctness of code, well if the objects appear to behave the way the real world does then that gives me confidence that the application will be correct. That's not a language specific thing.
I haven't tried Rust. I probably ought to. I've done C++ for over 30 years and I absolutely love it. I rarely produce code that has memory errors. That's down to objects again. Writing your business logic in terms of domain objects tends to lead to very predictable life-times so its much less likely that you trip over dangling references.
I think the biggest problem with OOP is that programs are often not well designed from the outset.
The object model of the program is usually not a perfect match for the reality of the business process. Particularly if it has been designed in parts by several different semi-competent people who all follow different religions about how systems should be designed. It barely works when first delivered. And then the requirements change and you find yourself stuck because some data you need is out of scope and the design is totally inflexible and it's a massive job to re-architect everything correctly so you're forced into some kind of ugly bodge just to make it work. And then more requirements change and the whole cycle repeats time and time again until you are left with a unmaintainable mess that nobody fully understands.
It's all very well saying, "my object is a component and this is what it does, and you're not allowed to peek inside and if you don't like it, use a different object instead", but the reality of maintaining a large complex piece of software over many years doesn't work like that except in the case of very simple objects. And if you think otherwise then you clearly haven't spent enough time working on other people's bad code.
OOP is great if you can take some fixed requirements and then come up with a nice clean design and then code it, test it, deliver it, and walk away. But it can be an absolute nightmare to maintain as legacy code. The same can be said, to some extent, of traditional procedural programming, but OOP, when done badly (as it usually is), adds a whole new dimension of unnecessary complexity.
It almost amazes me sometimes how some of them can even use a computer without having first opened case then reverse engineered the PCBs and chips therein.
I can tell you there are plenty of folks who presume to be able to program a computer without even knowing what a register is.
Prolly a good thing, then, that C and C++ removed the register keyword. Saves much carnage from many heads exploding.
"I can tell you there are plenty of folks who presume to be able to program a computer without even knowing what a register is."
I have interviewed kids right out of Uni who don't understand what the heap and stack are, much less how to use them, much less how the compiler sees them, and why.
Tut-tut. A low IQ software developer here. And you got me lost at that point. But the low IQ did not prevent me from significant contributions to open-source ONLY because newer easier languages became available. Python being the best example of these, supporting ground-breaking AI and scientific development. Golang being another.
There are multiple complains about under-stuffed open-source projects. So offering safer, easier languages allows to expand the anemic long tail of supersmart programmers into the much more populated middle part of the IQ normal distribution.
Also "smarter" does not necessarily means better. Deep learning is probably the best example with other mainstream approaches being too niche, too complicated. It is almost evolutionary process, where unexpected mutation could offer unexpectedly high reward. But you need a sufficiently big (software developer) population to facilitate the process. And with UK and US school systems deteriorating, it is not fully possible to fulfill the demand with immigrants. By looking at ethnic origins of CEOs of the top high-tech companies it is kind of obvious.
You definitely read too many newspapers with their sociology babble of "generation Z", "generation Baby Boomer" etc.
Suckers are born every day and always have been. But then and now, at a constant rate, Musks and Gausses are born.
Just read the NYT as the Russians read PRAWDA and after some time you can find a little bit of genius in your own honest thoughts.
Been there, done that.
In any non-trivial system, there is No Such Thing As Exhaustive Testing.
An attacker will analyse your code and find an "evil test case" which you have not yet in your test battery. He will proceed to develop the programming error into an exploit. Memory safe, strongly typed languages neuter 70% of CVE bugs. Those who are related to undefined memory errors in C and C++ programs.
I would be shocked if giving the team time to improve their code would not result in better code and increased confidence of the team in the code's correctness.
Every codebase has a ton of technical debt that drags the team's productivity down and defect rate up due to excessive complexity associated with the technical debt. Give the team some time to improve the code without an expectation that they will be adding a ton of new features, and you can be sure the quality, productivity, and even team morale will improve.
The question is whether this Rust rewrite did more long term good vs the same time spent just improving the C++ code (possibly upgrading the code to use such memory safe patterns as RAII).
Mr Stroustrup already made some incorrect claims. Unfortunately he wants to portray C++ as both super high runtime-efficient and memory safe at the same time.
It is easy to demonstrate why this is almost impossible.
He would have a greater posture if he claimed just the first property.
I have to wonder whether the increase in programmer productivity is in part due to much smaller Rust teams than the "huge" C++ teams. The rather obvious observation that the latest and greatest will attract the more talented whereas the older technology is more likely to attract and retain the plodders and would be careerists.
Anyone, programmer or not, who claims a chunk of code is "more correct*" probably hasn't understood. At best its likely to be less incorrect. It either satisfies its specification over its full domain☆ of application or it doesn't.
The heffalump in the room is that a lot of code is developed without anything remotely resembling a specification.
Rust looks like it would be more amenable to the application of formal methods and the last time I looked there appeared to be a fair bit of activity in this area.
Automatic memory management (garbage collection) does provide much of the memory safety of Rust and in many contexts is, I suspect, much less burden on developers to use languages like Go.
* even leaving termination aside and only considering partial correctness.
☆ restricting the domain to where specification does apply could induce an ordering on correctness - the larger the restricted domain the "more" correct I suppose.
"I have to wonder whether the increase in programmer productivity is in part due to much smaller Rust teams than the "huge" C++ teams."
I hope not. Rust's raison d'etre is to extend the type system to be able to effectively act as a lockout-tagout system for programming to limit the ability for defect rates to climb as team sizes do. (i.e. to protect you from changes you didn't see someone else make and vice-versa and to minimize the need to reason globally about the codebase's behaviour.)
..to increased Productivity because I have found it. The One, the Only, the True Path to Programmer Redemption. The Path of Rust..
I was an Unbeliever too. But then we took a large bloated code base written in a very convoluted version of a very convoluted language - no C++ 98 for us it was C++ 17 all the way - and we put a huge amount of time and effort into rewriting our working code to prove that we had found the True Language of the Eternal Magic Bullet. And it was Good.
And then we used a metric of how Good it was that would prove once and for all to the Unbelievers, the Scoffers, those who Rubbish the One and Only True Word, that would prove once and for all the we had found the Truth. Even though the metric was arbitrary, subjective, and complete unrelated to any half way plausible industry metric. But exactly like every other Metric of Goodness used in the last seventy years.
In other words the same old Bollocks we have been hearing from the same type of people since PL/1 was supposed to replace all other languages as the greatest most productive language ever. They even had great big books of metrics proving just how much better PL/1 was. Far more plausible metrics than the Rust ones. And that was in the mid 1960's. Remember PL/1? Of course not.
So has the Rust language actually got any kind of half way complete formal spec yet? Or is it any year now? Yeah, sure
So just yet another Kiddie Programmer Clown Car Language then. Plenty of those over the decades. Plenty.
I've been writing 100% memory safe C for six decades and memory safe C++ for five decades. Its something called paranoid programming a.k.a software engineering and if every second or third statement is not an assert and the code is not written with fail on assert false then its going to fail in the field. Guaranteed. And based on what I learned after a few years working at the coal face in the functional language compiler mine all recursive and gc code will too. I've found that anyone who disagrees with this statement has not the slightest idea about what goes on at the bare metal level. It aint pretty. Not the nice clean diagrams in your academic textbook.
I've had a look at some of the "superior" Rust code. It is written under the same fallacious assumption that all bad code is written. Assuming that everything will always work. It will fail. Just now in a different way. Bad programmers write code assuming everything will always work. Good programmers write code assuming everything might fail.
No language will produce good code from bad programmers. Just do a better job at burying their mistakes. Which sooner or later go boom. In a way the programmers who wrote it will not be able to untangle. So they just keep moving code around until it mysteriously starts working again. The bug aint fixed. It just moved. To blow up at some future date. Somewhere else.
I take exception of your use of "100%". We've all written little bits and bobs, shims, filters,and whathaveyou that aren't technically memory safe, many of which are supposed to be one-time-use-only but stick around for weeks, months or decades. 'tis the nature of the beast.
Overall nice comment, though.
You should have posted under your handle, not AC. Have a beer.
When you lock everything down, write all code involving memory manipulation with checks, double checks and triple checks, and write only continue execution if all asserts valid then the only thing that is left is compiler bugs. Or the OS / CPU bugs. And the same kind of paranoia you use to write trip-wires for memory manipulation bugs gets tripped by the compiler, OS and CPU bugs. Assuming that those kind of bugs haven't thrown a hardware level interrupt / exception. When its going to be up and out anyway. In my experience kernel level OS bugs (not higher level API bugs) rarely fail gracefully.Its core-dump time. And CPU bugs are nearly always Intel bugs. And its CPU lock and dump with those mysterious interrupt numbers which rarely make sense.
Compiler bugs are the most common mystery bugs which are "solved" by just moving the code around a bit. Although writing to an unexpected location in the heap or stack frame can also be solved the same way. For a while at least. The MS VC/VS C/C++ compiler optimizer has been broken for ever. GCC is well GCC. And the Objective C compiler Apple shipped with XCode before they went CLang (a horrible hacked GCC) had some of the saddest most pathetic compiler bugs I've seen this side of some undergrads project. XCode/GCC could not keep track of even basic variable scoping inside method bodies. Not surprised they dumped it. Clang is really nice. Not as nice a Watcom though. Just trying to work out how difficult it would be to integrated the open source Watcom C++ compiler into NetBeans. Now that Apache NetBeans has pretty much totally broken the C++ tool chain. Pity, it was so nice in NB 7 and 8. So sticking with those. When needed.
Fastest way of finding a compiler bug? Look at the disassembly of the code that blows up and see if it looks correct. So being able to read x86/64, ARM, Power PC, MIPS (and a whole bunch of others) instructions sets can come in very handy. And a big time saver.
From my experience, yes C++ compiler errors do exist. Definitely room for improvement in testing and implementation of these compilers.
BUT - it is 1000x more likely to have bugs in the "compilee" code, which you as a developer want to "get flying".
Memory safe languages help you to find 70% of these bugs and to stop the entire system(with a nice, debuggable corefile) before the cybernetic attacker will subvert your program and steal your data. Or worse, manipulate your data in order to make your mission fail. If he does it carefullly, you will never realize what happened. For example, Northern Telecom(once a great canadian company) had their systems subverted for years, including the CEO office !
See http://sappeur.di-fg.de/Sappeur_Cyber_Security.pdf
And here we have the prefect illustration of the lazy programmer type whose sloppy reading of clear technical English makes them jump to the totally wrong conclusion that makes them look like the total cockwomble they are. When it comes to wring clean stable shippable code. The same type of people always write the worst code.
Lets start the Remedial English comprehension class shall we. If programmer A first fires up CFront running with MPW on a MacPlus in 1987 and runs a C++ program and the current year is 2024 how many decades does that make? Lets see. The 1980's.The 1990's. The 2000's, The 2010's. The 2020's. That makes FIVE decades. Yes FIVE
Repeat after me class. Five Decades is not equal to 50 years. Five Decades is not equal to 50 years.
And if programmer A first fires up PCC running on a PDP 11 (typed in on a Decwriter) in 1979 and runs a C program and the current year is 2024 how many decades does that make? Lets see. The 1970's. The 1980's.The 1990's. The 2000's, The 2010's. The 2020's. That makes SIX decades. Yes SIX.
Currently waiting for a build to finish for a multi target cross-compiler / run time environment (X64/ARM) multi toolchain (MSVC/GCC/CLang) multiple platform (Win64/Linux). And you?
On the evidence above I must assume you are some kiddie tech type wannabe who is the typical output from some failed Comprehensive school / public school USD school system. Because your reading comprehension aint worth sh*t. So to speak. To use the Queens English.
Nope. I checked several dictionaries for this:
decade
Pronunciation /ˈdɛkeɪd/ /dɪˈkeɪd/
NOUN
1 A period of ten years. ‘he taught at the university for nearly a decade’
1.1 A period of ten years beginning with a year ending in 0. ‘the fourth decade of the nineteenth century’
(plus two non-year definitions of the word)
The way you used the term matches the usage for (1), so Howard was quite right to call you on it. There was no need for you to be insulting in turn.
And it is the Kings English now. Try to keep up...
This post has been deleted by its author
a decrease by more than 2x in the amount of effort
I like Rust, and I dislike C++ more every time I use it. But claims like "twice as productive" or, worse, the horribly convoluted phrase quoted above ("decrease by 2x"?) are nonsense. Without an actual methodologically-sound metric, computed using a methodologically-sound rubric and process, they say nothing.
And as others have pointed out, self-reported confidence in code quality means nothing.
So let me understand this.
It was written originally in C++. It was working it was fast and it was reliable.
But suddenly it wasn't so they rewrote it in Go, where it was working it was fast and it was reliable.
Until it wasn't so they rewrote it in Rust. So finally it is working it is fast and reliable.
If no new language come maybe next time they even improve the product.
C++ when used correctly gives good guarantees of the correctness of the software. In large c++ projects, because of the type checking, doing a 2000 line change to code is possible without breaking the logic, since type checking catches all the small mistakes. It's this ability to declare 2000 lines of code broken and rewrite the whole area that makes c++ in large systems special. C does not have this property, since types are not used in the same way as in large c++ programs. So if you think linux kernel as example of how it works, it's not the right approach.
1937, officers of the Japanese army.. after extensive field testing in controlled conditions.. conclude that infantry on the attack, armed with the bayonet, are twice as effective as defending troops in dug in positions, with machine guns.
No bias here !
Correlation is causation
Using Rust will slash the incidence of tooth decay in half, improve your posture, and increase your chances of winning the lottery all at the same time.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
