Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Rust faster than C?

steveklabnik.com

Post reply on HN
Print view View original

361–370 of 402 posts

Re: Is Rust faster than C?

#361

Post by estebank »

johnisgood wrote: post #328
Lorkki wrote: post #326

Earlier quoted context omitted.

> library quality and algorithm choice And especially having performant and actively maintained default choices built in. With C, as described in the post you responded to, you'll typically end up building a personal collection of dusty old libraries that work well enough for most of the time.

I think Rust projects will accumulate their own cruft over time, they are just younger. And the Rust ecosystem's churn (constant breakage, edition migrations, dependency hell in Cargo.lock) creates its own class of problems. Either way, I would like to reiterate that the comparison is flawed at a more fundamental level because hash tables and B-trees are different data structures with different performance characteri…

> constant breakage

Can you mention 3 cases of breakage the language has had in the last, let's say, 5 years? I've had colleagues in different companies responsible for updating company-wide language toolchains tell me that in their experience updating Rust was the easiest of their bunch.

> edition migrations

One can write Rust 2015 code today and have access to pretty much every feature from the latest version. Upgrading editions (at your leisure) can be done most of the time just by using rustfix, but even if done by hand, the idea that they are onerous is overstating their effect.

Last time I checked there were > dependency hell in Cargo.lock

Could you elaborate on what you mean?

Re: Is Rust faster than C?

#362

Post by estebank »

pjmlp wrote: post #301
jenadine wrote: post #292

Earlier quoted context omitted.

> There are lots of C++ UI applications. Is there? UI applications historically used to be written in C++. But in this decade, I don't think many new GUI are being written in C++

Games are, anything based on Qt/KDE, UWP/WinUI (even if it is mostly Microsoft employees). Now even if it is Flutter, React Native, or Chrome/Electron, they are powered by C++ graphics engine, and language runtimes.

The engine being written in C++ does not mean the application is. You're conflating the platform with what is being built on top of it. Your logic would mean that all Python applications should be counted as C applications.

Re: Is Rust faster than C?

#363

Post by superkuh »

junon wrote: post #331
superkuh wrote: post #188

As long as you can get the Rust code to compile it's about the same speed. The issue is that rustc is only available on limited platforms (and indeed lack of rustc has killed off entire hardware architectures in popular distros in a bit of tail wagging the dog), rustc changes in breaking ways (adding new features) every 3 months, current rust culture is all bleeding edge types so any rust code you encounter in the wi…

I've never run into this issue in the wild. It sounds like a hypothetical. Upgrading your Rust toolchain is ridiculously easy, and using a year old outdated toolchain is more or less a philosophical hang up than a technical one.

It's not a hypothetical. I was put off the entire language after it happened to me three times in a row with unrelated Rust written software. This was 1 month after Debian 12 was released (June 10, 2023) and I was running the brand new Debian 12 with rustc 1.63.0 from August 11, 2022. I ran into it with some web serial spidering and epub creation rust software (rust-wildbow-scraper). I ran into with a software defined radio spectrogram visualizer (plotsweep); I actually knew the author from IRC and he was able to edit it to not use bleeding edge rustc features and I managed to compile it. I can't recall the third. In the years since when I've stepped my toes into the "compile random rust programs with repo rust toolchain" and it's been the same.

But as you can see from my specific examples and dates: this is not a hypothetical. rust developer culture basically only writes for latest, having a 1 year old rustc is definitely not enough, and yes, installing compilers from a random website (curl site|sh) instead of my distro's repos is a problem.

Just because it hasn't happened to you doesn't mean it isn't a problem. Rust is a rolling release only compiler.

Re: Is Rust faster than C?

#364

Post by johnisgood »

steveklabnik wrote: post #345
johnisgood wrote: post #332

Earlier quoted context omitted.

Hmm. "Fearless concurrency" and the flagship examples are... background threads for search and not freezing the UI? That is GUI programming 101 from the Win32 era. Every Tcl/Tk app, every GTK app, every Qt app has been doing this for 25+ years. If Rust's concurrency story were genuinely revolutionary, you would expect examples like: - Lock-free data structures that are actually hard to get right - Complex parallel al…

When a basic question is asked, a basic answer is given. I didn’t say that I think that’s the coolest or most interesting answer. It’s just the most obvious, straightforward one. It’s not even about Rust! (And also, I don’t think things like work stealing queues are relevant to editors, but maybe that’s my own ignorance.)

You cannot have it both ways though. Either these are meaningful examples of Rust's benefits, or they are not worth mentioning.

In a thread about Rust's concurrency advantages, these editors were cited as examples. "Don't block the UI thread" as justification only works if Rust actually provides something novel here. If it is just basic threading that every language has done for decades, it should not have been brought up as evidence in the first place.

Plus if things like work-stealing queues and complex synchronization are not relevant to editors, then editors are a poor example for demonstrating Rust's concurrency story in the first place anyway.

Re: Is Rust faster than C?

#365

Post by pjmlp »

estebank wrote: post #362
pjmlp wrote: post #301

Earlier quoted context omitted.

Games are, anything based on Qt/KDE, UWP/WinUI (even if it is mostly Microsoft employees). Now even if it is Flutter, React Native, or Chrome/Electron, they are powered by C++ graphics engine, and language runtimes.

The engine being written in C++ does not mean the application is. You're conflating the platform with what is being built on top of it. Your logic would mean that all Python applications should be counted as C applications.

Indeed too many fake Python libraries.

Re: Is Rust faster than C?

#366

Post by Maxatar »

Seattle3503 wrote: post #273
bfrog wrote: post #156

Earlier quoted context omitted.

C++ you either use templates or classes and virtuals. In either case the caller doesn't get to decide.

Interesting, there isn't some way to have a template that is polymorphic over virtuals?

In C++ you do it the other way around, have a single class that is polymorphic over templates. The name of this technique within C++ is type-erasure (that term means something else outside of C++).

Examples of type erasure in C++ are classes like std::function and std::any, and normally you need to implement the type erasure manually, but there are some library that can automate it to a degree, such as [1], but it's fairly clumsy.

[1] https://www.boost.org/doc/libs/latest/doc/html/boost_typeera...

Re: Is Rust faster than C?

#368

Post by seanw444 »

I think the "social factors" section is the most significant. I've heard plenty of anecdotes of people stating that they "code defensively" in C, because it's too easy to mess things up. Whereas with a language such as Rust, you're able to be more aggressive in your optimizations without feeling like you're walking through a minefield unassisted. The end result is that the language with more constraints lets you be more safely free in your implementation.

Re: Is Rust faster than C?

#369

Post by junon »

superkuh wrote: post #363
junon wrote: post #331

Earlier quoted context omitted.

I've never run into this issue in the wild. It sounds like a hypothetical. Upgrading your Rust toolchain is ridiculously easy, and using a year old outdated toolchain is more or less a philosophical hang up than a technical one.

It's not a hypothetical. I was put off the entire language after it happened to me three times in a row with unrelated Rust written software. This was 1 month after Debian 12 was released (June 10, 2023) and I was running the brand new Debian 12 with rustc 1.63.0 from August 11, 2022. I ran into it with some web serial spidering and epub creation rust software (rust-wildbow-scraper). I ran into with a software define…

No, it's not. Your own misunderstandings of rust stable vs nightly and editions and using an unofficial installation method for a toolchain are not Rust's shortcomings. Sorry.

Re: Is Rust faster than C?

#370

Post by pjmlp »

seanw444 wrote: post #367
pjmlp wrote: post #305

Earlier quoted context omitted.

Yet it is one in itself, otherwise UNIX would still be written in Assembly.

Assembly itself is an abstraction. UNIX should have been written in machine code.

It was until version 4, when the C rewrite took place as it wasn't fun to keep writing it in Assembly.
Post reply on HN