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

Bugs You'll Probably Only Have in Rust

gankro.github.io

Post reply on HN
Print view View original

41–50 of 91 posts

Re: Bugs You'll Probably Only Have in Rust

#41

Post by dbaupp »

burntsushi wrote: post #39
Manishearth wrote: post #37

Earlier quoted context omitted.

I assume "rust fanboy" is me. Please stop it. This is the fourth time you're making this unsubstantiated claim. Yes, I backed up my argument with "the crates I am using" (that is, all the crates in the entire dependency tree of any crate I've used in the last year), which is at least somewhat representative of the crates that folks use, as opposed to your wild claims that have zero backup (or are backed up with one o…

> IIRC UTF8 stuff has been a perf bottleneck in the url crate Right, and this isn't surprising at all. It's not at all obvious to me that it's premature. It's really easy for from_utf8 to show up in a profile, and I've had occasion to either work around it safely (perhaps by staying in `&[u8]` land) or by resorting to `unsafe`. I did the latter in the CSV crate for managing `StringRecord`s.[1] The record is stored co…

I have found it very interesting to use the safe function when debug_asserts are on and the unsafe one otherwise (or more generally, some abstraction over safe/unsafe variants that compiles away to nothing in the optimised case). This plays really well with fuzzing/quickcheck (etc) too.

My favourite example of doing this personally is: https://github.com/Aatch/ramp/pull/48

Re: Bugs You'll Probably Only Have in Rust

#42

Post by Manishearth »

burntsushi wrote: post #39
Manishearth wrote: post #37

Earlier quoted context omitted.

I assume "rust fanboy" is me. Please stop it. This is the fourth time you're making this unsubstantiated claim. Yes, I backed up my argument with "the crates I am using" (that is, all the crates in the entire dependency tree of any crate I've used in the last year), which is at least somewhat representative of the crates that folks use, as opposed to your wild claims that have zero backup (or are backed up with one o…

> IIRC UTF8 stuff has been a perf bottleneck in the url crate Right, and this isn't surprising at all. It's not at all obvious to me that it's premature. It's really easy for from_utf8 to show up in a profile, and I've had occasion to either work around it safely (perhaps by staying in `&[u8]` land) or by resorting to `unsafe`. I did the latter in the CSV crate for managing `StringRecord`s.[1] The record is stored co…

Yep. We could potentially build a set of robust ASCII APIs with an asciichar type (wrapper around u8) that let you cheaply frob the ASCII portions of a utf8 string, or manipulate a pure ASCII string with free conversion to utf8 after the fact. I'm currently unsure what kinds of functionality is necessary here, but I bet it's all doable as a nicely packaged zero cost API.

Re: Bugs You'll Probably Only Have in Rust

#43

Post by mcguire »

"The bug was a missing annotation, and the result was that users of Rust's stdlib could compile some incorrect programs that violated memory safety."

IIUC, technically, the bug was a missing implementation of a trait and the result was a data race (which I (weirdly, maybe) don't think of as memory safety).

In other words, TL;DR: magic is neat, except that sometimes it really sucks.

I may have misunderstood Ralf's bug. Is it really the case that MutexGuard was seen as Sync if T was Send, rather that Sync? Wouldn't that be a bigger problem than just the case of MutexGuard?

Re: Bugs You'll Probably Only Have in Rust

#44

Post by mcguire »

Wait just a minute. Ralf Jung writes,

"This means that the compiler considers a type like MutexGuard to be Sync if all its fields are Sync."

Is that true in general? Is a type thread safe if all its fields are thread safe individually?

Re: Bugs You'll Probably Only Have in Rust

#45

Post by barsonme »

If you—like me—were interested in Diesel ORM's zero sized types thing, here's a pretty decent explanation: https://np.reddit.com/r/rust/comments/3ur9co/announcing_dies...

edit: Go also has zero-sized types (struct{}), so I wonder if this is also possible? Probably not, I don't think, since the compiler doesn't see through interfaces.

Re: Bugs You'll Probably Only Have in Rust

#46

Post by Manishearth »

barsonme wrote: post #45

If you—like me—were interested in Diesel ORM's zero sized types thing, here's a pretty decent explanation: https://np.reddit.com/r/rust/comments/3ur9co/announcing_dies... edit: Go also has zero-sized types (struct{}), so I wonder if this is also possible? Probably not, I don't think, since the compiler doesn't see through interfaces.

If you're interested in more of this, Sean, the author of Diesel, is giving a talk @ RustConf in August (http://rustconf.com/program.html#sean) which will probably cover these tricks in more depth :)

[Talks will be recorded, but also tickets are on sale right now if you want to be there in person!]

Re: Bugs You'll Probably Only Have in Rust

#47

Post by dbaupp »

mcguire wrote: post #44

Wait just a minute. Ralf Jung writes, " This means that the compiler considers a type like MutexGuard to be Sync if all its fields are Sync. " Is that true in general? Is a type thread safe if all its fields are thread safe individually?

Send and Sync are about data races, which lead to memory unsafety, not other forms of thread safety (like dead lock freedom, or maintaining non-unsafe relationships between fields). If there's no unsafe code, then there's no way to have a data race when the individual components are also data race free.

Re: Bugs You'll Probably Only Have in Rust

#48

Post by projectorlochsa »

wyldfire wrote: post #3

> Making unsafe a big scary "all bets are off" button is only compelling if most of our users don't need to use that button. Rust is trying to be a language for writing concurrent applications, so sharing your type between threads requiring unsafe would be really bad. It would be neat if we could decompose unsafe like so "unsafe[this_feature,that_feature] {}". The unqualified "unsafe" could still refer to a global "f…

unsafe with features sounds like monad transformers in haskell.

if implemented it would probably outperform haskell (given that monad transformers in haskell have runtime overhead, unfortunately).

Re: Bugs You'll Probably Only Have in Rust

#49

Post by tatterdemalion »

barsonme wrote: post #45

If you—like me—were interested in Diesel ORM's zero sized types thing, here's a pretty decent explanation: https://np.reddit.com/r/rust/comments/3ur9co/announcing_dies... edit: Go also has zero-sized types (struct{}), so I wonder if this is also possible? Probably not, I don't think, since the compiler doesn't see through interfaces.

> Go also has zero-sized types (struct{}), so I wonder if this is also possible?

No. It specifically uses Rust's generics system, and the fact that generics are monomorphized at compile time, whereas Go interfaces are not.

C++ templates can be used in similar ways.

Re: Bugs You'll Probably Only Have in Rust

#50

Post by tatterdemalion »

mcguire wrote: post #43

" The bug was a missing annotation, and the result was that users of Rust's stdlib could compile some incorrect programs that violated memory safety. " IIUC, technically, the bug was a missing implementation of a trait and the result was a data race (which I (weirdly, maybe) don't think of as memory safety). In other words, TL;DR: magic is neat, except that sometimes it really sucks. I may have misunderstood Ralf's b…

Your "IIUC" is just a restatement of the sentence you quoted.

You understood the bug correctly, but its not a bigger problem. You probably are lacking context on auto traits, but this blog post contains the context you need if you read it again.

Post reply on HN