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

81–90 of 117 posts

Re: Rust 1.49.0

#81

Post by nobleach »

adkadskhj wrote: post #63
boxmonster wrote: post #55

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.

The railway error-handling paradigm is superior (in my mind) to the common try/catch/throw pattern in many other languages. It promotes errors to first class citizens. It's a monadic pattern that many functional programmers like to employ.

Re: Rust 1.49.0

#82

Post by adkadskhj »

boxmonster wrote: post #72
adkadskhj wrote: post #63

Earlier quoted context omitted.

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.

> I wasn't saying C# is faster than Rust, I said C# got faster.

Ah gotcha - my mistake :)

Re: Rust 1.49.0

#83

Post by brundolf »

gamegoblin wrote: post #68
alpaca128 wrote: post #37

Earlier quoted context omitted.

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 ty…

> The methods on `String` should be a strict superset of the methods on `str` because `String` dereferences to `str`

I've found that sometimes this doesn't happen automatically (at least when passing as an argument; maybe not when calling methods). i.e., you have to explicitly call .as_str() in some situations. Even as someone who's comfortable with the String/&str distinction and moderately familiar with Rust, it's not clear to me where this is and isn't necessary. The compiler just tells me when I make the wrong guess.

Re: Rust 1.49.0

#84

Post by Scuds »

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…

even the rust-analyzer plugin for plugin for VSCode installs and runs without any fuss, definite improvement from when I last saw it in 2019.

Re: apt install - I never trust the OS packages for anything like developer tools, I'd rather have everything run out of my home directory. Then again, I'm not a C/C++ developer where the OS, libraries, build tools are all intertwined.

Re: Rust 1.49.0

#85

Post by lights0123 »

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.

Rust has full support for AVR, excluding function pointers due to current LLVM bugs. Building on stable would be nice though, as it currently requires a custom target JSON file.

Re: Rust 1.49.0

#86

Post by ragnese »

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've been using Rust since 2016 and I've never installed a nightly version for code I was writing. (I did install nightly for some code completion tool or something back in the day. Maybe Racer?)

I think it's still recommended to use rustup.

Re: Rust 1.49.0

#87

Post by aldanor »

brundolf wrote: post #83
gamegoblin wrote: post #68

Earlier quoted context omitted.

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 ty…

> The methods on `String` should be a strict superset of the methods on `str` because `String` dereferences to `str` I've found that sometimes this doesn't happen automatically (at least when passing as an argument; maybe not when calling methods). i.e., you have to explicitly call .as_str() in some situations. Even as someone who's comfortable with the String/&str distinction and moderately familiar with Rust, it's…

Maybe read a bit on Deref: https://doc.rust-lang.org/std/ops/trait.Deref.html

Any time you have a &String reference, it triggers coercion to &str.

Re: Rust 1.49.0

#88

Post by ragnese »

j1elo wrote: post #73
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…

"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.ycomb…

It's funny. Rust is a strange beast. It's a low level language. But, in some specific ways, it's more expressive than a lot of popular high level languages: traits are sometimes nicer than interfaces, strong concurrency guarantees are great compared to the nightmare of parallel processing in e.g., Java, discriminated unions with pretty good pattern matching is missing from many popular high level languages.

You still have languages that can't (really) even do async/threaded computation (Python, PHP, JavaScript/Node can't do threads AFAIK).

I've said this before: "Rust is the highest level low level language I've ever used. Java is the lowest level high level language I've ever used."

Re: Rust 1.49.0

#89

Post by sitkack »

dbrgn wrote: post #71
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.

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

That is true but there are literally millions of AVR based Arduinos out in the world and I can confirm that they are totally usable with Rust.

Re: Rust 1.49.0

#90

Post by hu3 »

jcelerier wrote: post #29
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 ?

in terms of cognitive load, yes
Post reply on HN