• 1 Post
  • 11 Comments
Joined 11 months ago
cake
Cake day: August 2nd, 2023

help-circle


  • 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(())
    }
    



  • m_f@midwest.socialtoProgrammer Humor@programming.devGolang be like
    link
    fedilink
    arrow-up
    20
    arrow-down
    2
    ·
    11 months ago

    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.




  • m_f@midwest.socialtoProgrammer Humor@programming.devGolang be like
    link
    fedilink
    arrow-up
    87
    arrow-down
    3
    ·
    11 months ago

    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.