Live data from Hacker News

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

collabora.com

541–550 of 675 posts

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

#541
post #311

Earlier quoted context omitted.

This only really applies to languages that don't check this at compile-time. I don't consider compile-time errors a foot gun. I mean, it should be impossible for that kind of bad code to ever get merged in most reasonable CI/CD processes.

No? This happens in any language that has keyword args. If I delete/rename a field of a class in any statically checked language, it's going to report a compile error, and it's still a breaking change. Same thing with named arguments.

Sure, but it doesn't actually matter because this can't ever manifest as a bug. Your PR will just be rejected, which to me, is correct behavior.

Typically when you're changing a name you're changing behavior, too. This isn't just something we should let slip under the radar, otherwise bugs can actually manifest.

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

#542

Earlier quoted context omitted.

Package managers per language are a (relatively) new endeavor. The oldest language I can think of that widely adopted it was Perl. Although, perl was quite ahead of it's time in a lot of ways, and php undid some the work of perl and went back to popularizing include type dependencies instead of formal modules with a package manager. C++ "gets away" with it because of templates. Many (most?) libraries are mostly templ…

It's a relatively new endeavor, but it's also a requirement in 2025 if you want to be portable. The Linux ecosystem was focusing on installing dependencies system-wide for decades (that's how traditional `./configure.sh` expects things to work), and this approach is just inferior in so many ways. The shenanigans people get into with CMake, Conan, vcpkg, and so on is a patchwork of nightmares and a huge time sink comp…

I don't think it's a requirement and it does actually come with it's own set of foot guns. The problem is that these design decisions impact culture, which is why JS has a culture of importing far too many third-party packages. Which comes with it's own set of risks.

I agree overall that the C or C++ way of doing things is more cumbersome, but I don't think that's enough to write off those languages as a whole.

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

#543
post #520

Earlier quoted context omitted.

I cannot follow your rant... I'll do my best to respond, but I'm probably not understanding something. Divide by zero must be undefined behavior in any performant language. On x86 you either have a if before running the divide (which of course in some cases the compiler can optimize out, but only if it can determine the value is not zero); or you the CPU will trap into the OS - different OSes handle this in different…

> Divide by zero must be undefined behavior in any performant language. On x86 you either have a if before running the divide (which of course in some cases the compiler can optimize out, but only if it can determine the value is not zero); or you the CPU will trap into the OS - different OSes handle this in different ways, but most not in a while that makes it possible to figure out where you were and thus do someth…

> What if you really do need "unsafe" division? Well, that is possible, with unchecked_div. Most people do not need unchecked_div. If you think you do but you haven't benchmarked yet, you do not. It doesn't get any simpler than that.

This attitude is why modern software is dogshit slow. People make this "if you haven't benchmarked, it doesn't matter" argument thousands of times and the result is that every program I run is slower than molasses in Siberia. I don't care about "safety" at the expense of performance.

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

#544

Earlier quoted context omitted.

I worked in the chromium C++ source tree for years and compiling there was orders of magnitude slower than any Rust source tree I've worked in so far. Granted, there aren't any Rust projects that large yet, but I feel like compilation speeds are something that can be worked around with tooling (distributed build farms, etc.). C++'s lack of safety and a proclivity for "use after free" errors is harder to fix.

Are there rust projects that are within orders of magnitude of Chromium?

Almost a quarter of Firefox' compiled code is Rust: https://4e6.github.io/firefox-lang-stats/

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

#545
post #535
post #417

Earlier quoted context omitted.

Did you ever actually program in Rust? In my experience, a lot of the code is dedicated to "correctly transforming between different Result / Error types". Much more verbose than exceptions, despite most of the time pretending they're just exceptions (i.e. the `?` operator). Why not just implement exceptions instead? (TBH I fully expect this comment to be downvoted, then Rust to implement exceptions in 10 years... So…

I've only worked in exceptions, so I can't really comprehend the book-keeping required without them. To me it's a separation of concerns: the happy path only involves happy code. The "side channel" for the unhappy path is an exception, with an exception handler at a layer of the abstraction where it's meaningful, yet happy, code. By "happy" I mean code that's simply the direct practical work that's trying to accompli…

In places where you only want to pass an error to the caller, Rust lets you just add "?" to the call that returns a Result/Option. And the Rust compiler will check that every potential error is handled.

I wouldn't say that it's the tedious part of the language.

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

#546
post #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.

Well, precisely. Such is the price of "general-purpose safety". The biggest irony IMO is that the security features of Rust are so often skirted in the name of speed, efficiency, etc, with the end result being a program which isn't much more secure than its C++ equivalent. ¯\_(ツ)_/¯

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

#547
post #530

Earlier quoted context omitted.

> Handling thousands of concurrent processes is beyond most OS It works fine on Linux - the operating system for the internet. Have you tried it? > good fraction of the CPU being spent solely on context switching I was waiting for this one. Threads and processes do the same amount of context switching. The overhead of processes switch is a little higher. The main cost is memory.

> Threads and processes do the same amount of context switching. Yes, therefore real webservers use a limited amount of threads/processes (in the same ballpark as a number of CPU cores). Modern approach is to use green threads which are really cheap to switch, it is like store registers, read registers and jmp. > The main cost is memory. The main cost is scheduling, not switching per se. Preemptive multitasking needs…

> The main cost is scheduling, not switching per se. Preemptive multitasking needs to deal with priorities to not waste time, and algorithms that do it

The person I am having a conversation with is advocating for threads instead of processes. How do you think threads work?

> Modern approach is to use green threads which are really cheap to switch, it is like store registers, read registers and jmp.

That’s certainly the popular approach. As I said at the beginning this approach is making a mini operating system with more bugs and less security rather than leveraging the capabilities of your operating system.

Once again, im waiting to here about your experience of maxing out processes and after that having to switch to green threads.

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

#548
post #535
post #417

Earlier quoted context omitted.

Did you ever actually program in Rust? In my experience, a lot of the code is dedicated to "correctly transforming between different Result / Error types". Much more verbose than exceptions, despite most of the time pretending they're just exceptions (i.e. the `?` operator). Why not just implement exceptions instead? (TBH I fully expect this comment to be downvoted, then Rust to implement exceptions in 10 years... So…

I've only worked in exceptions, so I can't really comprehend the book-keeping required without them. To me it's a separation of concerns: the happy path only involves happy code. The "side channel" for the unhappy path is an exception, with an exception handler at a layer of the abstraction where it's meaningful, yet happy, code. By "happy" I mean code that's simply the direct practical work that's trying to accompli…

There's mostly drawback of having exceptions, I'm not really aware of any benefits of not having them.

People often complain about:

- performance impact, either speed (most languages) or binary size (C++); this, however, is mostly an implementation concern, and doesn't impact Rust at all, as exceptions can simply be syntax-level compiler sugar, and can be compiled exactly the same as Result type is currently (having said that, the optional stack trace is another potential issue, which would have a performance impact even in Rust)

- checked exceptions - this is particularly a concern in Java, which has a fairly poor type system (closed subtyping only) and no type inference, so declaring all unhandled exceptions is tedious

- non-checked exceptions - in this case, "every exception can happen anywhere" so it's ostensibly unsafe (well it's just how life is, and even Java has special unchecked exceptions such as OutOfMemory that can happen anywhere) - some people claim that "exceptions can't just randomly jump out of code" is a benefit of not having exceptions but usually those people sweep OutOfMemory and DivisionByZero under the rug (e.g. Rust, where they just "crash" the program)

Rust would obviously fit the checked exceptions path, as the Result implementatoin basically is "poor-man's checked exceptions". It only needs to flip the syntax sugar - propagate by default (and implicitly), "catch" and materialize using `?` - as well as making Error an open enum (such that you can add cases implicitly - see e.g. OCaml's exception type `exn` [1]) - and that's basically it!

[1] https://ocaml.org/manual/5.3/extensiblevariants.html

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

#549
post #520

Earlier quoted context omitted.

> Divide by zero must be undefined behavior in any performant language. On x86 you either have a if before running the divide (which of course in some cases the compiler can optimize out, but only if it can determine the value is not zero); or you the CPU will trap into the OS - different OSes handle this in different ways, but most not in a while that makes it possible to figure out where you were and thus do someth…

> What if you really do need "unsafe" division? Well, that is possible, with unchecked_div. Most people do not need unchecked_div. If you think you do but you haven't benchmarked yet, you do not. It doesn't get any simpler than that. This attitude is why modern software is dogshit slow. People make this "if you haven't benchmarked, it doesn't matter" argument thousands of times and the result is that every program I…

> This attitude is why modern software is dogshit slow.

Bullshit. Here's my proof: We don't even do this. There's a ton of software that isn't safe from undefined behavior and it's still slow as shit.

> People make this "if you haven't benchmarked, it doesn't matter" argument thousands of times and the result is that every program I run is slower than molasses in Siberia. I don't care about "safety" at the expense of performance.

If you can't imagine a world where there's nuance between "we should occasionally eat 0.5-1ns on checking an unsafe division" and "We should ship an entire web browser with every text editor and chat app" the problem is with you. If you want your software to be fast, it has to be benchmarked, just like if you want it to be stable, it has to be tested. There's really no exceptions here, you can't just guess these things.

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

#550

Earlier quoted context omitted.

A lot of people using C++ don't actually use any libraries. I've observed the opposite with Rust. People choose C++ because it's a flexible language that lets you do whatever you want. Meanwhile Rust is a constrained and opinionated thing that only works if you do things "the right way".

> People choose C++ because it's a flexible language that lets you do whatever you want. You went on a bit too long. C++ lets you do whatever. Whether you wanted that is not its concern. That's handily illustrated in Matt Godbolt's talk - you provided a floating point value but that's inappropriate? Whatever. Negative values for unsigned? Whatever. This has terrible ergonomics and the consequences were entirely predi…

It's just strong typing. You can do it in C++ too.
Post reply on HN