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

161–170 of 277 posts

Re: Announcing Rust 1.20

#161

Post by dmix »

catnaroek wrote: post #160
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…

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

Re: Announcing Rust 1.20

#162

Post by reificator »

chancancode wrote: post #73
jeffdavis wrote: post #65

I've been having a little trouble using rust for a little project: I need a tree with uplinks (meaning there are cycles). I asked on IRC a couple times and I think what I need is a weak reference inside a refcell, but it's not very easy to make it work cleanly. For one thing, it doesn't look like refcell works well with traits (the nodes in the tree are traits, not plain structs). I'm a bit frustrated because this is…

Have you read "Learning Rust With Entirely Too Many Linked Lists"[1]? I think it will be quite helpful for these kind of situations. It walks you through all the possible tools in the language that is available to you, and at the end, if you just want to write it how you would in C, you could always do it "unsafely" with raw pointers (which is no worse than C). --- [1] http://cglab.ca/~abeinges/blah/too-many-lists/bo…

Beat me to this by six hours. Can vouch that the above link is quite helpful when learning Rust.

Re: Announcing Rust 1.20

#163

Post by Rusky »

steveklabnik wrote: post #156
iopq wrote: post #152

Earlier quoted context omitted.

Are you sure? I thought @ was reference counted in 0.6 and then removed after. Was it before that?

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.

Re: Announcing Rust 1.20

#164

Post by mbrubeck »

smegel wrote: post #129
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).

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-Firefox, but it does cover a related topic: How the Servo browser engine (written in Rust) interacts with the Spidermonkey JavaScript engine (written in C++ and embedded in both Gecko and Servo), including garbage-collected JavaScript objects:

https://research.mozilla.org/2014/08/26/javascript-servos-on...

Re: Announcing Rust 1.20

#165

Post by slavik81 »

kbenson wrote: post #120
slavik81 wrote: post #89

Earlier quoted context omitted.

Very nice. As you say, it doesn't just cast at the end, but actually uses the type through the whole calculation! To illustrate the difference: Rust: fn main() { let a: f32 = 1e7 + 0.5 + 0.5; let b: f32 = 1e7f32 + 0.5f32 + 0.5f32; println!("{}", a==c); // true } C: #include int main() { float a = 1e7 + 0.5 + 0.5; float b = 1e7f + 0.5f + 0.5f; printf("%s\n", a==b ? "true" : "false"); // false } That's awesome. I'm tot…

> While f might be a nicer suffice than f32, no suffix is even better. Well, isn't float in C and C++ platform dependent, and just usually 4 bytes on common platforms? I like the idea of being explicit in the storage type, even if it's slightly more verbose.

I might otherwise agree with you, but I find it hard to read when extra numbers are interspersed with the numbers that actually part of the calculation. I feel the readability matters more than the explicitness.

Re: Announcing Rust 1.20

#166

Post by xfer »

ryl00 wrote: post #159
PopsiclePete wrote: post #128

Earlier quoted context omitted.

That's my main beef with C++. You read a book and it's beautiful - no uninitialized memory, safety, no C arrays/strings, RAII everywhere, it's clean, fast.....then you get to the "real world" and realize that 99% of C++ programmers are pretty f###ing horrible at their job and should've just stuck to naked C because at least then you'd be able to pin-point the bugs easier. So C++ is a wonderful language - in a world t…

But isn't that the case with basically ANY programming language? Once its use becomes widespread, escaping the confines of the highly skilled early adapters, you can be sure a whole lot of dodgy code will be written in it.

Not really, because the language doesn't make it difficult to write dodgy code and gives you no power to easily find such dodgy code. In other safe languages either you simply can't write these kind of dangerous code or it should be easier to catch them with just keyword search. In C++ you need powerful static analysis and some dynamic instrumentation to hopefully catch them.

Re: Announcing Rust 1.20

#167

Post by steveklabnik »

catnaroek wrote: post #160
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…

> 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…

This is being worked on! Several bits of the rust standard library have already been proven safe in the initial model.

Re: Announcing Rust 1.20

#168

Post by firebones »

shepmaster wrote: post #158
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?

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.

Re: Announcing Rust 1.20

#169

Post by firebones »

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.

Re: Announcing Rust 1.20

#170

Post by JoshTriplett »

evincarofautumn wrote: post #139
JoshTriplett wrote: post #80

Earlier quoted context omitted.

> English is unusual in that it generally uses “this” for the future and “that” for the past. I don't know that I'd describe it as "future" and "past"; it's more that English uses "this" for "current" and "that" for "other", whether past or future. For instance, "this situation is broken, that solution looks promising" uses "this" to refer to the present and "that" for the future.

I was referring to past/future in the text . Deixis is about how words and phrases like “this”, “that”, “here”, &c. are contextualised. Your example is unrelated to discourse deixis because it’s not referring to a piece of the surrounding discourse. We use different forms of deixis and spatial metaphors for time, like “the end is near” or “the past is behind us”—in some languages, the past is in front of you (mnemoni…

Ah, fair enough; I hadn't interpreted your previous comment as backwards/forwards in the text. Thanks for the clarification.
Post reply on HN