Rust is becoming a necessary evil, but it's still evil. I mention this looking at the way various projects parse data. They love to overuse language abstractions when parsing needs to be concrete.
"Parsing data" is where you take bytes from the network or a file and interpret them. They usually conform to some sort of specification. Good parsers are those that clearly follow the specification. Bad parsers are those seeking some ineffable elegance, hiding details.
There are a lot of academic programmers who don't solve real-world problems, but instead cherry pick prototypes to show off the elegance of their favorite language. They view programming as some sort of poetry.
The other side of the coin are working programmers who are given problems not of their own choosing. They can't fit the problem to conform to the language, but solve the problem as given.
We need a good memory/type safe systems programming language. Rust is currently the best option for this. Yet, it's afflicted by the worst sort of academic disease that avoids solving real problems in favor of writing poetry.
"Systems programming", btw, means "assembly language". When you do systems programming in C it means using it as a portable assembly language. The thing you are abstracting with C is the hardware. As you write code, you think in terms of how it'll be expressed in assembly.
Higher level abstractions are fine, too, as long as you can still visualize the concrete implementation. A good example is tail recursion, where you write with the abstraction of "recursion" knowing it'll compile down to a "loop".
This is especially important for network protocols and file formats. You need to visualize how it matches the specification. If you can't compare the code against the spec to verify correctness, you have a problem.
