3 ms·
This is good advice. Write simple code first. Another generic thing I've come across is, "if the borrow checker is screaming at me when I hit a patch of code, I
by crabbygrabby 4y ago
This is good advice. Write simple code first. Another generic thing I've come across is, "if the borrow checker is screaming at me when I hit a patch of code, I probably have a design flaw not a programming problem".
I've seen a lot of new people also prematurely over generalizing code. I know it sounds terrible to say, but if you probably aren't going to reuse it, you really don't have to prepare your code base just in case you might later. Decide that later and move along...
- FpUser 4y ago>"if the borrow checker is screaming at me when I hit a patch of code, I probably have a design flaw not a programming problem". This reminds me: "you are holding it wrong"
- estebank 4y agoIn industrial machines, there's such a thing as holding it wrong. In some cases, that means getting maimed (that old-school table saw doesn't care whether it chews on wood or flesh) or precluded through a clunkier mode of operation (you need to press these two buttons separated at roughly arm length to make sure that they can't be actioned while you have an arm in the way of the heavy arm-eating chunk of metal). The former is C and unsafe Rust, the later is safe Rust and GC languages. You're trying to draw a comparison with a consumer product with a design flaw.
- FpUser 4y ago>"You're trying to draw a comparison with a consumer product with a design flaw." Not at all. I just do not like to dance around bonfire with tam-tam and being told that this is the one and only way
- kaba0 4y agoIt's not the only way, but if you do the tradeoff of going with manual memory management, then you should accept what the tradeoff entails. Essential complexity is non-reducible -- you either manage it automatically through a GC or choose a model that while let you ignore it quite often, will make you think about it in the end.