Live data from Hacker News

Matt Godbolt sold me on Rust by showing me C++

collabora.com

281–290 of 675 posts

Re: Matt Godbolt sold me on Rust by showing me C++

#281

Earlier quoted context omitted.

> Isn't this a runtime problem and not a compile-time problem? buy() or sell() is going to be called with dynamic parameters at runtime, in general. Yes, but the strength of Rust's type system means you're forced to handle those bad dynamic values up front (or get a crash, if you don't). That means the rest of your code can rest safe, knowing exactly what it's working with. You can see this in OP's parsing example, b…

What if the valid input for quantity must be greater than 0? A reasonable constraint, I think. The OP's example is contrived to line up with Rust's built-in types, and ignores the general problem.

It's a common fallacy to equate "there's a limit to how much we can guarantee" with "guaranteeing anything is a waste of time". Each guarantee we can make eliminates a whole class of possible bugs

That said, Rust also makes it very easy to define your own types that can only be constructed/unpacked in limited ways, which can enforce special constraints on their contents. And it has a cultural norm of doing this in the standard library and elsewhere

Eg: a sibling poster noted the NonZero type. Another example is that Rust's string types are guarantees to always contain valid UTF-8, because whenever you try and convert a byte array into a string, it gets checked and possibly rejected.

Re: Matt Godbolt sold me on Rust by showing me C++

#282

I already hated C++ (having written 100s of thousands of lines of it in games and at FAANG) I'd be curious to know what if any true fixes are coming down the line. This talk: "To Int or to Uint, This is the Question - Alex Dathskovsky - CppCon 2024" https://www.youtube.com/watch?v=pnaZ0x9Mmm0 Seems to make it clear C++ is just broken. That said, and I wish he'd covered this, he didn't mention if the flags he brings u…

There has been talk of new language frontends for C++:

Cpp2 (Herb Sutter's brainchild): https://hsutter.github.io/cppfront/

Carbon (from Google): https://github.com/carbon-language/carbon-lang

In principle those could enable a safe subset by default, which would (except when explicitly opted-out) provide similar safety guarantees to Rust, at least at the language level. It's still up to the community to design safe APIs around those features, even if the languages exist. Rust has a massive advantage here that the community built the ecosystem with safety in mind from day 1, so it's not just the language that's safe, but the APIs of various libraries are often designed in an abuse-resistant way. C++ is too much of a zoo to ever do that in a coherent way. And even if you wanted to, the "safe" variants are still in their infancy, so the foundations aren't there yet to build upon.

I don't know what chance Cpp2 or Carbon have, but I think you need something as radical as one of these options to ever stand a chance of meaningfully making C++ safer. Whether they'll take off (and before Rust eats the world) is anyone's guess.

Re: Matt Godbolt sold me on Rust by showing me C++

#283

The C++ code I write these days is actually pretty similar to Rust: everything is explicit, lots of strong types, very simple and clear lifetimes (arenas, pools), non-owning handles instead of pointers. The only difference in practice is that the build systems are different and that the Rust compiler is more helpful (both in catching bugs and reporting errors). Neither a huge deal if you have a proper build and testi…

The C++ code I wrote 20 years ago also had strong typing and clear lifetimes. Modern C++ has reduced a lot of typing through type inference, but otherwise the language is still strongly typed and essentially the same.

Unfortunely thanks to the "code C in C++ crowd", there is this urban myth that goodies like proper encapsulation, stronger types, RAII, were not even available in pre-C++98, aka C++ARM.

Meanwhile it was one of the reasons after Turbo Pascal, my next favourite programming language became C++.

For me mastering C, after 1992, only became mattered because as professional, that is something that occasionally I have to delve into so better know your tools even if the grip itself has sharp corners, otherwise everytime the option was constrained to either C or C++, I always pick C++.

Re: Matt Godbolt sold me on Rust by showing me C++

#284
post #76
post #54

Earlier quoted context omitted.

> -Wconversion ... assumes converting 1000.0 to 1000 is ok due to no loss in precision. Additionally, `clang-tidy` catches this via `bugprone-narrowing-conversions` and your linter will alert if properly configured.

My opinion is that if you need to run extra tools/linters in order to catch basic errors, the language & its compiler are not doing enough to protect me from correctness bugs. I do run clippy on my Rust projects, but that's a matter of style and readability, not correctness (for the most part!).

I beg to differ, the same reasoning applies to Rust, otherwise there would not be a clippy at all.

Re: Matt Godbolt sold me on Rust by showing me C++

#285
post #191

To be fair, this sort of thing doesn't have to be so much worse in C++ (yes, it would have been nice if it had been built into the language itself to begin with). You just need a function to do a back-and-forth conversion which then double-check the results, ie: #include #include template void convert_safely_helper_(From const& value, To& result) { std::stringstream sst; sst > result; } // Doesn't throw, just fails t…

Yes, from safety point of view Rust is much better option, however from the ecosystems I care about (language runtimes and GPU coding), both professionally and as hobby, C++ is the systems language to go, using Rust in such contexts would require me to introduce extra layers and do yak shaving instead of the actual problem that I want to code for.

Re: Matt Godbolt sold me on Rust by showing me C++

#287

I already hated C++ (having written 100s of thousands of lines of it in games and at FAANG) I'd be curious to know what if any true fixes are coming down the line. This talk: "To Int or to Uint, This is the Question - Alex Dathskovsky - CppCon 2024" https://www.youtube.com/watch?v=pnaZ0x9Mmm0 Seems to make it clear C++ is just broken. That said, and I wish he'd covered this, he didn't mention if the flags he brings u…

> 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 contain significant code. Of those 127,000 crates, 24,362 make use of the unsafe keyword, which is 19.11% of all crates. And 34.35% make a direct function call into another crate that uses the unsafe keyword. Nearly 20% of all crates have at least one instance of the unsafe keyword, a non-trivial number.

> Most of these Unsafe Rust uses are calls into existing third-party non-Rust language code or libraries, such as C or C++.

To be honest, I would have expected that 60% number to be higher if it were counting unsafe anywhere due to unsafe in the stdlib for vocabulary types and for (presumably) common operations like iterator chains. There's also a whole other argument that the hardware is unsafe so all Rust code will depend on unsafe somewhere or another to run on actual hardware, but that's probably getting a bit into the weeds.

[0]: https://github.com/rustfoundation/painter

[1]: https://rustfoundation.org/media/unsafe-rust-in-the-wild-not...

Re: Matt Godbolt sold me on Rust by showing me C++

#288

I already hated C++ (having written 100s of thousands of lines of it in games and at FAANG) I'd be curious to know what if any true fixes are coming down the line. This talk: "To Int or to Uint, This is the Question - Alex Dathskovsky - CppCon 2024" https://www.youtube.com/watch?v=pnaZ0x9Mmm0 Seems to make it clear C++ is just broken. That said, and I wish he'd covered this, he didn't mention if the flags he brings u…

There has been talk of new language frontends for C++: Cpp2 (Herb Sutter's brainchild): https://hsutter.github.io/cppfront/ Carbon (from Google): https://github.com/carbon-language/carbon-lang In principle those could enable a safe subset by default, which would (except when explicitly opted-out) provide similar safety guarantees to Rust, at least at the language level. It's still up to the community to design safe A…

I don't think Carbon is a C++ frontend like cppfront. My impression is that cppfront supports C++ interop by transpiling/compiling to C++, but Carbon compiles straight to LLVM and supports C++ interop through built-in language mechanisms.

Re: Matt Godbolt sold me on Rust by showing me C++

#289

The C++ code I write these days is actually pretty similar to Rust: everything is explicit, lots of strong types, very simple and clear lifetimes (arenas, pools), non-owning handles instead of pointers. The only difference in practice is that the build systems are different and that the Rust compiler is more helpful (both in catching bugs and reporting errors). Neither a huge deal if you have a proper build and testi…

I still find it basically impossible to get started with a C++ project. I tried again recently for a proxy I was writing thinking surely things have evolved at this point. Every single package manager couldn’t handle my very basic and very popular dependencies. I mean I tried every single one. This is completely insane to me. Not to mention just figuring out how to build it after that which was a massive headache and…

Felt the same pain with vcpkg. Ended up using OS packages and occasionally simply downloading a pure header based dependency.

With Nix, the package selection is great and repackaging is fairly straight forward.

Re: Matt Godbolt sold me on Rust by showing me C++

#290
post #258

This reminds me of SQL's constraints, or pydantic's custom types and validators, which can validate that a value should be an int, and between 0-999, and not exceed, e.g. -1 or 1000. pydantic is a library for python, but I'm not aware of anything similar in rust or golang that can do this yet? (i.e. not just schema validation, but value range validation too)

[dead]
Post reply on HN