Live data from Hacker News

Rust 1.49.0

blog.rust-lang.org

71–80 of 117 posts

Re: Rust 1.49.0

#71
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.

32 bit microcontrollers are well-supported, and often cheaper, more power efficient and with more features than old 8-bit uCs.

https://github.com/rust-embedded/wg

Re: Rust 1.49.0

#72

Earlier quoted context omitted.

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.

Definitely not bait because I like to jump around with languages so it's natural for me to compare them (that's why I do it.) I wrote my web server in Go, my util to find duplicate directories in Rust, etc.. I wasn't saying C# is faster than Rust, I said C# got faster.

Re: Rust 1.49.0

#73

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…

"I recently wrote a utility for myself in ASM after having done several in C. I like both languages, but ASM introduces pain points for no apparent reason."

IMO the_duke summarized it perfectly in other comment: You are essentially complaining that Rust is not C#; Rust is much lower level and makes very different tradeoffs; most of the design decisions are there for a reason, and are good choices (https://news.ycombinator.com/item?id=25593825)

People considering Rust as an alternative for higher-level programming languages are in for a potential surprise or two. I guess this happens because Rust has received a lot of attention and promotion, enough to make some people consider it, where otherwise they wouldn't have thought of using tools that stand at a lower level than what is most appropriate for their needs (or knowledge).

EDIT: I've now read that in this particular case, the parent commenter is consciously playing with different languages to learn about them. Still, I think it would be a misconception to think that C# and Rust are at an equivalent level of programming abstraction, and thus should offer similar ergonomics.

Re: Rust 1.49.0

#74
post #62

Earlier quoted context omitted.

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…

You don't want to sign Lin Clark for doing helping write these? If we could dream :)

I was imagining something spatial, a drawing, a map, something that makes it possible to overview and place the new features in context with each other. Probably nothing that can be realized.

Re: Rust 1.49.0

#75

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)

It sounds like your definition of stable applies to a very limited set of programming languages. The only thing I can think of that would fit that definition is C.

Have you seen how many new features have been added to C++20? (which is probably the closest language to Rust) Not to mention any of the dynamically typed languages.

Re: Rust 1.49.0

#76

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 no love for global/static variables? I know they are prone to be misused

Rust doesn't deal with "prone to misuse" but "provably safe, else explicitly unsafe, or made safe by the programmer through wrapping code." Global variables are inherently unsafe and need to be wrapped as such.

Of course you'll need global state at some point in your life. What Rust does is yell to remind you that it isn't thread safe.

If you stop thinking about a Rust program as a script where the runtime figures the hard stuff out for you, then these design decisions make a lot more sense. You have a lot more knobs to twiddle than in C#, no garbage collector, and no runtime. The compiler is pretty smart, but it tells you the things it knows and you're responsible for working around the limitations to create sound programs that the compiler can optimize.

Re: Rust 1.49.0

#77
post #74

Earlier quoted context omitted.

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…

You don't want to sign Lin Clark for doing helping write these? If we could dream :) I was imagining something spatial, a drawing, a map, something that makes it possible to overview and place the new features in context with each other. Probably nothing that can be realized.

Lin is fantastic, don't get me wrong :)

Re: Rust 1.49.0

#78

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)

It sounds like your definition of stable applies to a very limited set of programming languages. The only thing I can think of that would fit that definition is C. Have you seen how many new features have been added to C++20? (which is probably the closest language to Rust) Not to mention any of the dynamically typed languages.

Elixir is stable in that sense as well. Which IMO is very nice as I don't feel I have to relearn the language if I leave for 2 years, and I have to rewrite a 2 years old project to make use of any new idiom and syntax sugar.

Re: Rust 1.49.0

#79
post #52
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…

Stable rust is perfectly fine. The vast majority of Rust users are on stable only.

Unless you want to try out Rocket. That one STILL requires nightly...

Re: Rust 1.49.0

#80
post #52

Earlier quoted context omitted.

Stable rust is perfectly fine. The vast majority of Rust users are on stable only.

Unless you want to try out Rocket. That one STILL requires nightly...

Rocket 0.5 (which is coming soon) will compile on stable. Alternatively, you can the master git branch directly. Very few libraries still require nightly. Most of them have moved or are moving to stable.
Post reply on HN