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

Why you should, actually, rewrite some of it in Rust

unhandledexpression.com

Post reply on HN
Print view View original

291–300 of 300 posts

Re: Why you should, actually, rewrite some of it in Rust

#291

Post by Jweb_Guru »

_dcwr wrote: post #242
thephyber wrote: post #218

Earlier quoted context omitted.

> all these FUBAR C/C++ systems (...) work well enough to transfer that kind of garbage to me I don't think you read the article. The author specifically cites lots of different types of hyperbolic "rewrite everything in Rust!" arguments and explains how this article is not that and he doesn't advocate for that. The author of the article advocates "surgically replace weaker parts but keep most of the project intact."…

The garbage I was referring to was in the comments "below". Namely: "Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly" and "writing C++ code longer than a few lines without UB is humanly impossible", not the article, I quoted the latter shorter one in my original message. I consider Java browser applets unsafe trash an…

Did you read the linked article about UB? The odds that a random C++ program trips up some of that UB are actually pretty high, and all of the programs you've mentioned do have UB (Linus has infamously gotten angry about GCC starting to exploit it). It's just a question of whether a compiler (or hacker) is bothering to exploit it yet.

Re: Why you should, actually, rewrite some of it in Rust

#292

Post by youdontknowtho »

dikaiosune wrote: post #93
youdontknowtho wrote: post #87

"Rewrite it in Rust" is the new "Stallman was right" thread. Its an echo chamber of fandom. Over time I've come to despise "evangelism" or any kind. I'm sure Rust is great. I just don't think it's news every time a Rust fan says that its great. YouTube lectures of people actually using it? That would be interesting. Interviews of people actively porting a large C project to Rust. That would be interesting. Rehashing…

The author is actually using it, to actually rewrite portions of C projects in it, and writing about their experience doing this in practice. For example, the linked paper is about using Rust at the I/O boundary in an existing, complex system.

Except that the article is actually just the feature sheet of Rust. I would rather the article had been a link to that paper.

Re: Why you should, actually, rewrite some of it in Rust

#293

Post by rbehrends »

steveklabnik wrote: post #286
naasking wrote: post #281

Earlier quoted context omitted.

> If the problem requires a certain amount of overhead, than an implementation of that solution is considered zero-cost. Rust can't change the laws of math. His contention is that languages with GC don't require reference count updates, and so manipulating the BDD graph is much cheaper in these languages since the resource accounting overhead is deferred by some non-deterministic time.

You can still write a GC in Rust and use it for those types.

First, "you can write a GC" in Rust is not seriously an answer. You can't do it without unsafe code, it would be a lot of effort to just purposely avoid using a GCed language. And the existing efforts to do a GC in Rust are very simple mark-sweep designs that (unsurprisingly) don't even support generational collection.

Second, the reason why I use the BDD example (or, more generally, persistent data structures) is that it's the simplest way for online discussions, because (unlike simpler examples), it's not amenable to pseudo-solutions that don't resolve the underlying problem and that you don't have the space and time for.

The underlying problem is that Rust doesn't really do safe zero-cost abstractions for multiple ownership, and multiple ownership crops up more often in actual Rust code than people like to admit (global caches and memoization often end up with using cloning). You have to deal with it either through Rc, Arc, or cloning, of which cloning is the most common solution, because you don't have the footprints of shared ownership all over your code.

Re: Why you should, actually, rewrite some of it in Rust

#294

Post by rbehrends »

naasking wrote: post #281
steveklabnik wrote: post #274

Earlier quoted context omitted.

> BDDs inherently require Rc /Arc "Zero-cost abstraction" means "You couldn't have coded it any better yourself." If the problem requires a certain amount of overhead, than an implementation of that solution is considered zero-cost. Rust can't change the laws of math. Maybe Bjarne should have called it the "Zero additional-cost abstraction" instead; I think it'd clear the principle up a lot.

> If the problem requires a certain amount of overhead, than an implementation of that solution is considered zero-cost. Rust can't change the laws of math. His contention is that languages with GC don't require reference count updates, and so manipulating the BDD graph is much cheaper in these languages since the resource accounting overhead is deferred by some non-deterministic time.

> His contention is that languages with GC don't require reference count updates, and so manipulating the BDD graph is much cheaper in these languages since the resource accounting overhead is deferred by some non-deterministic time.

To be clear, the "contention" is the well-known problem that reference counting (especially atomic reference counting) is one of the most expensive automatic memory management techniques in existence, and it takes pretty significant efforts to get it on par with a modern tracing collector. That's because reference counting has high overhead and poor cache locality (as it comes with a built-in pointer chasing requirement even when you assign a reference).

That the cost is deferred has nothing to do with it.

Re: Why you should, actually, rewrite some of it in Rust

#295

Post by steveklabnik »

rbehrends wrote: post #293
steveklabnik wrote: post #286

Earlier quoted context omitted.

You can still write a GC in Rust and use it for those types.

First, "you can write a GC" in Rust is not seriously an answer. You can't do it without unsafe code, it would be a lot of effort to just purposely avoid using a GCed language. And the existing efforts to do a GC in Rust are very simple mark-sweep designs that (unsurprisingly) don't even support generational collection. Second, the reason why I use the BDD example (or, more generally, persistent data structures) is th…

Have you seen crossbeam? That's not mark and sweep.

As I said elsewhere, your definition of "zero cost abstractions" differs from what the term means.

Re: Why you should, actually, rewrite some of it in Rust

#296

Post by rbehrends »

steveklabnik wrote: post #295
rbehrends wrote: post #293

Earlier quoted context omitted.

First, "you can write a GC" in Rust is not seriously an answer. You can't do it without unsafe code, it would be a lot of effort to just purposely avoid using a GCed language. And the existing efforts to do a GC in Rust are very simple mark-sweep designs that (unsurprisingly) don't even support generational collection. Second, the reason why I use the BDD example (or, more generally, persistent data structures) is th…

Have you seen crossbeam? That's not mark and sweep. As I said elsewhere, your definition of "zero cost abstractions" differs from what the term means.

I know about crossbeam vaguely (mostly because the non-blocking concurrency is of interest to my research), but due to lack of documentation, haven't really dug into it and am not even sure what it has to do with GC?

> As I said elsewhere, your definition of "zero cost abstractions" differs from what the term means.

I'm going by Stroustrup's definition [1]? If your argument is – I'm not sure here – that "Rust gets zero-cost abstractions by limiting what you can do to beat its normal mechanisms", then that's not terribly convincing. What it boils down to is that multiple ownership is a weak spot of Rust, as for other languages that attempt the compile-time memory management thing, such as ParaSail. TANSTAAFL, "There ain't no such thing as a free lunch." No compile-time mechanism can solve the reachability problem for arbitrary runtime graphs without adding some overhead somewhere. Rust does zero overhead for certain kinds of graphs, but still needs overhead for others.

[1] http://www.stroustrup.com/ETAPS-corrected-draft.pdf

Re: Why you should, actually, rewrite some of it in Rust

#297

Post by steveklabnik »

rbehrends wrote: post #296
steveklabnik wrote: post #295

Earlier quoted context omitted.

Have you seen crossbeam? That's not mark and sweep. As I said elsewhere, your definition of "zero cost abstractions" differs from what the term means.

I know about crossbeam vaguely (mostly because the non-blocking concurrency is of interest to my research), but due to lack of documentation, haven't really dug into it and am not even sure what it has to do with GC? > As I said elsewhere, your definition of "zero cost abstractions" differs from what the term means. I'm going by Stroustrup's definition [1]? If your argument is – I'm not sure here – that "Rust gets ze…

Crossbeam's epoch based collection is basically a form of GC, for certain kinds of data structures.

Yeah Bjane's definition doesn't say "no overhead", it says "no extra overhead." If your data structure requires a GC, then writing a GC for it is a zero-overhead abstraction. What I'm saying is "gotcha, you need some runtime support for this" is not contradictory to zero-cost abstractions.

Re: Why you should, actually, rewrite some of it in Rust

#298

Post by dikaiosune »

youdontknowtho wrote: post #292
dikaiosune wrote: post #93

Earlier quoted context omitted.

The author is actually using it, to actually rewrite portions of C projects in it, and writing about their experience doing this in practice. For example, the linked paper is about using Rust at the I/O boundary in an existing, complex system.

Except that the article is actually just the feature sheet of Rust. I would rather the article had been a link to that paper.

uhhhhhh, multiple links in this block on the post:

"That’s because I have been working on this subject for a long time now:

* I did multiple talks on it * I even co-wrote a paper * I did it both as client and personal work"

Re: Why you should, actually, rewrite some of it in Rust

#299

Post by rbehrends »

steveklabnik wrote: post #297
rbehrends wrote: post #296

Earlier quoted context omitted.

I know about crossbeam vaguely (mostly because the non-blocking concurrency is of interest to my research), but due to lack of documentation, haven't really dug into it and am not even sure what it has to do with GC? > As I said elsewhere, your definition of "zero cost abstractions" differs from what the term means. I'm going by Stroustrup's definition [1]? If your argument is – I'm not sure here – that "Rust gets ze…

Crossbeam's epoch based collection is basically a form of GC, for certain kinds of data structures. Yeah Bjane's definition doesn't say "no overhead", it says "no extra overhead." If your data structure requires a GC, then writing a GC for it is a zero-overhead abstraction. What I'm saying is "gotcha, you need some runtime support for this" is not contradictory to zero-cost abstractions.

> If your data structure requires a GC, then writing a GC for it is a zero-overhead abstraction. What I'm saying is "gotcha, you need some runtime support for this" is not contradictory to zero-cost abstractions.

There are two points to be made here.

1. The problem is not that a data structure needs GC; it's that reference counting (or worse, atomic reference counting) is about the highest-overhead garbage collection in existence. It's popular because it's easy to implement, has mostly predictable performance, and can be implemented as a library without compiler support, but performance is not one of its virtues. The cost really becomes absurd in the `Arc` case, where you have an atomic operation for each reference count update. Nobody actually implements performance-sensitive data structures using naive atomic reference counting outside of C++ and Rust.

2. Persistent data structures (or anything with structural sharing) are, as I mentioned, just the simplest example. They are suitable for illustrating the problems Rust has with shared ownership, but shared ownership is not limited to those. Rust also has problems with shared ownership in a number of other scenarios (such as global caching or any scenario where object lifetime depends on the semantic state of a program).

The underlying problem is that whenever you approximate an undecidable predicate (pointer safety in this case) with a decidable subpredicate, then any zero-cost abstraction claim usually falls flat, because there are typically other decidable subpredicates (not even counting throwing a full theorem prover at the problem) that can handle cases without overhead that your approach can't. In the case of pointer safety, model-checking approaches would be an obvious and well-known example.

Obviously, these alternative approaches may carry different software engineering overhead, but a claim about an abstraction being zero-cost is independent of software engineering costs (not to mention that this is an area where Rust is hardly without its own issues).

Re: Why you should, actually, rewrite some of it in Rust

#300

Post by youdontknowtho »

dikaiosune wrote: post #298
youdontknowtho wrote: post #292

Earlier quoted context omitted.

Except that the article is actually just the feature sheet of Rust. I would rather the article had been a link to that paper.

uhhhhhh, multiple links in this block on the post: "That’s because I have been working on this subject for a long time now: * I did multiple talks on it * I even co-wrote a paper * I did it both as client and personal work"

Yes, I saw those links. The article that op linked to though was another Rust feature sheet blog post, though.

This was days ago, why do you care?

Post reply on HN