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

Post by selfmodruntime » Wed, May 07, 2025, 11:35 AM UTC

kelnos wrote: post #67

zozbot234 wrote: post #40

Earlier quoted context omitted.

> The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions This isn't really true since Rust has panics. It would be nice to have out-of-the-box support for a "no panics" subset of Rust, which would also make it easier to properly support linear (no auto-drop) types.

I wish more people (and crate authors) would treat panic!() as it really should be treated: only for absolutely unrecoverable errors that indicate that some sort of state is corrupted and that continuing wouldn't be safe from a data- or program-integrity perspective. Even then, though, I do see a need to catch panics in some situations: if I'm writing some sort of API or web service, and there's some inconsistency in…

Post by selfmodruntime » Wed, May 07, 2025, 11:36 AM UTC

kbolino wrote: post #118

zozbot234 wrote: post #44

Earlier quoted context omitted.

That's a neat hack, but it would be a lot nicer to have explicit support as part of the language.

That's going to be difficult because the language itself requires panic support to properly implement indexing, slicing, and integer division. There are checked methods that can be used instead, but to truly eliminate panics, the ordinary operators would have to be banned when used with non-const arguments, and this restriction would have to propagate to all dependencies as well.

Post by nosefrog » Wed, May 07, 2025, 11:41 AM UTC

simiones wrote: post #403

monkeyelite wrote: post #384

Earlier quoted context omitted.

> You're giving up scalability massively you’re vastly over estimating the overhead of processes and number of simultaneous web connections. > only to gain a minor amount of safety What you’re telling me is performance (memory?) is such a high priority you’re willing to make correctness and security tradeoffs. And I’m saying thats ok, one of those is crashing might bring down more than one request. > one that is virt…

Please find one web server being actively developed using one process per request. Handling thousands of concurrent requests is table stakes for a simple web server. Handling thousands of concurrent processes is beyond most OSs. The context switching overhead alone would consume much of the CPU of the system. Even hundreds of processes will mean a good fraction of the CPU being spent solely on context switching - whi…

Post by tomp » Wed, May 07, 2025, 11:53 AM UTC

dvratil wrote: post #8

The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking r…

Post by jeroenhd » Wed, May 07, 2025, 11:59 AM UTC

nerpaskteipntei wrote: post #378

roelschroeven wrote: post #194

Earlier quoted context omitted.

The numeric conversion functions in the STL are terrible. They will happily accept strings with non-numeric characters in them: they will convert "123abc" to 123 without giving an error. The std::sto* functions will also ignore leading whitespace. Yes, you can ask the std::sto* functions for the position where they stopped because of invalid characters and see if that position is the end of the string, but that is mu…

Now there is also std::from_chars function

    if let Ok(x) = input.parse::() {
         println!("You entered {x}");
    } else {
        eprintln!("You did not enter a number");
    }

     int x{};
     auto [ptr, ec] = std::from_chars(input.data(), input.data() + input.size(), x);
     if (ec == std::errc() && ptr == input.data() + input.size()) { 
         std::cout