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

101–110 of 139 posts

Re: Why your first Rust FizzBuzz implementation may not work

#101

Post by [deleted] »

steveklabnik wrote: post #97
sillysaurus3 wrote: post #93

Earlier quoted context omitted.

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)

[deleted]

Re: Why your first Rust FizzBuzz implementation may not work

#102

Post by Argorak »

mhaymo wrote: post #96
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

They plan an aggressive release schedule, though:

http://blog.rust-lang.org/2014/09/15/Rust-1.0.html#release-p...

So they could come in one of the post 1.0 releases and that could possibly be soon.

Re: Why your first Rust FizzBuzz implementation may not work

#105

Post by [deleted] »

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)

[deleted]

Re: Why your first Rust FizzBuzz implementation may not work

#106

Post by dbaupp »

hoeppnertill wrote: post #94
chrismorgan wrote: post #27

Earlier quoted context omitted.

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 n…

Thanks for noticing that! I filed https://github.com/rust-lang/rust/issues/17999

Re: Why your first Rust FizzBuzz implementation may not work

#107

Post by heinrich5991 »

Robadob wrote: post #103

I've always liked this c++ implementation of FizzBuzz, its not the most clear or logical but its short; const char* outs[] = { "%d\n", "Fizz\n", "Buzz\n", "FizzBuzz\n" }; for (int i = 1; i

Is that allowed by the standard? (Passing a parameter to `printf` but not referencing it, in the non-"%d\n" case?)

Re: Why your first Rust FizzBuzz implementation may not work

#108

Post by kibwen »

steveklabnik wrote: post #82
bjz_ wrote: post #79

Earlier quoted context omitted.

Oh - I thought it was a variant on HM, extended for region inference?

I'm not _totally_ sure, but I do know when I tried to reference HM in the docs I got yelled at... and now I'm pretty sure we do http://smallcultfollowing.com/babysteps/blog/2014/07/09/an-e...

It wasn't strictly HM, as it had extensions for the subtyping that lifetimes require. It was based on HM, however.

The new bespoke scheme gives approximately the same results as HM but is drastically simpler. For all I know this could inhibit Rust's future ability to do even more powerful things with types, but AIUI this scheme has the advantage of being actually decidable given the extensions to HM that we would require in the current language.

I ain't a type theorist though, so take this as hearsay. :)

Re: Why your first Rust FizzBuzz implementation may not work

#109

Post by kibwen »

bjz_ wrote: post #51
wycats wrote: post #42

Earlier quoted context omitted.

Yes. It's a design bug that String and slice don't share a common trait and that `.as_slice()` is common simply to use slice methods. I expect that to be fixed before 1.0.

At least you can now do: foo[].some_slice_method()

I think this is an anti-pattern. I'm not a fan of the slicing syntax in general, which seems to exist only to paper over the missing traits that wycats mentions.

Re: Why your first Rust FizzBuzz implementation may not work

#110

Post by dbaupp »

kibwen wrote: post #109
bjz_ wrote: post #51

Earlier quoted context omitted.

At least you can now do: foo[].some_slice_method()

I think this is an anti-pattern. I'm not a fan of the slicing syntax in general, which seems to exist only to paper over the missing traits that wycats mentions.

We will almost certainly just have `Deref for String` and so autoderef will handle `some_string.some_slice_method()` correctly.
Post reply on HN