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

171–180 of 277 posts

Re: Announcing Rust 1.20

#171

Post by LambdaComplex »

evincarofautumn wrote: post #77
kbenson wrote: post #13

> An unstable sort could provide this result, but could also give this answer too: It might just be me, but using "this" twice in the same sentence to refer to two distinct items, one a prior example and one an upcoming example, is somewhat odd. That said, I understood it perfectly fine, it just caused me to stop and ponder the wording for a moment. The following might be more clear: An unstable sort could provide th…

In case anyone’s curious, this is called discourse deixis[1]. It’s a frequent source of errors for non-native English speakers, because in many languages, you use “that” to refer to an example that follows, but English is unusual in that it generally uses “this” for the future and “that” for the past. So that[2] sounds wrong: This[3] probably screwed you up. The somewhat confusing thing is that “this” is also used fo…

Since you apparently know stuff about language, maybe you can help me out:

Sometimes novice programmers try something like "foo == bar && baz" when they really should have "foo == bar && foo == baz". This is because, in English, "Foo is equal to bar and baz" means (and is more common than) "Foo is equal to bar and foo is equal to baz". There's some name for this rule, but I haven't been able to remember it for a while. I think it's "right hand ______", but I can't remember that final word.

Re: Announcing Rust 1.20

#172

Post by steveklabnik »

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.

Re: Announcing Rust 1.20

#173

Post by steveklabnik »

Rusky wrote: post #163
steveklabnik wrote: post #156

Earlier quoted context omitted.

I don't have any citation beyond "Graydon told me one time". It was like, very very long ago, possibly before @T even existed.

IIRC it was a mark and sweep GC in the OCaml implementation.

That sounds about right.

Re: Announcing Rust 1.20

#174

Post by steveklabnik »

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)

We intend for it not to be; more on that as we get closer to actually having a model.

Re: Announcing Rust 1.20

#175

Post by vvanders »

oscargrouch wrote: post #138
steveklabnik wrote: post #130

Earlier quoted context omitted.

Rust doesn't have any more runtime than C, and also doesn't have a GC. Servo has bindings into SpiderMonkey's GC so that the JavaScript stuff works properly, but that's only that part. That said, I don't think there are any direct blog posts about it; Firefox's other code just sees Rust as C code, as far as I know. (I don't work on Firefox though so I could be wrong about some details.)

> That said, I don't think there are any direct blog posts about it; Firefox's other code just sees Rust as C code, as far as I know. So it means the compiled binary ends up in a simple compatible C ABI? thats pretty nice, if thats the case. But giving the project is using LLVM, even C++ ABI would be achievable without too much effort (i guess).

Yup, with bindgen and rusty-cheddar you can build interfaces both ways that just talk over a C ABI. It's really, really nice.

In fact Rust in general is awesome for going to a wide range of platforms. I've got a project right now that runs on MSVC-x64/x86, Linux-x64, OSX-x64, Android-armv7, Android-x86, Linux-armv7 and Emscripten. Single codebase and interacting with various languages(C#, C++, Java) via the C ABI. Rust even cross-compiles my C source via GCC crate so I can use C libraries and build for any of those targets from my host(win32) machine.

Also, having just spent a few hours fucking around with linker flags in Qt I can't stress enough how awesome Cargo, Crates.io, Rustup and the sane defaults Rust has. It really is an incredible ecosystem.

Re: Announcing Rust 1.20

#176

Post by GolDDranks »

jeffdavis wrote: post #92
comex wrote: post #75

Earlier quoted context omitted.

Regarding traits: you can have Rc (by casting from Rc ), but not RefCell . The reason is that Rc is a pointer, so the size of Rc can be constant regardless of the size of the type implementing the trait. But if you actually want a weak reference inside a refcell (as opposed to the other way around), RefCell > should work fine. Also consider the Cell type, which has a more limited API than RefCell but zero overhead. R…

Arenas have more to do with the allocation pattern, they don't solve the cycle problem, right?

In a sense, they solve the cycle problem in Rust. The trick is that once something is allocated to an arena, it has the same lifetime as the whole arena, and that allows cyclical links because none of the nodes "outlive each other".

However, you must have interior mutability (achieved using Cell types), because otherwise you can't mutate the parent nodes to add links to child nodes.

Check the typed arena crate in crates.io and the Cell type in the standard library.

Re: Announcing Rust 1.20

#177

Post by evincarofautumn »

LambdaComplex wrote: post #171
evincarofautumn wrote: post #77

Earlier quoted context omitted.

In case anyone’s curious, this is called discourse deixis[1]. It’s a frequent source of errors for non-native English speakers, because in many languages, you use “that” to refer to an example that follows, but English is unusual in that it generally uses “this” for the future and “that” for the past. So that[2] sounds wrong: This[3] probably screwed you up. The somewhat confusing thing is that “this” is also used fo…

Since you apparently know stuff about language, maybe you can help me out: Sometimes novice programmers try something like "foo == bar && baz" when they really should have "foo == bar && foo == baz". This is because, in English, "Foo is equal to bar and baz" means (and is more common than) "Foo is equal to bar and foo is equal to baz". There's some name for this rule, but I haven't been able to remember it for a whil…

First, I have a little anecdote about that. I was at a summer camp where we were taking game programming classes. I had been programming for longer than the other students, so I would help them out. One of my peers asked me for help with a part of his program. In the course of that, I noticed that he had written “if (x == 1 || 2 || 3 || …)” in another part of his code, and explained that this condition would always be true (in C++). He became defensive and dismissed me, saying “nah, I tried it and it works”…because he had only been trying the success cases. It absolutely infuriated me!

Anyway, IIRC that pattern is called “conjunction reduction”: “foo equals bar and foo equals baz” becoming “foo equals bar and baz”.

The term you might be thinking of is “right node raising”[1], which is when the elements of a conjunction “share” the stuff that follows them, as in “bar equals, and baz equals, foo”.

[1]: https://en.wikipedia.org/wiki/Right_node_raising

Re: Announcing Rust 1.20

#178

Post by burntsushi »

firebones wrote: post #168
shepmaster wrote: post #158

Earlier quoted context omitted.

It's not a blog, but Rust Belt Rust 2017 [1] (a conference I help organize) will have a talk "The Story of Stylo: Replacing Firefox's CSS engine with Rust" [2]. The conference is in Columbus, Ohio, and is reasonably priced. [1]: http://rust-belt-rust.com/ [2]: http://rust-belt-rust.com/sessions.html

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.

Re: Announcing Rust 1.20

#179

Post by wtetzner »

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 ;-)

Cyclic data structures can be created in Haskell, in large part due to laziness.

Re: Announcing Rust 1.20

#180

Post by smegel »

mbrubeck wrote: post #164
smegel wrote: post #129

Earlier quoted context omitted.

Are there any blogs about how Rust is integrated into Firefox (a mostly C++ program) - i.e. how the Rust runtime is invoked, garbage collection etc?

Hi, I'm a Servo developer who worked on some of the Rust code that's in Firefox. Calls between C++ and Rust code in Firefox all go through "extern C" functions. Some of the code involves reference-counted smart pointers. We use RAII wrapper types in both Rust and C++ to ensure that refcounts are incremented and decremented correctly on either side of the FFI boundary. P.S. This old blog post is not about Rust-in-Fire…

Cool thanks.
Post reply on HN