Why your first Rust FizzBuzz implementation may not work

Post by wycats » Mon, Oct 13, 2014, 3:47 AM UTC

hrjet wrote: post #41

wycats wrote: post #28

For what it's worth, String in Rust is similar to StringBuffer in other languages. You can append to a String; you can't append to a slice, which always represents a fixed view. A slice has storage that is borrowed from somewhere else, but it itself does not have its own storage. When you type `"foo"`, you are creating "static" storage (in the binary) and the slice is borrowed from that fixed-position location in mem…

But shouldn't they (String and slice) have some common super type to make this all easy to use ?

Post by latkin » Mon, Oct 13, 2014, 4:08 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)

  | _ -> num.ToString()

  |> List.iter (printfn "%s")

Post by kibwen » Mon, Oct 13, 2014, 4:10 AM UTC

hrjet wrote: post #41

wycats wrote: post #28

For what it's worth, String in Rust is similar to StringBuffer in other languages. You can append to a String; you can't append to a slice, which always represents a fixed view. A slice has storage that is borrowed from somewhere else, but it itself does not have its own storage. When you type `"foo"`, you are creating "static" storage (in the binary) and the slice is borrowed from that fixed-position location in mem…

But shouldn't they (String and slice) have some common super type to make this all easy to use ?

  trait WhatIsThis {
      fn what_is_this(self);
  }

  impl WhatIsThis for String {
      fn what_is_this(self) {
          println!("'{:s}' is a string!", self);
      }
  }

  impl WhatIsThis for &'static str {
      fn what_is_this(self) {
          println!("'{:s}' is a string slice!", self);
      }
  }

  fn print_me(me: T) where T: WhatIsThis {
      me.what_is_this();
  }

  fn main() {
      print_me("Blah blah blah");
      print_me("Yada yada yada".to_string());
  }

Post by wycats » Mon, Oct 13, 2014, 4:34 AM UTC

kibwen wrote: post #46

hrjet wrote: post #41

Earlier quoted context omitted.

But shouldn't they (String and slice) have some common super type to make this all easy to use ?

I don't think a common ancestor is how you want to do this. Instead, I'd encapsulate the common behavior in a trait (a.k.a. an interface, in other languages), and then write functions that accept any parameters that implement that trait. In Rust, you can do this even on "built-in" types like strings. For an example, see the `print_me` function below, which operates on both string types using a trait that I've defined…

    def print_me(me: T) where T: Str {
        println!("I am '{:s}'", me.as_slice());
    }

Post by Too » Mon, Oct 13, 2014, 4:36 AM UTC

adamnemecek wrote: post #9

Hello71 wrote: post #7

Earlier quoted context omitted.

sure, but when you're implicitly comparing code segments (by placing them next to each other), you should at least make the effort to make them more the same, instead of pointing out that one language is missing a feature used in the other language, especially when this claim is false. the formatting can of course be improved: for i in range(1, 101): print('FizzBuzz' if i % 15 == 0 else 'Buzz' if i % 5 == 0 else 'Fiz…

yeah, no one writes python like this.