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

Learning Rust via Advent of Code

forrestthewoods.com

Post reply on HN
Print view View original

71–80 of 85 posts

Re: Learning Rust via Advent of Code

#71

Post by josephg »

nixpulvis wrote: post #57
dtolnay wrote: post #47

> I feel like there should be a helper for simple parse operations. > parse!("#{} @ {},{}: {}x{}", id, x, y, w, h); > This would be a clean inverse of println!. The text_io crate does this exactly. https://crates.io/crates/text_io #[macro_use] extern crate text_io; fn main() { let id: u32; let x: u32; let y: u32; let w: u32; let h: u32; scan!("#{} @ {},{}: {}x{}", id, x, y, w, h); }

I wonder if we'll ever see `scan!` in the STD lib...

I hope not.

With a healthy crate ecosystem, std should be as small as possible (without being too small).

It makes sense for std to contain:

- Types that can't easily be put in a module (eg the `Fn` trait)

- Types needed for cross-project interoperability (like `TcpStream` or `Future`). Having these in std helps prevent ecosystem fragmentation.

- Stuff that gets used in most non-trivial projects (eg `Box`, `Vec`, `println!`)

Everything else belongs in a crate, where it won't bloat up the size of rust's standard library for everyone in perpetuity. `scan!` looks great; but I expect it'll be used in less than 1% of projects. There's no shame in keeping it in a crate - thats what they're for!

Re: Learning Rust via Advent of Code

#72

Post by saghm »

nixpulvis wrote: post #57
dtolnay wrote: post #47

> I feel like there should be a helper for simple parse operations. > parse!("#{} @ {},{}: {}x{}", id, x, y, w, h); > This would be a clean inverse of println!. The text_io crate does this exactly. https://crates.io/crates/text_io #[macro_use] extern crate text_io; fn main() { let id: u32; let x: u32; let y: u32; let w: u32; let h: u32; scan!("#{} @ {},{}: {}x{}", id, x, y, w, h); }

I wonder if we'll ever see `scan!` in the STD lib...

I see this come up a lot for various things in the Rust ecosystem. I think that moving more things into the standard library would actually be a net loss, mainly due to the versioning being tied to that of Rust itself. Once something is moved to the standard library, there can never be any breaking changes unless Rust 2.0 becomes a thing (which currently the core team says is not going to happen). It also makes the burden of doing bugfix releases much higher; for smaller bugs, users will have to wait until the next release of Rust itself, and for larger bugs, the entire language will have to do another release ahead of schedule. Given how easy Cargo makes it to add a dependency and how few projects can't actually use Cargo, I think it's better for the overwhelming majority of the ecosystem to keep things like this out of the standard library.

Re: Learning Rust via Advent of Code

#73

Post by nprateem »

I haven't tried rust in a few years, but I remember it was kind of annoying that you couldn't tell from a function name which parameters would invoke borrow checker stuff. At that time there wasn't great IDE support, but is there a common/idiomatic way of hinting the borrowing of function parameters?

Re: Learning Rust via Advent of Code

#74

Post by jeffdavis »

I use a different approach to learning new languages: I try to find out why the language really exists. Often, there is a very good reason that justifies all the work of creating a new language.

Often, this has more to do with the environment, runtime, etc., and the features of the language merely exist to serve that purpose. If that were not true, someone probably would have used an existing language and changed the runtime.

For rust, it seems to exist to bring modern, safe language features to a minimal C-like runtime existence by doing all of the work in the compiler. C has continued to thrive all of this time because it has a minimal runtime and a stable ABI defined on nearly every platform. Rust has a minimal runtime and supports the C ABI very well, so it has a great chance to have a big impact in areas where C/C++ might otherwise be used less safely and less productively. So my focus when learning rust is how to use the C FFI while still writing idiomatic rust.

It's harder to learn that way, but I find it more satisfying, especially in cases where I don't have an immediate project that's going to use the language. The fact is, no matter how many programming puzzles I solve in rust, it's not going to make it any more likely that I will rely on it for anything but a toy or hobby project. But learning the rust FFI does make it more likely I will rely on it in the future. Puzzles can be solved in any language; weird corner cases in the FFI cannot.

Re: Learning Rust via Advent of Code

#75

Post by Hortinstein »

nprateem wrote: post #73

I haven't tried rust in a few years, but I remember it was kind of annoying that you couldn't tell from a function name which parameters would invoke borrow checker stuff. At that time there wasn't great IDE support, but is there a common/idiomatic way of hinting the borrowing of function parameters?

documentation is much better, here are a few links that should answer your question

https://doc.rust-lang.org/book/ch04-02-references-and-borrow... https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html

Re: Learning Rust via Advent of Code

#76

Post by terhechte »

steveklabnik wrote: post #54
terhechte wrote: post #50

Earlier quoted context omitted.

This is awesome. How did you figure this out? The documentation on `split` says: "The pattern can be a &str, char, or a closure that determines the split." But in your case it is an array of chars and it splits for each of them. I don't see this documented at all.

Would you be willing to file a docs bug so we can clarify this? It’s possible that it used to be only those types, but was expanded. We should fix this!

Yeah, will do

Re: Learning Rust via Advent of Code

#77

Post by gridspy »

steveklabnik wrote: post #53
gridspy wrote: post #52

Earlier quoted context omitted.

Vec or an array for instance - [char; 20] can (automatically) create a "slice" of type &[char]. This is true for all types (not just char). The operator for this is for eg l[1..10]. It can also happen automatically. &str is the same type as &[char] - just a renaming. Still learning Rust myself, apologies if this leads you astray. Just do some reading on slices. https://doc.rust-lang.org/book/ch04-03-slices.html#strin…

&str is not the same as &[char]. &str has the same memory representation as &[u8]. char is four bytes, not one.

Thanks Steve.

Re: Learning Rust via Advent of Code

#79

Post by steveklabnik »

terhechte wrote: post #76
steveklabnik wrote: post #54

Earlier quoted context omitted.

Would you be willing to file a docs bug so we can clarify this? It’s possible that it used to be only those types, but was expanded. We should fix this!

Yeah, will do

Awesome, thank you!

Re: Learning Rust via Advent of Code

#80

Post by Spiritus »

dtolnay wrote: post #47

> I feel like there should be a helper for simple parse operations. > parse!("#{} @ {},{}: {}x{}", id, x, y, w, h); > This would be a clean inverse of println!. The text_io crate does this exactly. https://crates.io/crates/text_io #[macro_use] extern crate text_io; fn main() { let id: u32; let x: u32; let y: u32; let w: u32; let h: u32; scan!("#{} @ {},{}: {}x{}", id, x, y, w, h); }

This is "stolen" from r/rust. But there's also a `scan!` macro in serde_scan[1]

    let line = "#1 @ 555,891: 18x12";
    let parsed = scan!("#{} @ {},{}: {}x{}"
[1] https://docs.rs/serde_scan/0.3.2/serde_scan/macro.scan.html
Post reply on HN