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

221–230 of 277 posts

Re: Announcing Rust 1.20

#221

Post by lomnakkus »

amelius wrote: post #217
lomnakkus wrote: post #216

Earlier quoted context omitted.

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?

I would assume a rewrite counts as a bunch of line changes -- absent evidence to the contrary. Obviously, if you're changing the language that changes the equation, some bugs which can happen in C++ simply cannot happen in Rust, for example.

(And yes, I meant "positively correlated with".)

Re: Announcing Rust 1.20

#222

Post by pdpi »

copx wrote: post #15
kibwen wrote: post #6

Earlier quoted context omitted.

You've misread the announcement; Rust has had associated functions since time immemorial. Associated consts aren't class variables, because constants can't vary (that's sort of the whole point of constants...). Rust also doesn't have classes in any recognizable sense (we can argue all day about whether Rust supports "OOP", but the separation of data and behavior into structs and impls respectively pretty thoroughly s…

>Associated consts aren't class variables, because constants can't vary That's why I wrote "limited version of". Rust's "associated constants" are a subset of C++'s class variables feature. Namely you can only have variables qualified "const" i.e. constants. >Rust also doesn't have classes in any recognizable sense What? If you have instantiatable abstract data types with associated methods you have a "class". Callin…

> Oh and calling an interface a "trait" does not change its fundamental nature either.

Traits are a form of ad hoc polymorphism and behave closer to Haskell's typeclasses than they do to interfaces and subtype polymorphism.

Re: Announcing Rust 1.20

#223

Post by alphaalpha101 »

AsyncAwait wrote: post #220
alphaalpha101 wrote: post #193

Earlier quoted context omitted.

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.

Rust doesn't ensure memory safety or safe concurrency. It ensures memory safety - including data race safety, just one part of safe concurrency - assuming you never use any unsafe code and that the standard library is free of bugs. I'm happy to assume the standard library is free of memory safety bugs, because you have to trust something.

But I'm not happy trusting that dependencies aren't using unsafe code, and I'm not happy claiming that Rust ensures safety, when it ensures safety only if you assume that unsafe blocks aren't unsafe.

The problem is that you can't check unsafe blocks locally. Checking that each individual unsafe block doesn't have undefined behaviour requires checking the entire programme.

It's better than nothing, without a doubt, but it isn't safe.

Re: Announcing Rust 1.20

#224

Post by alphaalpha101 »

gcp wrote: post #210
jacobush wrote: post #202

Earlier quoted context omitted.

Here have an upvote. Can someone else comment/refute this?

Most of us write new, complex data-structures, that aren't part of the stdlib or a crate, like once a year, at most. Those are hard in Rust if they involve circular pointers. They're hard in C/C++ too, but in a different way (easier to write the code, harder to be sure it's correct). The idea that Rust would be no better than C/C++ because of the latter parts doesn't make much sense. This kind of work is unusual for…

It doesn't matter that it's 'kind of unusual', even though I contend that it isn't. Even if, for the sake of argument, we assume that it is, that doesn't change my point.

My point is that the whole point of Rust is supposedly that it

>is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.

except that when you look at any of the examples of code that really would benefit from the compiler's help, the compiler just throws its hands in the air and goes 'it's all up to you now'.

The problem is that Rust doesn't let you make a single assumption and let the compiler prove the safety of the code using that assumption. It just has a valve that you can hit that removes all guarantees.

If you could say 'this code is safe assuming that this FFI function doesn't exhibit undefined behaviour, please check that for me' or write a proof that says 'this actually is safe, because this pointer can only ever point into this valid memory or this valid memory, and this is why' then the compiler would still be useful.

Whether 'this work' (which is not just creating data structures, but anything that the compiler doesn't understand, which is much broader than just creating data structures) is unusual or not, IMO the whole appeal of Rust is that it makes doing that work easy. But it doesn't.

Rust just doesn't seem worth it, doesn't seem worth rewriting whole ecosystems of code. It doesn't give any actual safety.

Re: Announcing Rust 1.20

#225

Post by childintime »

__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

This is a PHP map, correct? It is the one language feature that made PHP stand out from the crowd.

Re: Announcing Rust 1.20

#226

Post by Vinnl »

dblohm7 wrote: post #64
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

Quantum is the project, not the engine. The resulting product is still Gecko.

And the goal of the project is to significantly improve the performance of Firefox.

Re: Announcing Rust 1.20

#227

Post by brazzledazzle »

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 use it everyday, several times per day. Thank you for you such a useful utility.

Re: Announcing Rust 1.20

#228

Post by sevensor »

whyever wrote: post #218
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...

That's something I'd like to understand better -- MAX is defined as a literal number, but NAN and INFINITY are computed by the compiler. I looked at the header files on my system: GNU nan.h uses a GCC builtin and falls back on a magic bit-pattern (a NaN as defined by the IEEE754). Is 0.0/0.0 more portable? Clearer? Are magic bit-patterns just not in the spirit of the language? Sorry to be so particular about this -- floats are tricky and I'd like to know exactly what's going on with them.

Re: Announcing Rust 1.20

#229

Post by giancarlostoro »

cpeterso wrote: post #189
bad_user wrote: post #182

Earlier quoted context omitted.

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.

They do plan on replacing component by component so not sure how that will be in the case of Gecko, unless Gecko is already designed with pluggable parts then it would make sense, otherwise they might have to replace a lot of moving parts (not sure how large Gecko is / how much it needs to function) but it'll still be done in chunks if it's too large I'm guessing.

Re: Announcing Rust 1.20

#230

Post by cesarb »

a_t48 wrote: post #153
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…

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

IIRC, Rust's HashMap uses a single raw vector containing for each entry its hash code, its key, and its value; empty entries have a special hash code as a marker, with the key/value left uninitialized. Also, the hashes are kept together (separate from the rest) for better cache behavior during the linear probing.
Post reply on HN