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

61–70 of 85 posts

Re: Learning Rust via Advent of Code

#61

Post by TotempaaltJ »

steveklabnik wrote: post #46
Twirrim wrote: post #41

Earlier quoted context omitted.

I've been using Kattis problems as a way to work on my Rust skills. The problem there is you're limited to the standard library. Rust's ultra-minimal stdlib makes a number of those kattis problems remarkably hard to implement, where I've managed to whip up something in short order in Python using the stdlib. I keep thinking that Rust has gone a little too far on the "keep it minimal" front. It also really disturbs me…

Part of what we do to balance this out is to have the team make some of those third party packages; the regex crate is a good example of that. It’s still maintained by the team even if it’s not in the standard library itself.

So then why isn't the regex lib part of the standard library?

Re: Learning Rust via Advent of Code

#62

Post by richardwhiuk »

TotempaaltJ wrote: post #61
steveklabnik wrote: post #46

Earlier quoted context omitted.

Part of what we do to balance this out is to have the team make some of those third party packages; the regex crate is a good example of that. It’s still maintained by the team even if it’s not in the standard library itself.

So then why isn't the regex lib part of the standard library?

The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust.

Besides the impact of not being in stdlib is very low except for discovery.

Re: Learning Rust via Advent of Code

#63

Post by eridius »

general_pizza wrote: post #43

I also thought regex seemed overkill and didn't feel like adding an extra crate to my Cargo.toml. Luckily for the days I attempted I was able to get by on just the split method for str's[0] which was nice and concise. So for your regex example you could also do: // #1 @ 916,616: 21x29 let parts: Vec = l.split(['@', ',', ':', 'x'].as_ref()).collect(); let x = parts[1].trim().parse:: ().expect("x as i32"); let y = part…

> and didn't feel like adding an extra crate to my Cargo.toml

Why not? cargo makes it extremely easy to add new crates. The hardest part is figuring out what dependency you want, but once you know what it is, adding it is really easy.

Re: Learning Rust via Advent of Code

#64

Post by davidhyde »

justwalt wrote: post #27
the_duke wrote: post #21

Earlier quoted context omitted.

Rust is a bit like Haskell: a very strong but also complicated type system that enables you to encode a lot of the logical restrictions into the API. This is most notable immediately around the Result and Option types with their many modifiers (map, map_err, and_then, ...) and how strings work. This can feel pretty awkward and cumbersome compared to other languages and that could be what you are describing. It's not…

“If it compiles, it probably works.” This has been so true in my experience. I find that it does take longer overall to write something in Rust, but I almost never have to root out strange errors from my code. In shorter files, I almost never have to use ‘cargo run --debug’ twice.

I second that! I wrote a small service for a friend the other day. It had to read some bytes off a tcp stream in a certain format and route them onto an obscure protocol called a modbus. Given a screenshot of some sample input data from an excel spreadsheet and some other minimal information about the target destination format and address I was able to make the service without having access to a real input tcp stream or the destination hardware required for the modbus. However, to our amazement the software ran without fault the first time it was executed on the target server. Sure I struggled to compile it because I am still a beginner but that has just never happened to me before in my professional career with c#. There is always some side case I haven’t thought about no matter how many unit tests I write! Maybe I got lucky but it definitely had nothing to do with my skills with rust which are still basic.

Re: Learning Rust via Advent of Code

#65

Post by Twirrim »

richardwhiuk wrote: post #62
TotempaaltJ wrote: post #61

Earlier quoted context omitted.

So then why isn't the regex lib part of the standard library?

The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust. Besides the impact of not being in stdlib is very low except for discovery.

> The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust.

How often do you see that actually being a problem? Rust releases new versions on a regular cadence. Just how often do you imagine the regex crate actually needs to be updated? Or how about the random number generator crate?

> Besides the impact of not being in stdlib is very low except for discovery.

I always find this an interesting argument. We've seen node.js etc. packages be compromised many times, or even completely vanish (left-pad)? How much confidence can I have that any individual package hasn't been compromised somehow? How much confidence can I have that random dependencies aren't suddenly going to enter my build chain. That left-pad situation was classic. So many things got broken, not because they'd picked up left-pad, but because dependencies of dependencies of dependencies relied on it (and so on down the line...)

There was that situation just a month or so ago where a developer just didn't want to maintain their package any more, had someone volunteer, who then compromised it with a crypto-miner.

Now on top of that licensing gets to be a whole bunch of fun as soon as you step outside the stdlib. For every crate you add, you need to do a licence audit, and for each and every one of its dependents, and its dependents dependents. Amazon, for example, has a black list of licenses. You can't use any software licensed under one of them, for whatever reason the lawyers have about each one.

Re: Learning Rust via Advent of Code

#66

Post by pornel »

general_pizza wrote: post #43

I also thought regex seemed overkill and didn't feel like adding an extra crate to my Cargo.toml. Luckily for the days I attempted I was able to get by on just the split method for str's[0] which was nice and concise. So for your regex example you could also do: // #1 @ 916,616: 21x29 let parts: Vec = l.split(['@', ',', ':', 'x'].as_ref()).collect(); let x = parts[1].trim().parse:: ().expect("x as i32"); let y = part…

The next step could be to remove `.collect()` and use `.next()` for each subsequent part. Zero allocations!

    let mut parts = l.split(&['@', ',', ':', 'x'][..])
       .flat_map(|s| s.trim().parse::().ok());
    let x = parts.next().expect("x as i32");
    let y = parts.next().expect("y as i32");
    let w = parts.next().expect("width as i32");
    let h = parts.next().expect("height as i32");

Re: Learning Rust via Advent of Code

#68

Post by shepmaster »

richardwhiuk wrote: post #62
TotempaaltJ wrote: post #61

Earlier quoted context omitted.

So then why isn't the regex lib part of the standard library?

The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust. Besides the impact of not being in stdlib is very low except for discovery.

> The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust.

More importantly, due to Rust's backwards compatibility guarantees, you can never remove something once it has been added.

I vaguely wave towards Python's 3-5 built-in "get data from a URL" libraries as an example of a bad route that this can take.

The regex crate can release a backwards-incompatible version 2 without destroying the entire ecosystem since multiple versions of a crate can co-exist in the final graph of dependencies.

Re: Learning Rust via Advent of Code

#70

Post by shepmaster »

Twirrim wrote: post #65
richardwhiuk wrote: post #62

Earlier quoted context omitted.

The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust. Besides the impact of not being in stdlib is very low except for discovery.

> The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust. How often do you see that actually being a problem? Rust releases new versions on a regular cadence. Just how often do you imagine the regex crate actually needs to be updated? Or how about the random number generator crate? > Besides the impact of not being in stdlib is very low except for…

> How often do you see that actually being a problem?

See my sibling comment about backwards compatibility

> Just how often do you imagine the regex crate actually needs to be updated?

You can see the frequency of updates to the regex crate if you are interested: https://crates.io/crates/regex/versions.

Sometimes a release in a few days, or a few a month.

> Or how about the random number generator crate?

Even more interesting, because `rand` hasn't even reached 1.0 yet! https://crates.io/crates/rand/versions

Specifically, the authors are still deciding the right way to architect the library for the myriad of uses that Rust has.

> or even completely vanish (left-pad)

In 99.99% of the cases, you cannot remove a crate from crates.io; you can only prevent new projects from adding the crate as a dependency. The other 0.01% is because of legal reasons, and there's not much to be done about that.

> For every crate you add, you need to do a licence audit

https://github.com/onur/cargo-license claims to show you the licenses of every dependency. It's required to have a license to publish to crates.io.

Post reply on HN