If you’re writing code that generic, why wouldn’t you want str to be passed in? For example, Counter('hello') is perfectly valid and useful. OTOH, average_length('hello') would always be 1 and not be useful. OTOOH, maybe there’s a valid reason for someone to do that. If I’ve got a list of items of various types and want to find the highest average length, I’d want to do max(map(average_length, items)) and not have that blow up just because there’s a string in there that I know will have an average length of 1.

So this all depends on the specifics of the function you’re writing at the time. If you’re really sure that someone shouldn’t be passing in a str, I’d probably raise a ValueError or a warning, but only if you’re really sure. For the most part, I’d just use appropriate type hints and embrace the phrase “we’re all consenting adults here”.

The collect’s in the middle aren’t necessary, neither is splitting by ": ". Here’s a simpler version

fn main() {
    let text = "seeds: 79 14 55 13\nwhatever";
    let seeds: Vec<_> = text
        .lines()
        .next()
        .unwrap()
        .split_whitespace()
        .skip(1)
        .map(|x| x.parse::<u32>().unwrap())
        .collect();
    println!("seeds: {:?}", seeds);
}

It is simpler to bang out a [int(num) for num in text.splitlines()[0].split(' ')[1:]] in Python, but that just shows the happy path with no error handling, and does a bunch of allocations that the Rust version doesn’t. You can also get slightly fancier in the Rust version by collecting into a Result for more succinct error handling if you’d like.

EDIT: Here’s also a version using anyhow for error handling, and the aforementioned Result collecting:

use anyhow::{anyhow, Result};

fn main() -> Result<()> {
    let text = "seeds: 79 14 55 13\nwhatever";
    let seeds: Vec<u32> = text
        .lines()
        .next()
        .ok_or(anyhow!("No first line!"))?
        .split_whitespace()
        .skip(1)
        .map(str::parse)
        .collect::<Result<_, _>>()?;
    println!("seeds: {:?}", seeds);
    Ok(())
}

Get pissed at NVIDIA. They’re the problem.

You probably wouldn’t be committing this, unless you’re backing up a heavily WIP branch. The issue is that if you’re developing locally and need to make a temporary change, you might comment something out, which then requires commenting another now-unused variable, which then requires commenting out yet another variable, and so on. Go isn’t helping you here, it’s wasting your time for no good reason. Just emit a warning and allow CI to be configured to reject warnings.

This is the best explanation I’ve ever seen of monads: https://www.adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html

For some reason, you’ll find a lot of really bad explanations of monads, like “programmable semi-colons”. Ignore those, and check out the link.

It’s not a half-arsed copy, it’s borrowing a limited subset of HKT for a language with very different goals. Haskell can afford a lot of luxuries that Rust can’t.

That’s 👏 what 👏 CI 👏 is 👏 for

Warn in dev, enforce stuff like this in CI and block PRs that don’t pass. Go is just being silly here, which is not surprising given that Rob Pike said

Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods. I grew up and today I use monochromatic numerals.

The Go developers need to get over themselves.

Thanks! That’s the sort of thing I’m looking for

Are there any good services like bandcamp, but for video? Even if it doesn’t have blockbuster/popular movies I’d be interested. I spend a lot of money on bandcamp because it’s easy and simple: I give them money and in return get bits that I do what I want with.