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

Rust 1.26 released

blog.rust-lang.org

Post reply on HN
Print view View original

91–100 of 178 posts

Re: Rust 1.26 released

#91

Post by staticassertion »

Thaxll wrote: post #76
nikolay wrote: post #74

Earlier quoted context omitted.

Rust is much safer by both design and implementation programming language. Google is emotionally attached to Golang, which was born at Google.

How is it much safer? Sounds like you don't know what you're talking about.

There are a few ways.

a) In terms of memory safety, Go is not memory safe in the presence of data races, and Go does not prevent data races at compile time.

On top of this Go does not enable ASLR on most OS's. That means that when Go loads code from other languages, such as C/C++, memory safety issues in those languages are extremely easy to exploit relative to in a language like Rust, which enables tons of mitigation techniques by default.

b) More loosely, Rust has a more expressive type system. It is, in my experience, much simpler to enforce constraints in a 'type driven' way. In my opinion, this leads to safer software.

As an example of (b) I have written authentication code that encodes the authentication protocol's state machine into the Rust type system. What this means is that it is impossible to jump between two states in an undefined way. Beyond that, because of Rust's affine type system, it is impossible to reference invalidated states.

For authentication code, especially when you add complex stateful transitions such as rate limiting, whitelisting, etc, this is an extremely effective way to reason about your security critical code.

I think there is a case to be made that there is a real, significant difference between the languages regarding security.

Re: Rust 1.26 released

#92

Post by mook »

saghm wrote: post #50
pcx wrote: post #45

The wonderful thing about Rust is that despite being fairly new and rare to get paid for working on it, it is still enticing( to most programmers I've met). The consistent effort to improve it is really paying off. I hope it gets to a place where it's `batteries included` like Python. There are some glaring holes in the stdlib I would like to see fixed sometime soon.

The argument for putting things in third-party "blessed" crates rather than the standard library is that it allows them not to have to follow the versioning guarantees of Rust itself. Given that the core team has stated that they don't plan to have a Rust 2.0, this means that there wouldn't _ever_ be any API-breaking changes for things added to the standard library; by having things like `regex` and `rand` be externa…

But the versioning guarantees are _exactly_ why having them in the stdlib would be good for me as a user; it means I'd be able to have code that keeps working, but have new improvements available.

It's totally fine to decide to make the trade off, but it's just frustrating to not have the downside acknowledged.

Re: Rust 1.26 released

#93

Post by [deleted] »

naasking wrote: post #84
wcrichton wrote: post #14

Earlier quoted context omitted.

The guarantee of `impl Trait` is that if I want to call a trait method on the returned object, e.g. for iterators if I want to call `foo(0).next()`, then the function pointer will always be in the same place on the object in memory (static dispatch). By contrast, if I returned a boxed trait, then calling the trait method requires a dynamic lookup to find the method on the boxed object, and then jumping to that functi…

I think your explanation of static and dynamic dispatch is either wrong, or incredibly confusing. The offset of the function pointers is always statically known for a given trait/interface type, it's just the actual vtable instance that may not be known, ie. the concrete type implementing that trait/interface. A statically known vtable instance that can be inlined/monomorphized is static dispatch, and if it's not kno…

[deleted]

Re: Rust 1.26 released

#94

Post by shepmaster »

the_mitsuhiko wrote: post #28
tylerhou wrote: post #16

Earlier quoted context omitted.

I think because returning two different types requires dynamic dispatch when using the returned objects, which requires Box; if the function only returns one type then that type can be determined at runtime and further function calls can be implemented with static dispatch instead.

Rust could generate a bespoke internal proxy type.

Until then, we use `Either` (https://stackoverflow.com/a/50204370/155423)

Re: Rust 1.26 released

#95

Post by nikolay »

Thaxll wrote: post #89
nikolay wrote: post #79

Earlier quoted context omitted.

It sounds like you have no idea about Rust.

You're the one that said "Google is emotionally attached to Golang, which was born at Google." which is really stupid tbh you think engineers at Google pick up tech because they're "emotionally attached"? Those smart people took the tool that fits their needs.

I'm sorry, but Google isn't some role model with high values. On the contrary, it makes most of its money from selling our dirty underwear to merchants.

Re: Rust 1.26 released

#96

Post by bluejekyll »

ben0x539 wrote: post #21

Hooray, congrats to the rust contributors, once again. :) Personally, not a fan of the match change. But then I was already not a fan of autoderef in method calls.

The biggest negative I've seen is this:

    let example: (String, String, String) = ("ref".to_string(), "to".to_string(), "ref".to_string());
   
    let example: (&str, &str, &str) = match &example {
       (ref1, to, ref2) => (ref1, to, ref2),
    };
Which might look confusing to people, it's converting from &(1,2) to (&1,&2)... but it's still type safe. Besides something like this, is there another reason to be worried about it?

https://play.rust-lang.org/?gist=e37f9b31cc5e5c7b9d19c6b0a4c...

Re: Rust 1.26 released

#97

Post by sctb »

wott wrote: post #90
Scarbutt wrote: post #58

Earlier quoted context omitted.

So yeah, 1.26 is the most substantial release since 1.0, but there's lots more goodies coming in the pipeline Will rust users get a break someday?

You have to wait 'post coitum', they are busy working on it at the moment: Very exciting So, so, so much stuff Amazing I'm so excited Lovely, lovely especially excited So cool! Awesome wonderful I'm super pumped Oh wow So freaking excited so excited wonderful amazing Hooray I'm super excited Super excited incredible! Rust is just killing it (I skipped the 'great' and 'congrats'.) Rust threads are a special kind of ob…

Please just skip them then, sparing yourself befoulment and us flamewars.

https://news.ycombinator.com/newsguidelines.html

Re: Rust 1.26 released

#98

Post by pm215 »

gamegoblin wrote: post #47
pcx wrote: post #45

The wonderful thing about Rust is that despite being fairly new and rare to get paid for working on it, it is still enticing( to most programmers I've met). The consistent effort to improve it is really paying off. I hope it gets to a place where it's `batteries included` like Python. There are some glaring holes in the stdlib I would like to see fixed sometime soon.

Which glaring holes are there in your point of view? Rust devs are on HN a lot, so maybe they will see your comment. All that said, Rust definitely errs on the side of preferring to put things in 3rd party crates instead of stdlib, even for things that are very common to put in std for other languages (e.g. random number generation).

Needing to use two separate third-party crates (lazy_static and maplit) to have a global constant-initialized hash table is the one that surprised me recently.

Re: Rust 1.26 released

#99

Post by steveklabnik »

pm215 wrote: post #98
gamegoblin wrote: post #47

Earlier quoted context omitted.

Which glaring holes are there in your point of view? Rust devs are on HN a lot, so maybe they will see your comment. All that said, Rust definitely errs on the side of preferring to put things in 3rd party crates instead of stdlib, even for things that are very common to put in std for other languages (e.g. random number generation).

Needing to use two separate third-party crates (lazy_static and maplit) to have a global constant-initialized hash table is the one that surprised me recently.

maplit is purely a convenience macro, so you shouldn't have actually needed it. Once `const fn` is a thing, lazy_static should be used a lot less too.

Incidentally you might like the phf crate, depending on your needs.

Re: Rust 1.26 released

#100

Post by Lev1a »

mook wrote: post #92
saghm wrote: post #50

Earlier quoted context omitted.

The argument for putting things in third-party "blessed" crates rather than the standard library is that it allows them not to have to follow the versioning guarantees of Rust itself. Given that the core team has stated that they don't plan to have a Rust 2.0, this means that there wouldn't _ever_ be any API-breaking changes for things added to the standard library; by having things like `regex` and `rand` be externa…

But the versioning guarantees are _exactly_ why having them in the stdlib would be good for me as a user; it means I'd be able to have code that keeps working, but have new improvements available. It's totally fine to decide to make the trade off, but it's just frustrating to not have the downside acknowledged.

As long as you don't use "*" as the version for any of the crates in your project's Cargo.toml it should stay at one particular version and therefore follow SemVer guarantees. If you are REALLY paranoid, you can even have the crate be a particular git commit or you could download your preferred version and then refer to it using the "path" key in the Cargo.toml.

Adopting crates into the stdlib would make stdlib and the crate depend on each other, which is not a nice scenario. Also having certain "core"-functionality be dependent on a 6wk release cycle is not great for stuff that is not good once it's set in stone (aka released on stable).

Real core functionality, bare bones stuff like parsing of Rust itself, I/O and TCP/UDP connectivity, which provide an unlikely to ever change framework for crates to build upon rightly has its place in std; e.g. convenience methods for downloading (like what reqwest provides) OTOH have to stay flexible to adapt to the real world.

Post reply on HN