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

Rust 1.49.0

blog.rust-lang.org

Post reply on HN
Print view View original

61–70 of 117 posts

Re: Rust 1.49.0

#61

Post by the_duke »

steveklabnik wrote: post #58
the_duke wrote: post #56

Earlier quoted context omitted.

rustup is still the recommended way to install. Rust has a 6 week release cadence, and while the language has settled down significantly over the last 1-2 years, there are still a lot of new features arriving that library maintainers are eager to use. Combined with performance improvements, you will almost always want to use a recent compiler. Relatively slow moving package repositories are not a great fit for that r…

(It's six weeks not three months)

Ah, right, thanks. I knew something about those 3 months bugged me.

Re: Rust 1.49.0

#62

Post by Kinrany »

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…

Do you have any ideas for changing the format, to make it easier to write about these things in a way that lets people read the parts they want?

Possibly write about the reasons something was changed and the use cases improved, instead of the changes themselves?

Re: Rust 1.49.0

#63

Post by adkadskhj »

boxmonster wrote: post #55
steveklabnik wrote: post #21

Earlier quoted context omitted.

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

the unwrap_or_else makes a lot more sense, because I could just use the ? operator, but if I don't want to panic, then I'll use unwrap_or_else. I am not by any means an advanced Rust programmer and in fact learning from your book, so I didn't mean to offend anyone. My initial impression of the match syntax for return values was that I didn't like it. Sorry.

Match has it's place in unpacking common Enum types like Option and Result, but typically you'll reach for functional patterns like `Result::map`, `Result::expect`, `Result::unwrap_or`, and of course `?` as they're able to do the same thing but in far less code.

I think the downvotes are because both the example and the generalized statement that C# is "noticeably faster" is bait / lazy.

Re: Rust 1.49.0

#64

Post by ReactiveJelly »

ufo wrote: post #51

A question for the Rust crowd, from someone who's thinking about giving Rust another chance in 2021: Last time I tried getting into Rust, some years ago, the recommended way to install it was to use the rustup tool. You were also kind of expected to learn using the "nightly" version of the language, because much of the documentation and stackoverflow answers depended on that. Is this still the case now that we're abo…

I used Rust pretty regularly through 2020 at work and home, all with stable Rust.

All the stuff I did worked fine - 3D graphics with OpenGL and SDL2, web services with Hyper and Tokio (recently hit 1.0!), and CLI apps.

If you want to try apt install first, you can do that - It's easy to remove. But personally I do use rustup.

Re: Rust 1.49.0

#65

Post by steveklabnik »

Kinrany wrote: post #62
steveklabnik wrote: post #16

Earlier quoted context omitted.

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…

Do you have any ideas for changing the format, to make it easier to write about these things in a way that lets people read the parts they want? Possibly write about the reasons something was changed and the use cases improved, instead of the changes themselves?

I don't, because I think it is fundamentally impossible. I'm willing to be proven wrong though!

I do try to write about the reasons why and use-cases improved. One of the issues is that that increases the amount of text, which directly goes against the idea of quickly finding what you want.

At the end of the day, if you want to know everything, you have to read everything. There's no shortcuts. I try to highlight the best things that the most people will want to know about, but if you really want to know everything, there's no better way than going straight to the source, like I do to create the post in the first place.

Re: Rust 1.49.0

#66

Post by steveklabnik »

boxmonster wrote: post #55
steveklabnik wrote: post #21

Earlier quoted context omitted.

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

the unwrap_or_else makes a lot more sense, because I could just use the ? operator, but if I don't want to panic, then I'll use unwrap_or_else. I am not by any means an advanced Rust programmer and in fact learning from your book, so I didn't mean to offend anyone. My initial impression of the match syntax for return values was that I didn't like it. Sorry.

It's all good!

Re: Rust 1.49.0

#67

Post by Galanwe »

Any chance to see increased support for 8bit AVR in upcoming releases?

I know Rust is community driven, so it's not like contributions will appear from thin air. But I guess maybe it would be time to promote/incentivize people to contribute support for microcontrollers. This is a realm where C reigns and Rust would be a bowl of fresh air.

Re: Rust 1.49.0

#68

Post by gamegoblin »

alpaca128 wrote: post #37
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.

What I tend to stumble over is how String and &str each have some methods and features that the other lacks, e.g. concatenation. Which of course makes sense with basic understanding of string slices, but sometimes I can't shake the weird feeling that I'm cloning some String unnecessarily. And I just wish generic type parameters wouldn't have to be propagated through all types touching them. That said I'm really happy…

The methods on `String` should be a strict superset of the methods on `str` because `String` dereferences to `str`, thus `String` gets all of the `str` methods for free.

If you're familiar with say, `Vec` and `[u8]`, `String` and `str` are basically the same except they are contractually valid UTF bytes. So just like you can `push` and `extend` to a `Vec`, you can do the same to a `String`.

With regard to generic type parameters, if you want to code in Java or Go style, you can use dynamic dispatch trait objects to remove type parameters.

Re: Rust 1.49.0

#69

Post by pjmlp »

steveklabnik wrote: post #54
ufo wrote: post #51

A question for the Rust crowd, from someone who's thinking about giving Rust another chance in 2021: Last time I tried getting into Rust, some years ago, the recommended way to install it was to use the rustup tool. You were also kind of expected to learn using the "nightly" version of the language, because much of the documentation and stackoverflow answers depended on that. Is this still the case now that we're abo…

Regarding nightly: https://blog.rust-lang.org/2020/12/16/rust-survey-2020.html > the number of users who are relying on a nightly compiler at least part of the time continues to drop - down to 28% compared with last year’s 30.5% with only 8.7% of respondents saying they use nightly exclusively. When asked why people are using nightly the largest reason was to use the Rocket web framework which has announced it will w…

Basically nightlies are just like the "preview" features in Java, .NET and C++ ecosystems, or import from future in Python.

Re: Rust 1.49.0

#70

Post by steveklabnik »

Galanwe wrote: post #67

Any chance to see increased support for 8bit AVR in upcoming releases? I know Rust is community driven, so it's not like contributions will appear from thin air. But I guess maybe it would be time to promote/incentivize people to contribute support for microcontrollers. This is a realm where C reigns and Rust would be a bowl of fresh air.

Folks are still working on it, yep.

I mean, Rust does have support for many microcontrollers. I do ARM stuff for work, for example. Just not AVR. It'll be nice to have it though!

Post reply on HN