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

211–220 of 277 posts

Re: Announcing Rust 1.20

#211

Post by gcp »

PopsiclePete wrote: post #128
jmcomets wrote: post #68

Earlier quoted context omitted.

I used to be a huge fan of C++. I loved how you could work with a somewhat OO language while still wielding dark powers like: manual memory management, mix-n-match polymorphism (aka. virtual inheritance ), templates, type-erasing. Then I got a full time job working with a large C++ codebase. Since then I've been dealing with: - uninitialized variables / members - NULL checks - buffer overflows, especially with C-stri…

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…

Most large C++ code-bases predate C++11, which was really game-changing.

Re: Announcing Rust 1.20

#212

Post by amelius »

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.

Doesn't ANY rewrite (regardless of whether there is a change in language) reduce bug-count, simply because all the requirements are more clear in advance and the engineers have had more time to think about a suitable architecture?

Re: Announcing Rust 1.20

#213

Post by imtringued »

tree_of_item wrote: post #56
zaphar wrote: post #55

Earlier quoted context omitted.

I wouldn't call myself an adherent. If anything I'm an adherent to the idea that Objects are just another Closure and vice versa. The interesting distinctions are in how they achieve those same goals. But most working programmers don't care about the debate at all in my experience. When they say they are looking for an object oriented language what they are really saying is: I am looking for a language that has a syn…

> I'm looking for a language with "objects" and a syntax like But why? That's such a weird thing to look for. Clearly there's a reason they think they want "objects", but what is it? And why the focus on what syntax these objects have?

Code organisation. Classes are basically used as datatype specific namespaces.

In Haskell you have to deal with the possibility of record types sharing the same field names.

Re: Announcing Rust 1.20

#214

Post by oscargrouch »

burntsushi wrote: post #140
oscargrouch wrote: post #138

Earlier quoted context omitted.

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

To clarify, Rust has its own ABI, just like C++ has its own ABI. And just like C++, you can expose a C ABI if you want by defining special functions. In C++, it's an `extern "C" { ... }` block, and in Rust, it's a `extern "C" fn foo() ...` function declaration. You can see an example here: https://github.com/rust-lang/regex/tree/master/regex-capi Adding C++ ABI support is a significant effort.

> To clarify, Rust has its own ABI, just like C++ has its own ABI. And just like C++, you can expose a C ABI if you want by defining special functions. In C++, it's an `extern "C" { ... }` block, and in Rust, it's a `extern "C" fn foo() ...` function declaration.

Ohh, Now i got it. But its pretty good thing to have anyway. C ABI is the lingua franca anyway to communicate to any language, even C++.

> Adding C++ ABI support is a significant effort.

Ok. So if has its own ABI, im sure it would be a pretty hard undertaking to be compatible with C++.

I was guessing if maybe Rust had managed to squeeze and reuse the C++ ABI.. but sure, giving Rust is not that much alike C++ this would probably be a bad decision for small gains.

Thanks for clarifying.

Re: Announcing Rust 1.20

#215

Post by oscargrouch »

Manishearth wrote: post #150
oscargrouch wrote: post #138

Earlier quoted context omitted.

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

bindgen actually has the option to generate wrappers for C++ methods and other stuff for Rust to call. We don't use this, but we do use its ability to generate templates and stuff. The other way around -- getting Rust to use the C++ abi -- needs compiler changes and also has questionable benefits.

> getting Rust to use the C++ abi -- needs compiler changes and also has questionable benefits.

Yes.. Im sure is not worthy it overall.

Re: Announcing Rust 1.20

#216

Post by lomnakkus »

amelius wrote: post #212
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.

Doesn't ANY rewrite (regardless of whether there is a change in language) reduce bug-count, simply because all the requirements are more clear in advance and the engineers have had more time to think about a suitable architecture?

Nope. Churn (= number of lines changed) is actually pretty well correlated with bug count.

I don't have a precise reference off-hand, but I believe I read it in "Making Software: What Really Works, and Why We Believe It".

Obviously you'll probably get closer to what the software is intended to do, but it probably won't reduce bug count in the short term. In the long term, you might end up with fewer lines of code overall (which is also correlated with overall bug count).

Re: Announcing Rust 1.20

#217

Post by amelius »

lomnakkus wrote: post #216
amelius wrote: post #212

Earlier quoted context omitted.

Doesn't ANY rewrite (regardless of whether there is a change in language) reduce bug-count, simply because all the requirements are more clear in advance and the engineers have had more time to think about a suitable architecture?

Nope. Churn (= number of lines changed ) is actually pretty well correlated with bug count. I don't have a precise reference off-hand, but I believe I read it in "Making Software: What Really Works, and Why We Believe It". Obviously you'll probably get closer to what the software is intended to do, but it probably won't reduce bug count in the short term. In the long term, you might end up with fewer lines of code ov…

> Churn (= number of lines changed) is actually pretty well correlated with bug count.

Is a rewrite considered as bunch of line changes or not? I would say not.

Also, can I assume that by "correlated with" you mean "positively correlated with"?

If so, isn't a rewrite reducing bug count because you'll end up with far fewer "changed" lines?

Re: Announcing Rust 1.20

#218

Post by whyever »

sevensor wrote: post #18

Not a Rust programmer, so the answer to this question may be in TFM -- Rust has floats, but it doesn't make available constants for inf and NaN? Are you not guaranteed IEEE754 floats? const NAN: f32 = 0.0f32 / 0.0f32; const INFINITY: f32 = 1.0f32 / 0.0f32; Or is that just for the sake of example?

This is how making the constants available could look like. Currently they are available via a module, and they are implemented like above:

https://github.com/rust-lang/rust/blob/master/src/libcore/nu...

Re: Announcing Rust 1.20

#219

Post by Insanity »

senatorobama wrote: post #208
mbrubeck wrote: post #164

Earlier quoted context omitted.

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…

Are there any engineering openings at Mozilla?

You can check out this page: https://careers.mozilla.org/

Re: Announcing Rust 1.20

#220

Post by AsyncAwait »

alphaalpha101 wrote: post #193
chancancode wrote: post #73

Earlier quoted context omitted.

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…

It's also really no better than C. Or at least no better than C++. This is my main issue with Rust. It doesn't seem to really solve the right problem. I feel like it solves the easy problems that I already know how to solve easily, but as soon as I get to something that really, truly feels like I want it, the best solution is unsafe. A complicated circular linked data structure is exactly where I want the language to…

I don't know, ensuring memory safety at compile time and safe concurrency is a pretty big win for me over C, I know many people who claim that they can write/debug C programs to be memory safe, however the real world would respectfully disagree.
Post reply on HN