Rust 1.49.0 • Hacker News Board

Re: Rust 1.49.0

#21

Post by steveklabnik » Thu, Dec 31, 2020, 3:50 PM UTC

boxmonster wrote: post #19

I recently wrote a utility for myself in Rust after having done several in C#. I like both languages, but Rust introduces pain points for no apparent reason. For example, I hate this way of dealing with errors match result { Ok(value) => value, Err(result) => { panic!("error traversing directories {}", result); } }; It's awkward and ugly. I'm back to C#, now on .NET 5.) and find that it just got noticeably faster! It…

This code is equivalent to

    result.unwrap_or_else(|e| panic!("error traversing directories {}", e));

There are a lot of methods on various types to reduce this kind of thing. If you didn't want to interpolate the value of e, it would be even simpler:

    result.expect("error traversing directories");

Re: Rust 1.49.0

#22

Post by lumost » Thu, Dec 31, 2020, 3:52 PM UTC

steveklabnik wrote: post #16

the_mitsuhiko wrote: post #11

Earlier quoted context omitted.

I generally started going from the blog posts to the changelog as I felt for a few times now that the stuff I care about was not in the announcement blog post.

Yeah, it's just impossible to please everyone, especially in releases like these, which have a few minor things and that's it. Rust 1.51 will be easy, given that "const generics" is a huge headline feature almost every Rust user will care about, but for features that are full of tiny things, it's just way way less clear. This has the funny effect of posts getting harder to write as time goes on; we have less releases…

It might be worth separating the different improvement areas by section to let people zoom in on what they care about.

Re: Rust 1.49.0

#23

Post by ChrisSD » Thu, Dec 31, 2020, 3:52 PM UTC

steveklabnik wrote: post #18

ChrisSD wrote: post #14

Earlier quoted context omitted.

I'm not sure what you mean by conversion between String and &str? To get an owned String from a &str you just use the `into` method, no?

Strings implement a lot of different conversions, since they're very general. You've got: * Into, with s.into() * An inherent method, .as_str() * Deref coercion, &s * Reborrowing, &*s (this builds on Deref too but isn't a coercion and can be done in places where coercion doesn't kick in) ... and probably some others I'm forgetting.

Right but as a general rule you'll mostly only be using `s.into()` to get a `String` from an `&str`. Or `&s` to deref `String` to a `&str`. I'm not sure why this would require a crate to handle?

The other ways are more "advanced", for when you're dealing with (for example) potentially unsafe coercions or you don't want to rely on inference for some reason.

Re: Rust 1.49.0

#24

Post by option_greek » Thu, Dec 31, 2020, 3:54 PM UTC

steveklabnik wrote: post #18

ChrisSD wrote: post #14

Earlier quoted context omitted.

I'm not sure what you mean by conversion between String and &str? To get an owned String from a &str you just use the `into` method, no?

Strings implement a lot of different conversions, since they're very general. You've got: * Into, with s.into() * An inherent method, .as_str() * Deref coercion, &s * Reborrowing, &*s (this builds on Deref too but isn't a coercion and can be done in places where coercion doesn't kick in) ... and probably some others I'm forgetting.

-> specifically this one: "Reborrowing, &*s"

Would have been easier to implement with a copy constructor I guess. Why not implicitly clone in some cases (since classes like String gets used so frequently).

Re: Rust 1.49.0

#25

Post by [deleted] » Thu, Dec 31, 2020, 3:55 PM UTC

option_greek wrote: post #20

steveklabnik wrote: post #15

Earlier quoted context omitted.

> the conversions between String and &str are really ugly to look at. This is entirely up to you; unless you find method calls ugly, in which case, you've got bigger problems :) > They need to take more inspiration from C# Could you elaborate a bit? I'm not familiar with what C# does here.

In C# there is a helper class: https://docs.microsoft.com/en-us/dotnet/api/system.convert?v... I'm still figuring my way around rust so obviously some noob questions follow: -> what's with the move/copy mess ? I know why they are needed but it seem to be in the face with all the explicit '&' all over the place in any reasonably sized code. Why not hide it a bit by letting the implicit copy to happen to simpler struct…

[deleted]

Re: Rust 1.49.0

#26

Post by deccanchargers » Thu, Dec 31, 2020, 3:55 PM UTC

Nice.

Rust is nice language btw.

But,when will stable version of Rust be released? By stable,i mean, number of new features added must not be too much. Rust currently seem to be adding too many features every release (which is nice but also not so good at same time)

Re: Rust 1.49.0

#27

Post by steveklabnik » Thu, Dec 31, 2020, 3:55 PM UTC

option_greek wrote: post #20

steveklabnik wrote: post #15

Earlier quoted context omitted.

> the conversions between String and &str are really ugly to look at. This is entirely up to you; unless you find method calls ugly, in which case, you've got bigger problems :) > They need to take more inspiration from C# Could you elaborate a bit? I'm not familiar with what C# does here.

In C# there is a helper class: https://docs.microsoft.com/en-us/dotnet/api/system.convert?v... I'm still figuring my way around rust so obviously some noob questions follow: -> what's with the move/copy mess ? I know why they are needed but it seem to be in the face with all the explicit '&' all over the place in any reasonably sized code. Why not hide it a bit by letting the implicit copy to happen to simpler struct…

Rust has From/Into and TryFrom/TryInto that do the same thing, as far as I can tell. It's not clear to me what the differences are, maybe someone else in this thread will know. :)

> Why not hide it a bit by letting the implicit copy to happen to simpler structures ?

This is the Copy trait.

> Why no love for inheritance

There are a variety of reasons, but one interesting one is that inheritance and strong type inference have issues, and we have very strong type inference. Beyond that, there are various other reasons, but what it really comes down to is that there's just not a ton of pressure to actually implement it; it's not enough of an impediment for Rust users to justify adding it. Most requests come from people who do not write Rust, and once people get into Rust and how it works, they don't seem to need it much anymore.

This is of course very general and there are some people who love it and want it badly anyway, but "some people exist who want this feature" is not enough to make it happen. Rust already has a lot of features, and some people say too many. We have to be careful here.

> Why no love for global/static variables ?

What does "love" mean? Rust absolutely supports these.

Re: Rust 1.49.0

#28

Post by School-Cotton » Thu, Dec 31, 2020, 3:56 PM UTC

option_greek wrote: post #20

steveklabnik wrote: post #15

Earlier quoted context omitted.

> the conversions between String and &str are really ugly to look at. This is entirely up to you; unless you find method calls ugly, in which case, you've got bigger problems :) > They need to take more inspiration from C# Could you elaborate a bit? I'm not familiar with what C# does here.

In C# there is a helper class: https://docs.microsoft.com/en-us/dotnet/api/system.convert?v... I'm still figuring my way around rust so obviously some noob questions follow: -> what's with the move/copy mess ? I know why they are needed but it seem to be in the face with all the explicit '&' all over the place in any reasonably sized code. Why not hide it a bit by letting the implicit copy to happen to simpler struct…

> Why not hide it a bit by letting the implicit copy to happen to simpler structures.

This is already the case. Built-in types that are simple enough to be copied implicitly already are (roughly: those which don't manage any memory or other resources), and you can enable this for your own types with `#[derive(Copy)]`, as long as they are composed only of implicitly copyable types.

    #[derive(Copy)]
    struct S {
        x: i32,
        y: usize,
        z: Option>,
    }

    fn f(x: S) {
        // ...
    }

    fn main() {
        let s = S { x: 0, y: 0, z: Some(Ok(())) };
        f(s);
        f(s);
    }

Something like `String` isn't implicitly copyable in Rust, because it manages memory, and therefore copying it would require a heap allocation.

The Rust way of forcing non-trivial clones to be explicit is much better than C++ IMO, where someone forgetting a `&` or an `std::move` somewhere can cause an innocuous-looking function call to be arbitrarily slow.

In C# there are not implicit copies either (except of value types), because more complex types in C# are accessed via pointers to garbage-collected heap objects. Rust doesn't have a garbage collector, though.

Re: Rust 1.49.0

#29

Post by jcelerier » Thu, Dec 31, 2020, 3:57 PM UTC

deccanchargers wrote: post #26

Nice. Rust is nice language btw. But,when will stable version of Rust be released? By stable,i mean, number of new features added must not be too much. Rust currently seem to be adding too many features every release (which is nice but also not so good at same time)

> but also not so good at same time

why ? do they charge you by the feature ?

Re: Rust 1.49.0

#30

Post by steveklabnik » Thu, Dec 31, 2020, 3:57 PM UTC

option_greek wrote: post #24

steveklabnik wrote: post #18

Earlier quoted context omitted.

Strings implement a lot of different conversions, since they're very general. You've got: * Into, with s.into() * An inherent method, .as_str() * Deref coercion, &s * Reborrowing, &*s (this builds on Deref too but isn't a coercion and can be done in places where coercion doesn't kick in) ... and probably some others I'm forgetting.

-> specifically this one: "Reborrowing, &*s" Would have been easier to implement with a copy constructor I guess. Why not implicitly clone in some cases (since classes like String gets used so frequently).

Well, Rust doesn't have constructors, let alone copy constructors. Clone goes from &T -> T, so that is the exact opposite conversion needed here, let alone auto-clone.

Automatically copying strings may not be a great idea: https://news.ycombinator.com/item?id=8704318