For a couple of months I tried to ask a very tricky question involving Linux sockets API and its strange behavior in some cases causing unexpected slow-downs. The tricky part was that I used my own programming language to interact with sockets and thus examples provided were written in it. Since it was my first question on Stackoverflow I decided to create my post in the playground (or how it's called, I don't remember). The answer of a couple of gatekeepers was shocking - they said that it's likely a problem with my language and not with Linux sockets API and I should rewrite my examples in C instead. I never did this for obvious reasons. One of suggestions was to update my OS, since it was somewhat outdated, which isn't that good advice too. Later I have found myself what was the problem - it wasn't something wrong with my programming language, but I just managed to hit some connection limits in the kernel.

I presume this happens nowadays frequently. All easy questions are answered by chat-bots or have ben already answered and hard questions don't pass gatekeeping.

▲

mdavid626 a day ago | parent [-]

Isn’t that good advice? Rewriting it in C can prove that the problem is not in your programmin language.

Outdated OS can be the problem as well.

What kind of advice did you expect?

▲

Panzerschrek a day ago | parent [-]

> Rewriting it in C can prove that the problem is not in your programmin language

It's a lot of work of rewriting it in C. It's doable, but impractical. And such rewrite may introduce new bugs.

Proving that the problem isn't in my language wasn't necessary - there were no room for it to introduce such kind of bug. Language bugs are usually manifest themselves in a way different way, (like broken binary code leading to crashes or accepting invalid code). That's why I have created my question in a first place - while I was sure, that it wasn't a language bug.

> Outdated OS can be the problem as well.

Outdated OS can't be a problem. Basic socket functionality was implemented eons ago and all known bugs should be fixed even in pretty outdated versions of the kernel.

> What kind of advice did you expect?

Eventually I have found myself, that in my test program I create too much connections for a TCP server and its internal connection queue overflows. But it took some time to find it, way longer compared to what could be achieved if my SO was answered. The problem was not so hard to spot considering that I have described what exactly I do. Even providing code examples wasn't necessary - textual description was enough.

	▲	7bit a day ago \| parent [-]
		Your arguments fall flat. Could very well be that your language was the issue and writing a small proof of concept for the specific use case that's problematic in a battle tested language other people know is a standard trouble shooting step. Especially if it was a rare limiting error, that sounds like a trivial thing to be implemented in C with a simple for loop and some dummy data perhaps. Same with the OS. Only because socket functionality is decades old doesn't mean that you can't hit a recently introduced bug, that could have been fixed in a new version. That also is a standard troubleshooting step. It doesn't make for bad advice only because you're too lazy to do it.