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

Why your first Rust FizzBuzz implementation may not work

chrismorgan.info

Post reply on HN
Print view View original

91–100 of 139 posts

Re: Why your first Rust FizzBuzz implementation may not work

#91

Post by shurcooL »

retroencabulato wrote: post #72
shurcooL wrote: post #2

That was informative... and it reinforced my perception of Rust as something to look into if I ever have to do something that absolutely necessitates the use of something low level like C++/Assembly. But for everything else that I can get away with (and that is a lot so far) I'll stick with Go because it's so much faster and shorter to write.

If something absolutely necessitates using C++, why not use C++? (I'm genuinely asking.)

Because writing and compiling code/projects in it is very painful. Header files, custom makefiles, etc.

Re: Why your first Rust FizzBuzz implementation may not work

#93

Post by sillysaurus3 »

steveklabnik wrote: post #65
sillysaurus3 wrote: post #26

Earlier quoted context omitted.

I guess beauty is in the eye of the programmer. I'd choose Python's or Ruby's FizzBuzz. It's beautiful that everyone can immediately understand those. This one, not so much. As a little experiment, I've deliberately avoided learning Rust to see if I can understand its idioms without reading any docs. I can sort of guess at what's going on here by reverse engineering what should happen with FizzBuzz, but it's not at a…

> As a little experiment, I've deliberately avoided learning Rust to see if I can understand its idioms without reading any docs. :D If you have the time, as you do this, I'd love to hear about your experience. Email me any time. (I maintain Rust's docs, and am also starting to write some introductory curriculum. Hearing from people like you is _invaluable_.)

Oh, okay! Cool! I didn't realize it'd be valuable to anyone. I'll try to put together something for you, and I'll take it seriously so that it isn't biased one way or the other. I have some stuff coming up, but after seeing some incredibly neat stuff written in Rust, I'm planning on doing a project myself, and I'll email you with a raw braindump of my first experiences with the language, along with a list of previous languages I've learned as well as my experience level with each. Thank you for maintaining Rust's docs!

Re: Why your first Rust FizzBuzz implementation may not work

#94

Post by hoeppnertill »

chrismorgan wrote: post #27
sillysaurus3 wrote: post #26

Earlier quoted context omitted.

I guess beauty is in the eye of the programmer. I'd choose Python's or Ruby's FizzBuzz. It's beautiful that everyone can immediately understand those. This one, not so much. As a little experiment, I've deliberately avoided learning Rust to see if I can understand its idioms without reading any docs. I can sort of guess at what's going on here by reverse engineering what should happen with FizzBuzz, but it's not at a…

It’s whether (i % 3, i % 5) is equal to (0, 0) et al., where _ means “any value”.

To be fair, you can bind to any name. So, binding to `a` instead of `_` would work as well. You could then use that bound value in the corresponding expression.

However, I would have expected rustc to complain about unused variables in

    fn main() {
        for i in range(1i, 101) {
            match (i % 3, i % 5) {
                (0, 0) => println!("Fizzbuzz"),
                (0, a) => println!("Fizz"),
                (b, 0) => println!("Buzz"),
                c => println!("{}", i),
            }
        }
    }
but neither the playpen nor yesterdays snapshot complains. And if you want to suppress warnings about unused variables, you prefix the variable with an underscore, or just use only the underscore, which got common to mean "I don't care what value gets bound to this name.".

    fn main() { let a = 0u; }
compiles with warning: unused variable: `a`, but

    fn main() { let _a = 0u; }
compiles silently.

Re: Why your first Rust FizzBuzz implementation may not work

#95

Post by lmm »

Scala guy here. This kind of thing is useful - I'm happy to pay the costs of garbage collection so I don't need it for ownership, but for separating out async operations from sync operations, or database-transactional operations from non-database operations, it's great to be able to represent that difference in the type system (and without a huge syntactic overhead). But then if you want to abstract over types like MaybeOwned, you need higher-kinded types to be able to work with them effectively. Has Rust got any further towards implementing those?

Re: Why your first Rust FizzBuzz implementation may not work

#96

Post by mhaymo »

lmm wrote: post #95

Scala guy here. This kind of thing is useful - I'm happy to pay the costs of garbage collection so I don't need it for ownership, but for separating out async operations from sync operations, or database-transactional operations from non-database operations, it's great to be able to represent that difference in the type system (and without a huge syntactic overhead). But then if you want to abstract over types like M…

Unfortunately I don't think higher-kinded types are planned for Rust 1.0. See the rfc: https://github.com/rust-lang/rfcs/issues/324 and this HN thread: https://news.ycombinator.com/item?id=7997926

Re: Why your first Rust FizzBuzz implementation may not work

#97

Post by steveklabnik »

sillysaurus3 wrote: post #93
steveklabnik wrote: post #65

Earlier quoted context omitted.

> As a little experiment, I've deliberately avoided learning Rust to see if I can understand its idioms without reading any docs. :D If you have the time, as you do this, I'd love to hear about your experience. Email me any time. (I maintain Rust's docs, and am also starting to write some introductory curriculum. Hearing from people like you is _invaluable_.)

Oh, okay! Cool! I didn't realize it'd be valuable to anyone. I'll try to put together something for you, and I'll take it seriously so that it isn't biased one way or the other. I have some stuff coming up, but after seeing some incredibly neat stuff written in Rust, I'm planning on doing a project myself, and I'll email you with a raw braindump of my first experiences with the language, along with a list of previous…

Great, thanks! (And Mozilla is owed some thanks for paying me, otherwise I wouldnt have nearly as much time to do it)

Re: Why your first Rust FizzBuzz implementation may not work

#98

Post by frankzinger »

shurcooL wrote: post #91
retroencabulato wrote: post #72

Earlier quoted context omitted.

If something absolutely necessitates using C++, why not use C++? (I'm genuinely asking.)

Because writing and compiling code/projects in it is very painful. Header files, custom makefiles, etc.

Pardon me, but 'custom makefiles' have absolutely nothing to do with C++. There are IDEs with C++ support.

Also, while working with headerless languages may be easier, calling working with headers 'very painful' is hyperbole.

Re: Why your first Rust FizzBuzz implementation may not work

#99

Post by burntsushi »

rplnt wrote: post #90
burntsushi wrote: post #8

Earlier quoted context omitted.

I disagree. I think code comparisons should be done using idiomatic code. I personally would not consider chaining `if` expressions like you've done here idiomatic Python.

I don't see a problem with code chosen for each example. What is a problem is explicitly stating that python doesn't have such functionality.

Yes. I responded to this initially above.

Re: Why your first Rust FizzBuzz implementation may not work

#100

Post by steveklabnik »

Erwin wrote: post #89
steveklabnik wrote: post #83

Earlier quoted context omitted.

One difference is that this won't do exhaustiveness checks, where the pattern match will.

Well, here's an exhaustively checking version. Not statically still of course. for x in range(1,101): print [ # %3 = 0 [ x, "Fizz" ], [ "Buzz", "FizzBuzz"] # %5 = 0 ][x%3 == 0][x%5 == 0] (I'll note this was hard to get than if-checks and pattern matching so I won't be replacing such logic with matrices in my Python program any time soon...)

> not statically of course

Right, but that's the point!

Post reply on HN