Why your first Rust FizzBuzz implementation may not work

Post by acqq » Mon, Oct 13, 2014, 6:59 AM UTC

sillysaurus3 wrote: post #26

icedog wrote: post #20

Putting the String issue aside, I just wanted to show the beauty of pattern matching. for i in range(1i, 101) { match (i % 3, i % 5) { (0, 0) => println!("Fizzbuzz"), (0, _) => println!("Fizz"), (_, 0) => println!("Buzz"), _ => println!("{}", i), } } -- edited: removed `.to_string()`, thanks chrismorgan

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…

Post by minikomi » Mon, Oct 13, 2014, 7:06 AM UTC

icedog wrote: post #34

kyllo wrote: post #31

Earlier quoted context omitted.

Weird to see this mix of a very imperative for-range iterative loop with a very functional pattern match, which makes it look similar to an SML or OCaml solution to FizzBuzz. I guess this is the definition of multi-paradigm right here. Will Rust's type checker warn you of a non-exhaustive pattern match?

Here's the same approach in F# without the different types of String; therefore, easier to get more functional. let fizzbuzz num = match num % 3, num % 5 with | 0,0 -> "FizzBuzz" | 0,_ -> "Fizz" | _,0 -> "Buzz" | _,_ -> num.ToString() [1..100] |> List.map fizzbuzz |> List.iter (fun (s:string) -> printfn "%s" s)

    #lang racket
    
    (define (fizz-buzz n)
      (match (list (modulo n 3) (modulo n 5))  
          [(list 0 0) "FizzBuzz"]
          [(list 0 _) "Fizz"]
          [(list _ 0) "Buzz"]
          [_          n]))
    
    (for [(i (range 100))]
      (displayln (fizz-buzz i)))

Post by dbaupp » Mon, Oct 13, 2014, 7:16 AM UTC

chrismorgan wrote: post #74

acqq wrote: post #71

Earlier quoted context omitted.

It can be that _ for any is less expected than a star or a dot would be. We're used to the star in shells and the dot in regexps for decades already. (0, *) seems more obvious in that example than (0, _) but at least we are used to ____ in the forms printed on paper too.

Just as a point of interest: in these cases, (0, ..) would also work, where .. means “any number of elements”.

Post by Daishiman » Mon, Oct 13, 2014, 7:26 AM UTC

burntsushi wrote: post #4

dbaupp wrote: post #3

Earlier quoted context omitted.

> it's so much faster and shorter to write This is not obviously true to me, Rust provides more tools for building abstractions, even just "handle errors less manually"-abstractions, so they're possibly not that different (this certainly applies to the 'shorter' section). I guess it may be true for the things Go is suited/designed for; time and experience will tell.

Anecdotes and personal opinions follow. I'm pretty happy with the speed at which I write Rust code, but I can definitely churn out Go code more quickly. (Probably on the order of how quickly I can write Python, although refactoring Go code is much faster.) I'm not sure exactly why, but my guess is that there are fewer abstractions to deal with (and fewer opportunities to make abstractions). I have written several med…

Post by bjz_ » Mon, Oct 13, 2014, 7:39 AM UTC

steveklabnik wrote: post #67

bjz_ wrote: post #49

Earlier quoted context omitted.

Rust was first conceived by an avid Ocamler, and it was originally implemented in Ocaml too. Although the pot has been stirred quite a bit since those early days, the influence still remains, including the expression heavy programming style, pattern matching, 'let's, HM inference, and `var: T` declaration syntax. Whilst Rust is quite procedural and (you rarely use recursion), it often feels quite functional due to th…

Small note, technically Rust never did HM, and now we _certainly_ don't. It's still inference, just not that algorithm.