It’s like an engineer who says “how does a screen show black” and then says “nope” to every response. It’s maybe a way to make people think, but beyond that the negativity and grandstanding of it is ultimately a turn off for many receivers which eventually either then has them bully others this way or deters them from the field, depending on how it affects them. There are far better teaching methods that work better for everyone and teach faster and result in higher accuracy and retention.

They have not written a "falsehoods programmers believe" article. They have proposed that one ought to be written and have given a starting point for what it might cover.

They offered their list to "get the ball rolling", confirming that they don't see it as a finished product.

They sent it to other readers of the same forum, who might be expected to have more knowledge of this topic, not to whoever runs across it on the front page of HN.

1-4. Yes we know about the 2 generals problem. And yes we know what "reliable" means in this context. 5-6. This is just stupid. 7. Obviously not true. Nobody thinks this. 8-9. The reasons for and flaws of Nagle's algorithm are well known. 10. This isn't even true. Most of the time you don't need to care about it. That's the whole point of abstraction. You need to care about it if you are doing extensive performance optimisation, but usually you aren't. 11. Again untrue. You can think of TCP as a two way pipe. Again that's the whole point of abstraction. 12. Not sure exactly what they're trying to say here but again it's very well known that TCP and UDP are pretty much the only protocols that are likely to work on the internet. 13. Ditto. We all know why so many protocols are "over HTTPS", e.g. DoH. 14. This isn't a technical point. 15. Dunno what this is talking about but I'm guessing it's along the lines of "a byte is 8 bits", i.e. it is actually true in the modern world.

But I do agree that some of the later entries have felt a little lazy.

1. That said items are falsehoods in the first place.

2. That said items are necessarily interesting or noteworthy.

3. That a list is necessarily the best format to present said items.

4. That they may speak for the involved parties beliefs.

https://beej.us/guide/bgnet/ -- Covers what abstractions the OS provides for network programming and the guarantees that are possible.

https://www.madwizard.org/programming/tutorials/ - This is the very first ever good tutorial I read on socket programming. It's OG winsock. Introduces network programming from the most basic level. Aimed at C.

When you understand these guides you'll learn that how you structure your entire programs networking depends on whether you want to use blocking or non-blocking sockets. If you go with blocking you'll probably be using threads or processes. Otherwise you can't do any other work. With non-blocking it will be more about polling sockets and eventually you might end up with something resembling an event loop.

Until you come towards to the current approach to networking which is mostly async await -- an event loop works with non-blocking sockets, watches them for changes, and passes data from them to event handlers. There's a lot more that can be done on sockets to effect things like how data is flushed, how TCP errors are handled, and so on, but its a good start.

1. You're wrong

2. Okay, you're right

3. Okay maybe you're right or wrong but certainly not both

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

“Falsehoods programmers believe…” articles are designed to make you THINK about problematic assumptions. They are not like the 10 commandments and they are not decrees of absolute truth.