Why your first Rust FizzBuzz implementation may not work
chrismorgan.info
Why your first Rust FizzBuzz implementation may not work
1–10 of 139 posts
Re: Why your first Rust FizzBuzz implementation may not work
#2Re: Why your first Rust FizzBuzz implementation may not work
#3That 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.
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.
Re: Why your first Rust FizzBuzz implementation may not work
#4That 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.
> 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.
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 medium Go applications (near or above 10 KLOC, which ideally, I would never hit in a dynamic language), and I'm pretty happy with how the code turned out in all but one of them. (But that one is a window manager.) I haven't yet written a similarly sized Rust application, though.
I do write Rust code more quickly that I write Haskell code though. :-)
Re: Why your first Rust FizzBuzz implementation may not work
#5 for i in range(1, 101):
print('FizzBuzz' if i % 15 == 0 else 'Buzz' if i % 5 == 0 else 'Fizz' if i % 3 == 0 else i)
python doesn't have expressions? oh dear me.Re: Why your first Rust FizzBuzz implementation may not work
#6for i in range(1, 101): print('FizzBuzz' if i % 15 == 0 else 'Buzz' if i % 5 == 0 else 'Fizz' if i % 3 == 0 else i) python doesn't have expressions? oh dear me.
Moreover, the code you've presented here certainly isn't idiomatic, which counts for something.
Re: Why your first Rust FizzBuzz implementation may not work
#7for i in range(1, 101): print('FizzBuzz' if i % 15 == 0 else 'Buzz' if i % 5 == 0 else 'Fizz' if i % 3 == 0 else i) python doesn't have expressions? oh dear me.
The OP's characterization is reasonably accurate in my experience . I've run into several Python programmers who didn't actually know about Python's special "if expression" syntax. Moreover, the code you've presented here certainly isn't idiomatic, which counts for something.
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
'Fizz' if i % 3 == 0 else
i)
there's also a suspicious "return" at the end of the second code segment which mysteriously appeared some time after the first one; looks like the author was trying a little too hard to differentiate python and rust.Re: Why your first Rust FizzBuzz implementation may not work
#8Earlier quoted context omitted.
The OP's characterization is reasonably accurate in my experience . I've run into several Python programmers who didn't actually know about Python's special "if expression" syntax. Moreover, the code you've presented here certainly isn't idiomatic, which counts for something.
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…
Re: Why your first Rust FizzBuzz implementation may not work
#9Earlier quoted context omitted.
The OP's characterization is reasonably accurate in my experience . I've run into several Python programmers who didn't actually know about Python's special "if expression" syntax. Moreover, the code you've presented here certainly isn't idiomatic, which counts for something.
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…
Re: Why your first Rust FizzBuzz implementation may not work
#10That 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.
The reality is that people have very little time to try out new languages, and have to rely on anecdotes about the long-term cognitive costs of things like this.
My personal experience is that many of the seemingly more-onerous things about Rust end up falling away once the rhythm of programming sets in.
This is likely similar to how the error-handling approach of Go looks onerous at first, but seems to be something that doesn't slow people down too much in practice.