3 ms·
> Its design anti-goals include complicated compile-time computations, such as macro or type tricks, even at cost of performance degradation. Why? That sounds
by adwn 7y ago
> Its design anti-goals include complicated compile-time computations, such as macro or type tricks, even at cost of performance degradation.
Why? That sounds more like an ideological decision than a pragmatic, engineering-driven one. Especially for a TCP/IP stack, where performance is typically a major concern, be it in a desktop, server, or embedded environment.
- q3k 7y agoIt can be an engineering decision: write readable, easy to understand and reason about code.
- toast0 7y agoMost of the performance of TCP stacks has more to do with the order that comparisons are made for incoming packets (sometimes called fast path -- check for and handle normal packets first), locking of data structures, and congestion strategies (including retransmit behavior, SACK, etc). Macros or typing is less likely to make that faster. For a new stack, though, correctness and readability are more important than performance.
- whitequark_ 7y agoAt the time when I started working on smoltcp, there were a few Rust libraries for working with TCP/IP on the wire level, and they heavily used metaprogramming. Unfortunately, the task of implementing a generic binary protocol serializer/deserializer that can handle TCP/IP is not small, and as far as I could tell, it overtook implementing anything beyond that. So I made the decision to do the simplest possible thing: write the packet serializers/deserializers entirely by hand. It took very little time and adding any new features was easy and predictable. I believe it was the right decision as it allowed me to focus on the hard parts of a TCP/IP stack.
- adwn 7y agoThank you for answering. That sounds sensible, I guess.