Whatsapp rewrote its media handler to rust (160k c++ to 90k rust)
Posted by NYPuppy@reddit | programming | View on Reddit | 224 comments
Posted by NYPuppy@reddit | programming | View on Reddit | 224 comments
AppearanceFun8234@reddit
How does WhatsApp handle media sending and receiving from contacts ?
CSMR250@reddit
In other news, WhatsApp rewrote its Windows app in Javascript (200MB to 1.4GB memory consumption).
FalseRegister@reddit
What? The one for MacOS used to be like that but then went native. It's a bliss.
maqcky@reddit
Native Windows development is a mess nowadays. Apple does not care about backwards compatibility and it forces you to use their newest framework. Not even Microsoft uses WinUI 3. For instance, parts of the Start Menu were rebuilt using React Native.
MacASM@reddit
why is it messy?
maqcky@reddit
There are too many UI frameworks for Windows and Microsoft does not stick to any one of those. They should be using WinUI 3 with C# and XAML but they use React Native in some places, WPF in others, many applications are built in electron, etc.
Eric848448@reddit
What even IS native Windows development these days? JavaScript?
wk_end@reddit
WinUI 3 is, I think, the latest toolkit that MS is pushing and will soon abandon.
MacASM@reddit
soon abandon?
thesituation531@reddit
It doesn't even have to be "native" like one of Microsoft's frameworks.
Just pick literally any framework that uses a windows API, or uses its own and is hardware-accelerated but isn't web. There are a lot of good UI frameworks that isn't the garbage that is React Native and Electron.
----Val----@reddit
React Native isn't web based and is nothing like Electron.
thesituation531@reddit
Perhaps, perhaps not.
The name is certainly web-based, and every React app I've used feels just like Electron: just like a webpage but laggier.
Xystrel@reddit
And Javascript's name is Java-based and look how related those are
----Val----@reddit
Its not even a perhaps, React Native is not a web technology full stop. It doesnt use a browser, doesnt use a browser JS VM, isnt JIT compiled and doesnt use HTML.
Its called React Native because it uses the
reactlibrary for state/diffing and maps the virtual dom to native component, but doesnt usereact-domat all.thesituation531@reddit
That's nice, but it still feels like web tech, and it was born of it. The feel and the performance are what matters. I wouldn't give a shit if everything was using these garbage frameworks if they actually worked well and didn't just feel like worse web pages.
----Val----@reddit
Could you provide an example for a react native product this applies to?
ee3k@reddit
ai mostly, based on the last patch tuesday.
raevnos@reddit
Whatever the AI feels like using.
TheWM_@reddit
I wish there was a fully open alternative to Qt. Qt is basically the only good option for low-level cross-platform GUIs, but the licensing is a mess. If there was something that was just as good but free, I think a lot more people would use it.
silajim@reddit
It's lgpl what is messy about it? yeah, there are some modules that are commercial only or gpl only but you can make a lot of stuff with the lgpl
sorressean@reddit
Wxwidgets? It's also accessible for screen readers where QT still struggles in some areas.
TheWM_@reddit
I haven't used wxWidgets, but apparently it's not very pleasant to use. It also looks blurry if you have your scaling above 100% in Windows.
_VZ_@reddit
Just for the record, this is false, wxWidgets has high DPI support since many years. Applications need to use correct values in their manifest but this is something that only application developers can do.
TheWM_@reddit
At the very least, every app I've seen to have this problem has used wxWidgets.
sorressean@reddit
I didn't know that; I've avoided QT mostly because it's not usable for screen readers. It's not ideal generally; it's a lot of code and the library is huge, but when I wrote UIs in c++ it beat many more hundreds of lines of win32 code, and I just kept the wx code off in a corner where no one would look at it much after it called into the controller-type layer. That's good information/background and also a bit sad given that my hope has always been people will use the more accessible option.
UnacceptableUse@reddit
Doesn't part of the new taskbar run in Edge even?
Interest-Desk@reddit
No, React Native. The view is native code but the react side (which tells the view what to put where) is in Node or something like that. I’m not super familiar with RN but I do at least know that the stuff the user sees is native code.
UnacceptableUse@reddit
I could've sworn there were some EdgeWebView processes that are tied to the taskbar. Perhaps I'm thinking of widgets though
DeveloperHistorian@reddit
The MacOS one works like a charm, it’s very good!
Eric848448@reddit
I wonder if they’re going to kill it like they did with FB Messenger for macOS.
Sharlinator@reddit
Almost certainly. It's already lagging behind on features…
light24bulbs@reddit
Oh yeah I was wondering why I hadn't been experiencing this, remembered I'm using Mac.
repeating_bears@reddit
7x improvement!
Mental_Estate4206@reddit
Bigger is better, always anytime
WaitForItTheMongols@reddit
I bought 32gb of ram, I'm going to use 32gb of ram.
MathKillsYou@reddit
I bought 128 gb of ram (DDR5 btw), I'm going to use 128 gb of ram.
jnxy_@reddit
OK, we understand, you rich. Show off.
tadrith@reddit
I have that, and thanks to work, my virtual machines eat ALLLLLL of it.
jug6ernaut@reddit
Y you gotta flex on us like that
WaitForItTheMongols@reddit
Oh, I don't actually have 32 in my machine. I have 128. Salvaged it from my college's ewaste heap. Crazy the stuff the math department gets rid of. I think they were at the end of their fiscal year.
SnugglyCoderGuy@reddit
The more memory we demand from our apps, the less that is available to our competitors (please god, dont let that be real at any point in any timeline).
LegitimatePenis@reddit
– Todd Howard
hongooi@reddit
You know what they say, unused memory is wasted memory 💪
Emotional-Energy6065@reddit
😭😭😭😭😭 dont make me feel feel even worse
Little-Helper@reddit
"Unused RAM is wasted RAM" /s
LLFTR@reddit
Yeah. I never got this one.
For complex apps it makes sense. Easier to just build a website basically, than to tediously program all the various interface screens and elements using any desktop GUI SDK. I know it's still doable, but the website-in-a-wrapper approach cuts development time. Manager happy, end-user memory usage be damned.
BUT THEY ALREADY HAD THE APP. Why on Earth rebuild it? It's not like the WhatsApp interface will vary wildly and tons more panels would be needed. They ALREADY had the app, it was built, it worked, it was better, just needed to be maintained. Why start from scratch?
CSMR250@reddit
That argument works if the company knows about the web as a cross-platform framework and is not aware of any others!!
dukey@reddit
lol, on 32 bit windows you could only theoretically allocate up to 2gig of memory for your app. But if your heap became fragmented that figure could be MUCH less. These kinds of insanely bloated programs would be unthinkable a generation ago.
exscape@reddit
If you mean human generation, then sure. Two generations ago, having a megabyte of RAM was... well, not unthinkable, but a lot.
Not defending WhatsApp here as 1.4 GB is still unacceptable for that kind of app, but I switched to 64-bit Windows 21 years ago.
Sparaucchio@reddit
Bro it's a stupid messaging app, it shouldn't need more than 2MB of ram lmao. Unless you have chats with trillions of messages. God damn, what does it have to do other than asking the server "is there any new message"?
Ah right, they scan your chats with AI...
dukey@reddit
Given the current cost of ram, this kind of insane inefficiency might be not be cool again lol. Skype went the same way, really just a simple messaging app but on mobile it got hilariously sluggish and borderline unusable. Our team switched to signal and never looked back.
Polymer15@reddit
Ah, but you see, they aren’t paying for the memory!
cyberbemon@reddit
it is hands down one of the worst fucking things I have used. I like having it, cos its easy for me to answer calls when im on the pc, but my god does it fucking suck so much.
vini_2003@reddit
It's impressively horrible! If I made such a horrible app at my company I'd be fired. The bloody thing crashes, freezes, misses messages during sync, it's such a mess.
DecadentCheeseFest@reddit
Very Microsofty.
chobolicious88@reddit
Its awful. It legit lags for typing basic messages… i just cant…
Jaggedmallard26@reddit
I just use the web.whatsapp webpage. If I'm going to be running a browser it might as well be the browser I'm actually running.
usrnmz@reddit
Yup. I switched back to web recently. Much better than the app.
t-to4st@reddit
Can't take calls on there though
AlternativeCapybara9@reddit
Another plus
auctus10@reddit
I found web whatsapp to be somehow worse than the windows app. It's slow and lags.
lobehold@reddit
Performance for me, bloat for thee.
hhpl15@reddit
Was this recently? Can't get the app to work since a few weeks
ManagementKey1338@reddit
A plot to drive up DRAM market apparently.
zenware@reddit
Well that’s because they want the code on their servers to be performant to save their own money, and because they don’t care about client side perf since that’s not their own money.
pheonixblade9@reddit
Beeper is great :) currently under 300MB for whatsapp, sms, signal, fb messenger, instagram, discord, telegram all in one app.
Leirbagosaurus@reddit
In this economy?!
manystripes@reddit
Thank goodness RAM is so cheap these days
notsooriginal@reddit
Excuse me, Windows App is reserved for our new remote desktop program. Please and thank you for not destroying our SEO.
Martin8412@reddit
I still don’t understand what was wrong with
mstsc.milanove@reddit
Probably named by the same people changed Microsoft Office to Microsoft 365 Copilot app.
cake-day-on-feb-29@reddit
You could've just said "Microsoft"
maqcky@reddit
Because that doesn't cost them money. Keeping a native version is actually more expensive.
Sopwafel@reddit
I made a reddit post about WhatsApp hogging 100% of CPU resources like 5-6 years ago and I'm STILL getting occasional fresh comments from users experiencing the exact same fucking issue.
The workaround is to go into your registry and assign the lowest possible CPU priority to the WhatsApp process, which is ridiculous.
sorressean@reddit
My hero. it's also garbage. I'm not sure what their accessibility department does, but it turns out they're not fixing accessibility issues because for blind users it's a total reversal. This new rewrite is broken, doesn't support half of what their desktop app did, and they force signed everyone out and forced you to update to this stupid buggy whatsapp desktop version.
NurUrl@reddit
WhatsApp Give and WhatsApp Take.
sjepsa@reddit
The language of rewrites strikes back
sad_cosmic_joke@reddit
LoC is not a good measure of anything.... without additional context the base assumption is that that code just got pushed out into 3rd party libraries.
LoC comparisons don't tell us anything about efficiency, security, or actual maintainability/accountability.
That's my $0.02
matthieum@reddit
That's certainly a possibility, as Rust isn't particularly terse (cough).
From a maintenance point of view, however, LoC definitely matters. Of course, you do need to get trusty 3rd-party libraries, but once you do, less code to maintain is pretty neat...
... especially if the replaced code is in the deep bowels, and requires arcane tricks with UB looming over the maintainer like a Sword of Damocles.
sad_cosmic_joke@reddit
Part of "maintenance" is "accountability"
Absolutely, the smaller my code base the less upfront work I have to do...
"Of course" is doing a ton of heavy lifting there... The trade off for pushing things out your codebase is increased vulnerability, greater attack surface, stochastic fragility, and long-term stability.
These are the "accountability" apects of code maintenance -- ie: who's responsible when something breaks? Who's responsible/culpable for preventing that?
As a career software project manager/programmer these are the questions I have to weigh and answer when making these kinds of deep platform decisions.
budgefrankly@reddit
What makes you think this implementation uses many, or any, external crates?
matthieum@reddit
I agree dependencies are a trade-off, and a cost/benefit analysis is required at the individual/company level:
There's also, interestingly, a cost/benefit analysis at the ecosystem level, where consolidation tends to be beneficial in terms of quality, maintenance, etc... of the available libraries.
So, yes, trade-offs.
BUT in the very specific context mentioned here, it turns out Rust has multiple high-quality crates for encoding/decoding images, in particular (less sure about video/sound), and the formats are complex enough that using pre-vetted crates can definitely be worth it.
(Bonus points: a number of the image crates are unsafe-free...)
NYPuppy@reddit (OP)
If you read the article they explain some of that, including their rigorous testing method.
Fwiw I'm surprised the rust is actually less lines.
angelicosphosphoros@reddit
What's surprising? A lot of stuff you need to write manually in C++ (e.g. hashing, serialisation, equality operators, etc) can be written in a single line using derive macros in Rust.
Also, with Rust, it is easy to link to third-party libraries.
And even little things can reduce amount of code. E.g. match operator is shorter and easier to read than switch, especially if you have if statements in switch. Another example is block expressions that allow to structure code without having to move that parts into separate functions or using IIFE.
Also, you can rewrite some data transformations way shorter using iterator combinators (e.g. map, filter, reduce, fold, sum) way shorter than using for loops or header.
EfOpenSource@reddit
Yeah. But this is a significant shrinkage.
Personally, I would say that it is a lot due to rust knowing what it wants to be while C++ is… C++. If you have 10 different, equally experienced programmers write something in rust vs C++, I’d wager the rust versions will be far closer to one another than the C++ versions.
Then the rust rewrite had the benefit on hindsight, which is huge. As a personal example, I once shrunk an internal module down from 4,000 LOC to just 400, and mine was more robust, handled more situations, gracefully dealt with bad data, and ran like 40x faster.
Then rust also has the great benefit of far easier use of 3rd party code (3rd party code which itself is far and away generally rewrites of existing code with the same benefits).
Personally, I would still agree with others that LOC diff is not a thing to highlight without full context given.
Full-Spectral@reddit
I'm not sure why anyone would be surprised that the same functionality in Rust would require fewer lines of code. As someone who has written C++ for almost 40 years now, and am now far enough down my Rust path to write good, idiomatic code, my Rust almost always more concise.
One obvious thing is that, for reasons that have always wobbled my mind, the C++ folks have gone decades without provide some of the most obvious helper functionality. So you end up writing so much wordy, grunt work code that Rust almost always has a very clean way of doing. It adds up over non-trivially sized code bases.
IDUnavailable@reddit
Seems like the "performance and runtime memory usage advantages" would be more useful to include in the title, although the article doesn't have any interesting data quantifying those "advantages".
kuikuilla@reddit
The title of this post should be "Rust at Scale: An Added Layer of Security for WhatsApp", nothing more and nothing less. That is what the title of the article is anyway.
buzmeg@reddit
They are almost certainly not counting the lines of code of all the crates.io packages they are pulling in.
I suspect almost all the LoC gain was from using external libraries for tasks that they were using their internal code for previously.
That's not necessarily a bad thing. But it is a tradeoff.
RussianMadMan@reddit
In C++ you either get someone parsing 30MB json with a scanf (GTA V incident), or you get a cobbled together garbage that copies same string 10 times, because half your libraries are in C and they take char* and copy it themselves and the other half uses some custom string/vector class because of compatibility issues and you have to copy the data anyway. And its all in different encodings too.
notyourancilla@reddit
qUaNtiTatIvE bEneFitS
Buddy that’s a number that is smaller than another number of equal unimportance.
If you asked 4 people to do this task in the same language I’d put money on there being a 100k line spread from largest to smallest implementation.
What matters is you can read it and understand it at the end of it. Now, would the c++ have been easier to read than the rust stuff, anyone’s guess, it was probably rewritten because it was ‘legacy’, which is what we tend to call ‘someone else’s code’ nowadays.
Either way I’ll look forward to the we rewrote this rust garbage into zig blog post in a few years when the rust guy leaves WhatsApp
YeOldeMemeShoppe@reddit
That’s a pet peeve of mine, because it is a dangerous idea that LoC don’t matter. In the real world for average projects, LoC will definitely matter even before accounting for maintenance of the code.
From Code Complete (McConnell 2004):
LoC matters. It is linearly correlated to the number of errors in the code. Whether those translate to exploitable errors is also a subject of research (cant find the link at the moment for the DARPA study).
See https://rstudio-pubs-static.s3.amazonaws.com/926483_590da6817bd94b0094dfc3bc130a8aec.html for some more data.
sad_cosmic_joke@reddit
I never cliamed that LoC isn't an useful metric, I use it all of the time in my own analysis, just that it's meaningless (a) on it's own, (b) when comparing language ports.
YeOldeMemeShoppe@reddit
First, the IBM anecdote is imo less a criticism of LoC as a metric, but rather Goodhart’s law in application. This is different than using LoC as a measure of potential errors.
Second, I’d counter that using a library will result in less bugs (unless you’re going full clean room development with your processes) than reimplementing the library yourself (assuming the library has a history of bug fixing of course). So with that into account, yes I would maintain that less LoC in your own project is still less errors (without accounting for third party libraries), on average in the industry.
We don’t have to agree on it, but all the research I’ve read points to it. It has also been my experience in a career on some big projects; reducing LoC regardless of language reduces the amount of bugs overall. The other metrics that would make a dent over time would be age of the project (or measuring fixes PRs) and regression testing.
Interesting read: https://www.mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio
Amendment: to avoid getting into “but I can make all programs in a single line of C/Python/JavaScript/… kekeke”, let’s interchange LoC with something like tokens (as in lexer). They measure the same thing in any sane project with style guides, let’s call it the viscosity of the code.
sad_cosmic_joke@reddit
Excuse me for paraphrasing in your quote here:
Agreed
There's the rub... using a library externalizes the complexity and obscures the total lines of code. To get a full picture of the effective change in complexity (measured by LoC) you have to include the entire compiled code path - including the libraries!
Brief example: someone as part of a project rolls their own crypto in 200 LoC, realizes that's a bad idea and switches to a secure library resulting in those 200 lines dropping to 10 LoC. This is great, this is a good idea, but this also incorporated an additional 2k of LoC from the library and now the code runs slower.
A surface drop in LoC says nothing about what the program is actually doing.
I've had the same experience... the thing is in those cases, every LoC reduction came as a result of a carefully planned refactoring and bug squashing campaign. It really seems to me that it was this intentional act of improving the code that resulted in less bug and fewer lines of code.
The LoC reductions in those cases were a side effect of intentional bug fixing (correlation), and not the primary cause.
BTW I really appreciate your agruments and the way you presented them. Kudos!
przemo_li@reddit
LoC is a good bug counter. Just not across languages. Other big rewrites also suggest that new code in Rust is less bug prone to new code in C++. That's not however a full rewrite.
sad_cosmic_joke@reddit
I'm really not so convinced that is directly the case. LoC reductions in a code base almost invariably come as part of a larger refactoring and bug squashing campaign.
To me it seems that this intentional act of fixing bugs is the root cause for less bugs and the LoC reduction is merely a side effect and artifact of those efforts.
Correlation != Causation
SiegeAe@reddit
I wouldn't say that's the base assumption if you've converted anything notable from C++ to Rust before, though that is possible for sure.
Honestly I'd say its very likely most of the line diffs were just formatting, as a lot of C++ devs write very spaciously, as well as rust typically using much more method chaining instead of explicit loops or try catch blocks.
It doesn't concretely say anything but it does indicate likelyhoods, it could very easily be worse for both of those, but I would say: - There us a slightly higher chance that it is more efficient than less efficient since its likely the copied very equivalent algorithmic choices so if they did then in most cases they'd save on the cost of abstraction a little. - It is also more likely to be more maintainable, sure it could be less as it could be too terse or some QOL choices could've been misunderstood and removed but that much less code is more likely to be less effort to fix and change as the amount of reading to understand the current state would be more likely to be less. - It should also in theory be more secure as rust's choices in the standard library often were made based on security first and it also stops some potential security problems from being possible with its memory model.
I definitely agree there are no good measures, but to say they don't tell us anything is too absolute.
axonxorz@reddit
(your LLM outputs broken markdown for old reddit)
SiegeAe@reddit
and goddammit there's even typos in my message should've made it obvious its not an LLM
SiegeAe@reddit
fuck you man I wrote that shit by hand and the formatting is fine if you're not using ancient artifacts
menictagrib@reddit
Looks fucked on all platforms to me. You may be able to ask ChatGPT to add double spaces.
SiegeAe@reddit
double spaces for what? I put a hyphen at the start of each point and two lines between paragraphs, nothing weird and there's no code so it shouldn't be different anyway
sad_cosmic_joke@reddit
Offloading previous functions into the language's standard lib is still moving moving code to a 3rd party library.
I like how ChatGPT is being so non-committal in the response it gave you.
SiegeAe@reddit
No its not lol, its a library but its still part of the language not 3rd party, you know C++ has a standard lib too right?
Also "Non-commital" do you not know what nuance is or do you think you just have to say absolute things even if they're false?
Saying any of that shit with absolute certainty would always be either memeing or an idiot take, you're not a fucking oracle lol.
Also, you were technically incorrect, chatgpt would've most likely been too.
sad_cosmic_joke@reddit
Thank for pointing out the obvious!
Did you write the standard library? If not then it is third party to the developer.
That seems pretty third party to me!?
Not commenting on the rest because your tone is borderline abusive, the 'argumetns' are completely ad-hominem and unabashedly hypocritical.
Good Day Sir.
SiegeAe@reddit
You accused my writing patterns of being like an LLMs which is worse of an insult than anything I said to you lol.
The fact that C++ has a std lib makes your point about abstracting the code away redundant is all. Also would be 2nd party in this case since we're talking about a developer and rust.
GenazaNL@reddit
Or some features being removed
Iggyhopper@reddit
Plot twist: The 70k extra lines was X Macros and templates.
Far_Marionberry1717@reddit
They said C++, not C, come on.
Mars_Bear2552@reddit
Cthulhu__@reddit
It’d be a better comparison if they shared metrics like compiled app size, raw performance, etc.
nkviz07@reddit
Partly disagree, less LoC often means easier time reading, easier time preserving system knowledge and maintaining. It might not necessary be the case, especially if we are measuring one language to a different one.
Psychological-Rub505@reddit
I agree that less code is always better except for when it hampers readability. However, less LOC does not necessarily mean easier time reading, especially for large codebases. Similarly, the preservation of system knowledge is not proportional to LOC. System Knowledge should be about features and processes. It doesn't matter if a particular feature has a LOC of 10K vs 12K. What matters is the feature, how it behaves etc etc.
sad_cosmic_joke@reddit
That can definitely be true, but establishing that requires transparent comparison of the code bases.
As is the case here ;)
xLosTxSouL@reddit
90k for a media handler? Lmfao
seweso@reddit
I never understand the point of these posts.
If you rewrite you’ll always improve. A fair comparison would be comparing a full rewrite in c++ and rust.
the_ai_wizard@reddit
I mean, sometimes rewrites completely fail lol
seweso@reddit
Somehow nobody boasts about that
meanest_flavor@reddit
Y'all might not know, but bloated ain't a term that Rust created.
It has been rewritten with way less code since BSD and GNU people begun back there.
d_o_n_t_understand@reddit
I have a suspicion that if they rewrote c++ in c++ or any other language, they'd also save a lot of LOC and produce better quality code. That's what happens when you rewrite something that already exists, you know what are the requirements beforehand, and you can carefully plan how to porcees
Psychological-Rub505@reddit
It really depends on the quality control and the type of app you’re writing. Something like WhatsApp has to focus heavily on performance, so they’re not writing code willy-nilly.
A reduction from 160K to 90K lines of code is a huge drop, nearly 50%, which isn’t what you’d expect from an app like WhatsApp.
EfOpenSource@reddit
We don’t know what’s they’re even counting though.
It is like what you see in /r/Python code comparisons where the Python is indeed 2 lines, but one of those lines is importing everything, and they C++ version uses no headers and implements system calls manually, then they all jerk eachother off over how the python is so much better cause of that?
NYPuppy@reddit (OP)
This gets thrown around a lot but it's only partially true. There is an empirical benefit to rust over c++.
nyibbang@reddit
You're getting downvoted and yet you're right. I write both C++ and Rust and I can say 100% that Rust code is less buggy than C++.
And people who say otherwise either don't know C++, don't know Rust or worse know none of them.
5gpr@reddit
Rust code isn't less buggy than C++, you are writing more buggy code in C++.
FaceyMcFacface@reddit
Rust makes it harder to write buggy code. The compiler points out a lot of issues that would otherwise arise only at runtime. So yes, you are writing buggy code in both, but Rust forces you to acknowledge the bugs at compile time.
5gpr@reddit
That isn't even my take. I was originally just amused about dude going "I write programs. C++ and Rust make mistakes.", paraphrased briefly.
As regards mistakes "my take" would be that we are nominally an engineering discipline. We ought not use tools in lieu of expertise and care, especially since it's us that are held responsible for mistakes, rather than said tools.
nyibbang@reddit
If we put aside the rage bait, you're absolutely right. And it's simply because C++ makes it really difficult to write non buggy code.
UB is everywhere, standard library types make no sense. You have to read every bit of a type to use it correctly. You have to know every rule and every exception to them to not step into pitfalls.
Now I agree I'm not perfect and I make mistake. Rust stops me from doing them, and the standard library actually make sense, compared to whatever the STL does.
But let's have some fun, let me read your C++ code so I can learn how to not write buggy code please ! I'm sure I won't find dozens of UB in it right ?
5gpr@reddit
It wasn't meant to be rage bait. I just found your switch from active to passive voice funny.
I find that modern C++, especially in application development, generally works as I would expect it to. It becomes more complex when writing libraries or library-like code and it is necessary to accommodate as of yet undefined types.
Not generally, no. I'm not saying that I don't make mistakes, but software development is my profession. I can't go around blaming my tools for my mistakes. I'm also lucky in that I'm working in an environment where speed of feature implementation isn't the primary concern, so that the requisite care can be taken.
That aside, you say
In what way?
How is that not true of rust, too? Look at
hashand tell me that you don't have to read every bit of that to correctly implement the trait for some type.nyibbang@reddit
It's mine as well, in C++ especially.
There would be too much to say. So I'm going to focus on things that happened to me from the last months and I've been bothering me.
void, which is another mess to deal with.error()is similar to theoperator*, it is UB to call it if there is no error in the expected.value()on the other hand will check if there is a value and throw an exception.ranges::split_viewsplits a range with a delimiter. Now, the invariant should be that a range that contains N delimiter, once split, should produce a range of ranges of size N+1, right ? IT MAKES SENSE RIGHT ? It's what EVERY COMMEN SENSE SPLIT FUNCTION WOULD DO. Well no, not in C++, if you use split_view on an empty range, you obtain an empty range, instead of a range of one empty range. Now you have to get bitten in the ass at least once by this function to know that. Here is the issue https://cplusplus.github.io/LWG/issue4017, there is at the moment no fix for it.That's just a couple, there are so many more. Some from the standard library, some from the language itself. You don't realize a bad it is until you've pulled your head out of the sand and used another language that does not do this kind of shit.
In most cases for Hash, you can derive it and it will work out of the box, but I see your point, and I don't think you understand what I meant.
In C++, you have to read get informed of every thing from each function that you might call if you want to ensure that you do cause UB. UB is a plague, it breaks the integrity of your program, that's what most C and C++ programmers don't understand. They underestimate what it does.
Avoiding UB in C++ is like walking on eggs. You have to be careful every step of the way. In comparison, in Rust, as long as you don't do unsafe code and you don't use crates made by people who don't check their safety invariants correctly, you're guaranteed to not cause UB, no matter what you do. Your program might not do what you want because of your mistakes, but it will never make you think it does things correctly while invoking UB, which is what C++ is allowed to do.
NYPuppy@reddit (OP)
And Rust as a language makes it easier to write performant, correct code than C++. It's simply a better tool.
menictagrib@reddit
As someone who learned C++ as my first language, has great fondness for it, hasn't used it much in a while, and has recently been learning Rust... I kind of feel like experience with C++ would make you appreciate the language, unless one is simply externalizing fears about the future economic value of their skillset.
The language is reminiscent of C++ if it had been designed to hit you across the knuckles with a ruler any time you even suggest half-assing your design decisions, instead of giving you maximal control and expecting you to reinvent the wheel 5-200 times per day.
d_o_n_t_understand@reddit
Yes, of course, there are places where rust is objectively less verbose, less complicated, etc. than c++. I'm not saying rust is bad, just that the statemant that rewriting something specifically in rust will magically reduce the size fo your codebase by half, made it more clean/less buffy/more safe is also only partially true.
nyibbang@reddit
There is no magic, Rust and its standard library are both better designed than C++ and its standard library.
non3type@reddit
I’m unsure, the article is a little ambiguous about the sequence of events:
“Rather than an incremental rewrite, we developed the Rust version of wamedia in parallel with the original C++ version.”
d_o_n_t_understand@reddit
I believe it means that they fliiped the switch from ful c++ to full rust after rust version was feature complete instead of replacing codebase part by part.
twobitbrain@reddit
cool read! I need to practice some more with Rust
voc0der@reddit
Remember that time that they're being sued...
Oh right, that's right now.
They lied that their platform was secure. No e2e.
https://www.pcmag.com/news/lawsuit-alleges-that-whatsapp-has-no-end-to-end-encryption?test_uuid=04IpBmWGZleS0I0J3epvMrC&test_variant=A
ArdiMaster@reddit
voc0der@reddit
It almost doesn't matter, because of the way they are completely closed source and any public trust shattered without re-proofing. Signal you can checksum the client.
WhatsApp is a just bad chat app at this point, doesn't matter what it's written in.
tnemec@reddit
Meta: "WhatsApp is E2E encrypted, source: trust me"
Some random lawsuit: "WhatsApp is not E2E encrypted, source: trust me"
I mean... it may well turn out that Meta lied, I certainly wouldn't put it past them, but unless you just blindly believe the last thing you've heard on a given topic, I don't think anyone went from "I 100% trust WhatsApp" to "my trust in them is completely shattered and I will need to see incontrovertible proof showing they were in the clear to ever trust them again" just because this lawsuit merely exists.
DedlySnek@reddit
That's why the article mentions end-to-end encryption multiple times. They really want us to believe them.
Sunderblunder@reddit
Why use many word when few word do same trick
Educational_Cow8366@reddit
I'm not really sure but from what I know I can say that now go and rust is very optimizing. Now some of big techs are rewriting their code to go/rust.
jaredcheeda@reddit
This reminds me of this quote:
immersiveGamer@reddit
Quote from who?
I agree. Often by reading existing code, just for the act of reading it, you can find bugs or improvements. Obviously it is a hard sell to tell your boss "hey we should just read our code". Refactoring or a rewrite of code is continuation of that reading and understanding, can't refactor what you don't know.
However, I do find that often re-writes create new bugs because it can very easily mis recreating behavior that was originally a mistake but now other code depends on that incorrect behavior.
omgFWTbear@reddit
I know he’s controversial, but I think of Spoolsky’s article on the Netscape rewrite, to paraphrase my recollection of it, “It turns out the accumulated kruft, was, in fact, dealing with dozens of 5% of users edge cases, and so by cleaning up the code, you’ve unlearned years of research.”
That said, I don’t intend to advance the extreme position of calcified code, merely the caution against the reverse, careless “streamlining,” which I also don’t intend to imply was what was said.
jlboygenius@reddit
I manage an app for my company. it's a bit dated, but works fine for the users. THe UI is decent and hasn't limited any features we wanted to build.
The IT devs want to re-write it in rust, because it's something they understand.
There are dozens of small features added in that aren't documented well. re-writing it would be fun to learn something new, but I can't see how it benefits the end user or business owner. at the end of the day, they'll end up with the same product, missing a million little features and adding dozens of new bugs to fix.
This idea was never even presented to the business owner group. I'm not sure who's going to eat the cost of it, since it'll easily be half a million dollars in dev salaries.
saintpetejackboy@reddit
There are very few individuals or teams who can do a proper rewrite of a live business system, and the pool of people shrinks the older and more complex the business proprietary software becomes. This is something I have specialized at in my life and I had to quickly learn some tricks and some of the actual pain points of a rewrite from scratch. The most dubious and difficult part (especially is swapping stacks entirely) is the point at which you try to swap over handling the data or swap over the users to a new interface, especially if you have a lot of users. It can be an almost unsurmountable problem if you don't approach from the right vector.
You can easily churn out a clone of 80% of the features, sure, and on paper and in theory a brand new software might work sufficiently, but that point in time when you actually have to make it go live is when the other 20% bites you in the ass. The day to day grind stuff that somebody else or a whole team spent YEARS trudging through, incrementally as it happened, are now laid in your lap all at once.
I found there are ways around this, but it requires careful scaffolding and experience having gone through similar situations prior in a variety of contexts, if everything were intuitive, then a fresh rewrite would work out of the box - but they aren't and it won't.
Then you also have critical systems where the risk may outweigh the reward. Some small fuck up could cost hundreds of thousand dollars, or cause legal peril, or jeopardize sensitive data, or result in seizures, coma and death. Those risks might not be worth "we reduced the lines of code by 90% and certain metrics now load 20% faster!" - the rest of the company isn't the IT department in most cases and wouldn't even be able to comprehend or quantify the end goal. Many companies won't even splurge enough for proper maintenance and other required and associated costs with a project, so trying to convince them to reach in their pockets for a greenfield rewrite when their current software isn't actively on fire and crushing orphans is typically a hard sell.
jlboygenius@reddit
we moved from one server to another and it requred a dfferent URL. for weeks people were like, is the app down, i can't get to (the old URL). like, where have you been? we trained on this, emailed about it, it's been news for weeks. THe old site even had a big warning on it for a while.
Right now the decision is between going COTS or potentialy re-writing it. I don't want to go COTS, so I don't really want to tell the business side that is thinking that about what IT wants to do. If they hear that IT wants to re-write it, they'll just use that as a justification to go COTS. But, I'm also using that as a way to hold off the IT group, because if we're gonna go COTS, then there's no reason to re-write it.
Of course, going COTS will cost a TON of money (consultants beause we don't have the balls to do it ourself), take a long time, and leave us with a product that is static. We'll end up building a lot of side projects to support the COTS product because we can't ever change it. It'll be part of the financial system, so any update/change is nearly impossible.
giantsparklerobot@reddit
Anyone that wants to rewrite something needs to be responsible for writing 100% coverage unit tests for the existing software. If they can pull that off they know enough about the existing code base to rewrite it faithfully. If they can't...they're not rewriting the app, they're writing fan fiction in a different language.
jlboygenius@reddit
The main 'architect' guy is the most whiney complainer nerd i've ever met. He bitches about stuff all the time. Like, ok, we get it, can we get to the part where we resolve the issue and get past the whining and bitching part? My concern is that he's going to agonize about some tech issue and ignroe the requirements of the user.
LordoftheSynth@reddit
Is he one of those Rust zealots who runs around telling everyone they've been programming wrong for decades, and they need to rewrite all their shit in Rust?
omgFWTbear@reddit
Yeah, that’s the thrust of that Spoolsky article, to not rewrite just because we are excited to do it.
I’ve similarly worked a few things where the cost of developed with the skillset needed has gone up a lot compared to the median, and for example, one guy got them to pay for him to take the train from his retirement community on Monday, stay in a hotel Tuesday and Wednesday, train ride home Thursday, f—- off Friday; an agreement I think we know only exists because it’s him or nobody.
The business justification for a rewrite in that case writes itself. They’re actually excited to end at the same place they began, but with a developer pool they can hire from that vaguely resembles the general market.
jlboygenius@reddit
that's part of the problem here. I'm the only guy that's been dev on this app for the past decade and I'm not part of the IT group. IT didn't provide support, so my dept hired me to manage it outside of IT.
times and management change, IT wants more control.
They'd rather re-write it in rust than spend time to learn how the existing system works (angularJS). No doubt, they could learn enough about angularJS in 1/100th the time it would take to re-write it(which, most of the team doesn't know rust either, so it's all learning something new).
There's also talk of ditching it and ging COTS, so IT and the business have not been talking (even though the IT management is in those discussions). So we'll probably be spending a LOT of money either way to end up with a new set of problems.
LuckyHedgehog@reddit
Considering it reached end of life 4 years ago, I get it. Security will become a concern even if it's an internal only application, who knows how long the tooling will remain supported or functional. The odds you'll find a front end dev these days who know it or even willing to get hired to maintain it will dwindle very fast.
Having a team of internal engineers take the time to learn it well enough to rewrite it in modern tooling has the benefit of training that team on the entire feature set of the application. They should be productive on maintaining it and delivering new features once complete, whereas right now I bet it would be a struggle adding anything of moderate complexity
robolew@reddit
Is spolsky controversial? He might be a bit blunt and reductive, but I feel like most people agree with most of what he says
omgFWTbear@reddit
Three thoughts -
one, citing someone on the internet these days begs the “you’re all in on everything he says, and that makes both of you a villain by the transitive property because one time that person picked my dog!” reply
Two, like RMS, when citing RMS replies are often, “but he was insufferable to interact with.” Yes but was he wrong? “No, but he was insufferable to interact with.” Let’s be fair, if either of us anticipated Amazon half a century ago, we’d be pretty insufferable, too. And if you threw us in a Time Machine and we were passionately trying to stop DRM, we’d probably be more insufferable.
Three, I hail from the ancient times where the Browser Wars were fresh and bloody, also plural; and writing that could be perceived as identifying any fault in any camp automatically made you a villain to all, and basically loop in points one and two.
So, I hoped to preempt any discussion of the author as the write up is decently clear, breezy, and on point.
Slappehbag@reddit
It's sort of like Chesterton's fence.
anengineerandacat@reddit
TBH it's always easier to improve upon an existing design, it's much harder to get a perfect design out the door.
Been on the side rebuilding apps and been on the side building the apps to be rebuilt.
Easy to poke fun at shitty designs, but depending on the business behind it at the time it might even be a miracle anything got designed in the first place.
jaredcheeda@reddit
There are two types of tech debt, Intentional, and Unavoidable.
You may decide to do something the wrong way to make a deadline, knowing you'll have to fix it later.
Or you may use all the best judgement you can with the data you have today to decide an approach for the code, only later to find out, once you have more information that your solution was either under-engineered resulting in lots of bad connecting code or over-engineered, resulting in lots of complexity that makes the system harder to work with.
You can't help it, the user's don't know if what you built is what the wanted until they try it and give feedback, and you don't know what the product will look like in 5 years. How will other market forces and competition effect your company and the needs of the users of the software. What improved technologies and patterns will be available to you by then that negate your previous best practices.
Only at the end of a project do you have the knowledge to actually start on the project correctly.
dylanbperry@reddit
Wayne Gretzky
captain_obvious_here@reddit
on_the_pale_horse@reddit
Which is why rewriting minecraft java in C++ famously reduced all bugs
TulipTortoise@reddit
That codebase is a monstrosity because it changed what it was supposed to be ~3 times all being written and rewritten by different teams. It was some android demo thing, then the "education edition", and then by the time I was looking at it, it was now supposed to be their general cross platform engine.
mpanase@reddit
xD
You will find bugs you didn't know about... lose features you didn't know about, and add new bugs.
non3type@reddit
Refactoring small portions of a code base this can hold true but a complete rewrite, with a new language no less, can also end in new bugs depending on how radically the new implementation differs.
Different-Ad-8707@reddit
I consider the fish shell to be the best done re-write in Rust project, as far as I know.
It's a widely used program, that has new features being and maintenance done at a frequent pace, with neither of them being too adversely affected by and during the re-write.
TL-PuLSe@reddit
strangler fix
Able-Swing-6415@reddit
Yea especially when you think some code is nonsense until you remember why it was there to begin with.
I think John carmack or someone had a super weird piece of code that had the comment (I don't know what the fuck this does but if you change it everything breaks)
pheonixblade9@reddit
ugly code is very often bug fixes.
TL-PuLSe@reddit
That quote is top quality horseshit.
TheoreticalDumbass@reddit
you can also accidentally introduce bugs
deltanine99@reddit
And introduce a bunch of new bugs.
zombiecalypse@reddit
I feel that you will fix a lot of bugs and introduce a lot of others in any sufficiently complex rewrite. The article mentioned ways to avoid it, but otherwise I'd have my doubts if you'd end up with fewer bugs afterwards or just different ones.
sidonay@reddit
It can be the opposite if not done carefully. It should still be done though. It just isn't that linear that it will fix bugs you don't know about . It might, or it might add new ones. Sometimes when porting functionality to a new system, some edge cases are forgotten, and the accumulated insight from many years of code built into previous code base isn't properly considered. Partially due to haste and partially due to the legacy code itself sometimes being hard to understand.
bi-bingbongbongbing@reddit
I'm the guy they bring in when it's not done carefully. I hate being that guy. I need a new job.
matthieum@reddit
There's certainly a risk.
Do note, however, the mention of differential fuzzing in the article.
The great thing about differential fuzzing is that it surfaces the differences, without any opinion that one behavior is correct and the other is not -- in fact, in rare cases, both are not!
This really helps reducing the number of differences that sneak in, and as a bonus, it helps identifying real bugs in the current software during the development of the new one :)
sidonay@reddit
It‘s definitely possible to rewrite something and make it better in most metrics. But just the act of rewriting itself doesn’t guarantee it (the comment I’m replying to makes it seem that it’s a certain )
Kevin_Jim@reddit
What’s this quote from?
Psychological-Rub505@reddit
When it comes to large-scale refactoring, you fix many bugs while also introducing new ones.
Delicious_Praline850@reddit
True but Rust is more modern and developer friendly.
Still as a backend developer I have yet to find a good enough use case for rust.
ToaruBaka@reddit
If you can't find a good enough usecase for rust as a Backend developer you should find a new career.
menictagrib@reddit
Wild to get downvoted for this. Replace "rust" with "C++" and you have an only slightly more insane statement but because C++ is something of a standard and Rust is a new thing intended to (and widely lauded for its success in) improve on C++ especially for large, security-critical codebases, it is somehow reasonable to pretend Rust doesn't have nera ubiquitous utility.
MornwindShoma@reddit
Not a lot of people get how bloated are non-systems langs and how big the savings are in memory and CPU time. No, better waste users and company's money, and ship JavaScript fueled (or worse, Python) crap written as fast as possible and pay immense bills to AWS.
menictagrib@reddit
You're correct but we're talking about a backend dev saying they can't see a use case for Rust. The use case for Rust is everywhere C/C++ can be used, plus places where relying on every dev to always manage memory well is risky. It's also nice that it is designed to make it hard(er) to miss edge cases. That is to say, it's hard to see how a backend dev would struggle to find a use case for what is basically a drop-in replacement for most languages used for most backend development. And yes I understand ecosystem maturity and availability of skilled devs between different languages.
MornwindShoma@reddit
Agreed. Plus WASM being an amazing frontier for deploying software, and Rust is pretty good at that.
StengahBot@reddit
Why the fuck is this downvoted
Zasd180@reddit
They hate him because he spoke the truth
Imnotneeded@reddit
I should learn rust...
answerguru@reddit
So LOC is a metric that means it’s better now?
Hot-Employ-3399@reddit
> So LOC is a metric that means it’s better
Yes. The smaller code base is, the easier it's to reason about what it's doing.
> now
No. 1kLoC functions were considered garbage long before you were born.
jonatansan@reddit
I removed every new lines from my C++ code base. Now I have a single line of code!
__konrad@reddit
But how can you have two
#includein a single line?shotsallover@reddit
It’s like the old adage I learned years ago.
Every program can be reduced by at least one line. Every program has at least one bug in it. Therefore, every program can be reduced down to just one line, and that line is wrong.
Princess_Azula_@reddit
It's a python script that calls my C++ code from a library!
arwinda@reddit
More is better.
Which means the manager has to explain now why the number is lower, not higher in the end.
/s
NYPuppy@reddit (OP)
No, the article talks about why the rewrite is better. I mentioned the loc partly because I'm surprised the rust code is so much smaller while being better too.
Less code to maintain is always a good thing too. Writing more loc doesn't mean a solution is better, despite what elon musk thinks.
guepier@reddit
All other things being equal (which is a big if), less code to maintain absolutely does mean it’s better now, yes.
Heuristics@reddit
Now rewrite it back to C++ and it would be 70k
No_Potential9410@reddit
you’re funny
Heuristics@reddit
sure, it's a joke, but I also believe it to be true
NYPuppy@reddit (OP)
Then rewrite that back to rust so it's 50k.
I think you are on to something here!
YellowBunnyReddit@reddit
Then rewrite in Brainfuck and it's down to 1.
maxip89@reddit
Why? Not because something gets better, just because someone wants a promotion.
Normal thing at big tech companies.
UselessOptions@reddit
rust is... le good
c++ is... le bad
updoots to the left
mpaes98@reddit
The real question is, how many lines will it be once all the bugs and error handling from the refactor are done?
That said, LOC is a very dumb metric for scaled systems. Adding more lines can make code much more efficient.
mpanase@reddit
The actual title of the blg entry is:
Which is a sane and non-silly one.
OP did them dirty, changing the title to something stupid.
Honestly, it'd be nice for the sub to not allow this kind of manipulation.
alteresc@reddit
Rust: pushing all your vulnerabilities into a "not my fault" zone as a design pattern.
The_0bserver@reddit
And is it better or worse because of that?
Local_Nothing5730@reddit
I rather read an article of why their "media handler" has that many lines and if it includes dependencies
tangoshukudai@reddit
I’m sure if you refactored your C++ you could have also reduced the amounts of lines of code.
Individual-Trip-1447@reddit
So they reduced memory bugs and line count. Rust really said “less code, less regret.”
ArashPartow@reddit
Google did something similar several years ago, where they took a poorly written C++ component and rewrote in Go then claimed: Mission Complete!
NurUrl@reddit
NSA Favorite Backdoor written in rust.. so safe
ConstructionLost4861@reddit
gotta make sure that your backdoor never crash
Local_Nothing5730@reddit
How many LoC for dependencies?
morebob12@reddit
And the compression levels are still shit
the_ai_wizard@reddit
Be great if they rolled back their desktop app. Holy shit what a piece of garbage it is now.
Also on mobile android, image gallery doesnt properly load half the time when trying to share an image. Just reopen 3 or 4 times and eventually it works.
0/10 total shit quality
sarhoshamiral@reddit
Are we still doing lines of code metric? For all we know lines are less because "} else {" is now in one line instead of 3 separate lines in the previous code.
What stuck out for me was: "Two major hurdles were the initial binary size increase due to bringing in the Rust standard library". There is no discussing about the binary size afterwards.
Ultimately I agree that the security Rust brings is likely worth that binary size increase but when you focus on lines of code as the first mention, it kind of ruins rest of the article.
ArashPartow@reddit
Google did something similar a few years ago, where they took a poorly written C++ component, rewrote in Go then claimed: Mission Complete!
sorressean@reddit
Now when the media engine takes a shit people will just assume it's this shitty vibe-coded javascript desktop replacement. So much winning!
_dude_404@reddit
They should rewrite they security and make it actually end to end encrypted. This is just corporate propaganda to wash their image.