Dunno about this, the example C++ code is so obviously bad that I had no desire to watch the video.
Creating strong types for currency seems like common sense, and isn't hard to do. Even the Rust code shouldn't be using basic types.
Matt Godbolt sold me on Rust by showing me C++
341–350 of 675 posts
Re: Matt Godbolt sold me on Rust by showing me C++
#342I always enjoy reading articles like this. But the truth is, having written several 100s of KLOC in C++ (i.e., not an enormous amount but certainly my fair share) I just almost never have problems with this sort accidental conversion in practice. Perhaps it might trip me up occasionally, but will be noticed by literally just running the code once. Yes, that is an extra hurdle to trip over and resolve but that is trivial compared to the alternative of creating and using wrapper types - regardless of whether I'm using Rust or C++. And the cost of visual noise of wrapper types, already higher just at the writing stage, then continues to be a cost every time you read the code. It's just not worth it for the very minor benefit it brings.
(Named parameters would definitely be great, though. I use little structs of parameters where I think that's useful, and set their members one line at a time.)
I know that this is an extremist view, but: I feel the same way about Rust's borrow checker. I just very rarely have problems with memory errors in C++ code bases with a little thought applied to lifetimes and use of smart pointers. Certainly, lifetime bugs are massively overshadowed by logic and algorithmic bugs. Why would I want to totally reshape the way that I code in order to fix one of the least significant problems I encounter? I actually wish there were a variant of Rust with all its nice clean improvements over C++ except for lifetime annotations and the borrow checker.
Perhaps this is a symptom of the code I tend to write: code that has a lot of tricky mathematical algorithms in it, rather than just "plumbing" data between different sources. But actually I doubt it, so I'm surprised this isn't a more common view.
Re: Matt Godbolt sold me on Rust by showing me C++
#343Earlier quoted context omitted.
> speaking of which, according to another C++ talk, something like 60% of rust crates are dependent on unsafe rust. It's probably not the source of the stats you had in mind since it's discussing something slightly different, but the Rust Foundation built a tool called Painter [0] for this kind of analysis. According to that [1]: > As of May 2024, there are about 145,000 crates; of which, approximately 127,000 contai…
Memory allocation is unsafe, so any container in the stdlib end up using unsafe at some point. This does not mean that safe Rust is useless without unsafe - the utility of Rust is that it allows one to create sage interfaces around an unsafe construct.
Right, I totally agree. I suppose I was kind of trying to express a bit of confusion at the 60% number due to the lack of specifics of what it encompasses (e.g., how far down the dependency chain is that number looking?), unlike the stats I quoted.
Re: Matt Godbolt sold me on Rust by showing me C++
#344I always enjoy reading articles like this. But the truth is, having written several 100s of KLOC in C++ (i.e., not an enormous amount but certainly my fair share) I just almost never have problems with this sort accidental conversion in practice. Perhaps it might trip me up occasionally, but will be noticed by literally just running the code once. Yes, that is an extra hurdle to trip over and resolve but that is triv…
> Why would I want to totally reshape the way that I code in order to fix one of the least significant problems I encounter?
I feel the same. Rust certainly has many nice properties and features, but the borrow checker is a huge turn-off for me.
Re: Matt Godbolt sold me on Rust by showing me C++
#345I see an article about how strict typing is better, but what would really be nice here is named parameters. I never want to go back to anonymous parameters.
Yes, this is one of the few things that I think was a big mistake in Rust's language design. I used to do a lot of Scala, and really liked named parameters there. I suppose it could still be added in the future; there are probably several syntax options that would be fully backward-compatible, without even needing a new Rust edition.
I suppose the sense it is backwards incompatible is that library authors have named their parameters without intended to make them part of the public interface that they commit to maintaining. Perhaps it could be made backwards compatible by being opt in function declarations but that would seem like a bit of a pain.
Re: Matt Godbolt sold me on Rust by showing me C++
#346Earlier quoted context omitted.
I like so much about Rust. But I hear compiling is too slow. Is it a serious problem in practice?
Absolutely, the compile times are the biggest drawback IMO. Everywhere I've been that built large systems in Rust eventually ends up spending a good amount of dev time trying to get CI/CD pipeline times to something sane. Besides developer productivity it can be an issue when you need a critical fix to go out quickly and your pipelines take 60+ minutes.
We have 60 minutes deploy pipelines and are in python. Just mentioning that since, in theory, we are not penalized for long compile times.
Fast ability to quickly test and get feedback is mana from the gods in software development. Organizations should keep it right below customer satisfaction and growth as a driving metric.
Re: Matt Godbolt sold me on Rust by showing me C++
#347Earlier quoted context omitted.
Because cpp is not meant for "rapid prototyping" involving importing half of github with single command. And the reality is that it works.
Works for whom? C++ build systems are notoriously brittle. When porting a project to a new platform, you're never just porting the code, you are also porting your build system. Every single project is bespoke in some way, sometimes because of taste, but most of the time because of necessity. It works because people spend a huge amount of time to make it work.
This seems hyperbolic. At work we cross compile the same code for a decent number of different platform - six different OS (Linux Mac windows and some embedded ones) over 20odd cpu architectures.
It’s the same build system for all of them.
Re: Matt Godbolt sold me on Rust by showing me C++
#348I always enjoy reading articles like this. But the truth is, having written several 100s of KLOC in C++ (i.e., not an enormous amount but certainly my fair share) I just almost never have problems with this sort accidental conversion in practice. Perhaps it might trip me up occasionally, but will be noticed by literally just running the code once. Yes, that is an extra hurdle to trip over and resolve but that is triv…
> but will be noticed by literally just running the code once.
I assure you that's not the case. Maybe you didn't make that mistake, but if you did I'm sure it sometimes went unnoticed. I've found those issues in my code and in other projects. Sometimes they even temporarily don't matter, because someone did a func(CONST, 0) instead of func(0, CONST) and it turns out CONST is 0 - however the next person gets a crash because they change 0 to 1. A lot of similar issues come from the last line effect https://medium.com/@Code_Analysis/the-last-line-effect-7b1cb... and can last for years without being noticed.
Re: Matt Godbolt sold me on Rust by showing me C++
#349Types are a catastrophe in C++ that cannot be fixed, no matter how much cruft you bolt on after the fact. It's time to leave this dinosaur and use a sane language.
Re: Matt Godbolt sold me on Rust by showing me C++
#350I always enjoy reading articles like this. But the truth is, having written several 100s of KLOC in C++ (i.e., not an enormous amount but certainly my fair share) I just almost never have problems with this sort accidental conversion in practice. Perhaps it might trip me up occasionally, but will be noticed by literally just running the code once. Yes, that is an extra hurdle to trip over and resolve but that is triv…
> I just almost never have problems with this sort accidental conversion in practice.
95% of C++ programmers claim this, but C++ programs continue to be full of bugs, and they're usually exactly this kind of dumb bug.
> will be noticed by literally just running the code once.
Maybe. If what you're doing is "tricky mathematical algorithms", how would you even know if you were making these mistakes and not noticing them?
> the cost of visual noise of wrapper types, already higher just at the writing stage, then continues to be a cost every time you read the code. It's just not worth it for the very minor benefit it brings.
I find wrapper types are not a cost but a benefit for readability. They make it so much easier to see what's going on. Often you can read a function's prototype and immediately know what it does.
> Certainly, lifetime bugs are massively overshadowed by logic and algorithmic bugs.
Everyone claims this, but the best available research shows exactly the opposite, at least when it comes to security bugs (which in most domains - perhaps not yours - are vastly more costly): the most common bugs are still the really dumb ones, null pointer dereferences, array out of bounds, and double frees.