As a programmer in a high-level language, you do not need to have your ear to the wire. Just because whatever network-communicable abstraction you use ends up s

As a programmer in a high-level language, you do not need to have your ear to the wire. Just because whatever network-communicable abstraction you use ends up serialized as a sequence of bytes, doesn't mean you should be thinking about byte sequences when communicating in a network. >What is he proposing we do to prevent confusion between strings? Don't use a paradigm where your code can see the strings. If your high-level language only manipulates resources, it can't confuse strings with each other. It also can't manipulate strings to try to access different resources. Sure, at the low level, you'll still be doing communication via bytestrings. But you can keep the footprint of that "core" low-level component small and trustworthy, and let the high level work confidently. An analogy is using a memory-safe language like Java vs C. Java still relies on fast-but-scary code like pointer arithmetic for fast execution, but Java programmers don't need to know about pointers and aren't constantly on the lookout for buffer overflows or other bugs that plague C programs. The guarantees of the JVM let Java programmers do more expressive and saner things, like "take all the even numbers in a list greater than 100".