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

Announcing Rust 1.20

blog.rust-lang.org

Post reply on HN
Print view View original

181–190 of 277 posts

Re: Announcing Rust 1.20

#181

Post by lomnakkus »

lederhosen wrote: post #115
jeffdavis wrote: post #100

Earlier quoted context omitted.

Thank you. I will look into these and give it another try. It's a good point that maybe I should just have the right expectations here, and expect data structures to be hard in rust. I looked around a bit and it looks like these thing are quite challenging in haskell as well.

In Haskell it is easy, you can not create cyclic data structures ;-)

Counterexample:

    $ ghci
    GHCi, version 8.0.2: http://www.haskell.org/ghc/  :? for help
    Prelude> let ones = 1 : ones
    Prelude> take 50 ones
    [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1]
You can take as many as you like. (The 'ones' list contains a tail which links back to its head, producing an infinite list.)

Obviously, this is a trivial example, you can do much more interesting things with mutually recursive bindings.

Re: Announcing Rust 1.20

#182

Post by bad_user »

tempay wrote: post #36
kibwen wrote: post #3

Interestingly, because Firefox chooses to use stable Rust exclusively, this is the version of Rust that will be used to deliver Quantum when Firefox 57 releases on November 14 (by which time Rust 1.21 will be out (releasing October 12), but Firefox 57 will be in beta by September 20).

To save others from searching, Quantum[1] is the new engine for Firefox replacing(/building upon) gecko. [1] https://wiki.mozilla.org/Quantum

So they are already switching to the new Quantum-powered Gecko in Firefox 57?

Re: Announcing Rust 1.20

#183

Post by Animats »

dmix wrote: post #161
catnaroek wrote: post #160

Earlier quoted context omitted.

> The answer isn't generics, Coq, or some fancy type system nobody will understand or use properly. The solution is a formal semantics for unsafe Rust, so that programmers can prove that their unsafe Rust code is safe to use by whatever means they prefer. (Mine would be by hand.) --- Reply to dmix: A formal semantics doesn't have to be particularly fancy, although in Rust's case, it will in most likelihood not be str…

Is that a fancy system that nobody will understand or use properly? (Honest question)

Probably. I used to do formal proof of correctness work and headed a project to build a verifier.[1] That stuff is very hard.

The partially initialized array thing is an issue of expressive power. You can't talk about that in Rust yet. This is a classic issue. The three big headaches in C around memory safety are "how big is it", "who owns it", and "who locks it". The language lacks the syntax to even talk about those issues. Rust can talk about those, which is a huge step forward.

Before you can even consider verifying something, you have to be able to talk about it in some formal language. Preferably the one you're programming in. Having to do formal specifications in a separate language is a huge headache. Been there, done that.

There are a few standard trouble spots. I've listed two of them. Most other unsafe code comes from

1) Foreign functions, which can be expected to decline over time as more libraries are implemented in Rust. (How's SSL/TLS in Rust coming along?)

2) "Optimization", which may be premature. This usually consists of bypassing subscript checks. I'd rather have the subscript checks on all the time, and see effort put into hoisting subscript checks out inner loops. (Subscript checks that aren't in inner loops usually aren't significant overhead items.)

3) replicating C/C++ code in Rust. (An early attempt was a transliteration of Doom into Rust, with lots of pointer arithmetic.)

Remember, it can blow at any seam. It only takes one buffer overflow to allow an exploit.

[1] https://github.com/John-Nagle/pasv

Re: Announcing Rust 1.20

#184

Post by Animats »

__s wrote: post #154
Animats wrote: post #133

Earlier quoted context omitted.

I've argued this issue before. The answer isn't generics, Coq, or some fancy type system nobody will understand or use properly. There are only a few inherent trouble spots in pure Rust code safety. The big two are: - Partially initialized arrays. "Vec" has to be unsafe because growing an array involves uninitialized slots. You just need a way to say "this array is initialized from 0..N only", where N is in a data st…

Good Map implemented on top of Vec: https://github.com/bluss/ordermap

Very nice.

Re: Announcing Rust 1.20

#185

Post by Animats »

__s wrote: post #155
a_t48 wrote: post #153

Earlier quoted context omitted.

A hashmap being implemented on top of vectors is a pretty common implementation. Not sure what Rust uses though.

Problem is avoiding having to do Vec >

If T is a reference type, doesn't Rust do an optimization where >> is implemented by using null pointers?

Re: Announcing Rust 1.20

#186

Post by tene »

lederhosen wrote: post #115
jeffdavis wrote: post #100

Earlier quoted context omitted.

Thank you. I will look into these and give it another try. It's a good point that maybe I should just have the right expectations here, and expect data structures to be hard in rust. I looked around a bit and it looks like these thing are quite challenging in haskell as well.

In Haskell it is easy, you can not create cyclic data structures ;-)

    let cycle = "cycle " ++ cycle

Re: Announcing Rust 1.20

#187

Post by fdchn2016 »

Is there a book on Programming Data Structures in Rust. Like from scratch. Trees, Graphs etc. I would expect the first 2 to 3 chapters to be on Rust pointer system and the rest of the book to be on implementing Data Structures using the pointer system.

Similar to like Tanenbaum's book for Data Structures in C or Kruse, Leung and Tondo's book for Data Structures in C.

Re: Announcing Rust 1.20

#188

Post by lordnaikon »

burntsushi wrote: post #178
firebones wrote: post #168

Earlier quoted context omitted.

Are there any stats yet on improvements in memory safety within Firefox attributable to Rust. In theory, it could be as much as 50% fewer based on the original premise of Rust removing whole classes of programmer errors, but are there stats from Rust being in the wild? The CSS replacement reminded me that there should be something to compare.

> are there stats from Rust being in the wild? I don't know, but if I recall correctly, nobody has ever reported a memory safety bug to ripgrep, or even the underlying regex engine. I don't really know how many people use ripgrep, but it's not zero.

I can assure the lower bound is at least one. Thanks for boosting my productivity!

Re: Announcing Rust 1.20

#189

Post by cpeterso »

bad_user wrote: post #182
tempay wrote: post #36

Earlier quoted context omitted.

To save others from searching, Quantum[1] is the new engine for Firefox replacing(/building upon) gecko. [1] https://wiki.mozilla.org/Quantum

So they are already switching to the new Quantum-powered Gecko in Firefox 57?

There is no single switch. Quantum is an ongoing initiative to import more code from Servo into Firefox/Gecko and to improve Firefox responsiveness.

Re: Announcing Rust 1.20

#190

Post by chrismorgan »

steveklabnik wrote: post #172
firebones wrote: post #169

May be too late in this thread for a response, but does the completion of the 1.20 release free up some time for the "State of Rust 2017" survey results blog post before the 1.21 release? I know there was a huge response, and you don't want to step on the release news, but I'm waiting to see where the user community stands.

It's not really about that; the post is almost done, and you should see it soon. It was a lot of work to go through.

While thinking about such things—what happened to https://underhanded.rs/?
Post reply on HN