Not that I don’t like those chainings. Is quite powerful once you got it. Using it with JavaScript and TypeScript for a long time. And also like those aspects in Rust. On the otherhand, I like the clear - and more verbose way - of C and Go. Gives another form of power of your code.
I’m totally amazed what the Rust compiler does with those chains. There were some tests of one student here, that it not even is a difference of using multiple filters or make one filter with multiple conditions. For Go those optimizations are just not intended. So you mostly optimize by writing different code.
I sympathize with this. But it only works for short chains / ‘small’ concept compositions / simple problems.
The main point of abstraction is not to make the simple even easier. Rather, it is to allow you to add more links / layers / complexity without losing your bearings. (Example: throw a few conatMaps in that iterator chain and witness your preference shift.) That is, abstraction lets you see further, not necessarily more keenly.
Abstraction is hard to sell: those without it are not able to see the benefits, because they cannot see far enough, because they aren’t using the abstraction. See also: Blub paradox (and co-Blub).
I may be overlooking something here, but I don’t think it’s that impressive. It’s mainly just in-lining, which you can do mindlessly yourself, and then eliminating operations that cancel each other (e.g. wrap in a struct → immediately unpack) and concatenating bodies of similar loops, and such. I suspect2 that the Rust compiler does not do anything here that you, a Go developer, do not already do fairly regularly.
(Which does make me wonder a bit: why does the Go compiler not do this as well? Will it when you ask nicely?)
Not that it isn’t nice of course. It is! See also that leap example above: the lambda version produces the same assembly as the original.
I would claim, Go is way more on the C side of its philosophy. You get what you write. And that’s usually quite predictable. Except of some inlining Go can do, it usually cares about your original structure. Even struct alignment is optimized per default with Rust, which isn’t the case for Go.
But I don’t think someone should wonder about those cases. It’s philosophy. That’s why still more than enough will always prefer C. Others rely on the magic of the compiler. Both worlds are fine and both exist.
At the end, I’m for sure not deep into any compiler. Just some cases I know about. At the end I care more about the result, tested with benchmarks etc. And I guess here the Rust compiler does way more than the Go compiler. For Go, usually you optimize. And that means, especially take care about your data structures because of the GC.
I always try to write code in this way, i.e. to reduce nesting levels, because it greatly increases code readability and maintainability. IMHO, NN + DRY are core values in code quality. Somebody who do not understand the value in nesting less, imagine a code having 20 if’s, 10 try…caches, 5 loops and a pair of “goto’s”. While inspecting such code I could literally get drunk just from the fog in my brains
I know I’m not the only old guy on here, but I’d say a hefty amount of my coding style follows the original video, but not for the reasons cited. My first coding was on a dumb terminal. That meant I had 80 columns and 25 lines. So, I unabashedly cuddle my elses simply because I don’t think an else clause is worthy of 3 lines of my screen real estate.
Likewise, if I have short if or loop, I’ll collapse it to one line. For this reason, I really like Perl’s trailing if/for syntax. I think it is more readable to say “do something IF this is true”.
I also tend to extract longer functions and I agree it is more readable. But again, I originally started doing it to conserve screen space and ensure everything I wanted to see, logic-wise fit on the screen. I don’t need to see all the code related to checking for a valid date format, unless I believe that code is failing. So, in my main area, I just want to see:
die if invalid_date_format($date);
Later, I gave more time to readability by carefully considering variable and function/method names. Now-a-days, when I refactor to make code more readable, I don’t mean readable as in an “easy to follow the logic” per se, but rather in a readable as if it were a book sort of way.
Is quite powerful once you got it. Using it with JavaScript and TypeScript for a long time. And also like those aspects in Rust. On the otherhand, I like the clear - and more verbose way - of C and Go. Gives another form of power of your code.
