5 ms·
Which -in my opinion- is a lot clearer than the Rust code in the article.
by kutkloon7 10y ago
Which -in my opinion- is a lot clearer than the Rust code in the article.
- thenewwazoo 10y agoThat's totally fair, but that may have something to do with how well you know Rust. I obviously don't know your familiarity level, but once your mental models "snap" out of thinking about moving data around, and start thinking about operations upon the data, it gets really intuitive.
- deleted 10y ago[deleted]
- khedoros1 10y agoI've seen Rust written in imperative style, and it was clear to me in most of the cases. I think it's more the difference between imperative and functional styles that's throwing people for a loop.
- Gankro 10y agoYeah this is clearly someone who's into FP. If you rewrite this code to replace the map/sum with a for loop it's basically identical in length, while being completely idiomatic.
- bluejekyll 10y agoIt took me some tome to embrace this style in Rust, but now o love it. It cuts down on boiler plate code.
- AnimalMuppet 10y ago> I think it's more the difference between imperative and functional styles that's throwing people for a loop. Pun intended? If so, nicely done.
- kutkloon7 10y agoI am familiar enough with functional programming patterns. I could probably understand this if I had some more experience with Rust. But I think I would be able to understand the snippet in most imperative and functional languages. My point is not that the snippet is bad, just that Rust feels, looks, and probably is, quite complex. As opposed to, for example, Haskell, which also introduced a bunch of nice, new, ideas.
- Sean1708 10y ago> Rust feels, looks, and probably is, quite complex. As opposed to, for example, Haskell Do you really think that Haskell is less complex than Rust, or am I just reading your comment wrong?
- shmageggy 10y ago> I am familiar enough with functional programming patterns. Really? I've never used rust but the code was pretty clear to me except for the >> shift part. > But I think I would be able to understand the snippet in most imperative and functional languages. In Python (ignoring the shift thingy) I'd write prediction = sum(map(lambda c, s: c*s, zip(coefficients, buffer[i-12: i]))) To me, both are equally clear
- imron 10y agoOn the other hand, the Rust code is guaranteed at compile time to be free from buffer overruns, off-by-one errors, and a whole host of other nasties. I know, I know, the C code you write never has buffer overruns, just like the C code I write never does, well, except that one time, but then I caught it in the debugger during testing and it was easy to fix. Oh, and then that other time, but I caught that one too, and then.....
- bluejekyll 10y agoYou forgot about the time you forgot to zero the memory before using it, and it took a week to track down the random junk appearing in you data.
- imron 10y ago> you forgot to zero the memory before using it Nah, I did that on purpose because I remember the time I accidentally swapped the 'value' and 'size' parameters of memset, trashing the stack, and so now I go the 'safer' option to just leave things uninitialised. Not to mention the performance increase I get from avoiding a memset that isn't necessary, so long as I'm really, really careful and never make a mistake, which I almost never do.
- sqeaky 10y agoI love how a type safe memset that distinguished between size types and value types would have fixed your problem (with no run time overhead), but you take this a reason to do even more unsafe stuff that has dubious costs for dubious advantages. And I cannot tell if you are serious, trolling or sarcastic, because I know people who think this way, think this way is a joke and think this way is the bane of their professional lives.
- imron 10y agoNot being serious, but joking based on real life things have have bitten me at one point or another, and the mindset of some developers dismissing the benefits of safety and caring about mostly non-existent speed benefits.