a lot of quality engineering has gone into some of the system libs and they have been battle tested as well. So it will be a tall order to replace them, but they should be where it makes sense.
It’s pretty striking to me how different system calls are from the internal language implementations.
Node.js also has a 2 DNS implementations - one that calls getaddrinfo synchronously from the threadpool, and another that always performs a DNS query over the network. I remember running into an issue with slow, unreliable cell modem connections where DNS queries would timeout and it would starve the Node.js threadpool (all threads blocked waiting for getaddrinfo to fail), and ultimately the entire application would become unresponsive. Since we were also reading data from the serial port in real time, this would cause packets to be dropped for a few hundred milliseconds. This was a painfully difficult thing to debug, and my nightmarish experience is part of the reason why the Node.js documentation now explicitly calls this issue out.
Great hearing these real-world experiences. I’ll add one more …
In one system we designed, we used a Cat-1 modem which implemented a USB network interface. Apparently this modem acted somewhat like a router in itself and cached DNS queries. When we switched to a Cat-M modem, we had to use PPP over serial to establish the network connection, and then noticed a lot more data being used. We eventually traced it down to DNS queries on every CoAP transaction. So while the CoAP packet was small, the DNS transaction on every packet added significant overhead. We ended up adding dnsmasq to the edge system to cache DNS requests – this is working well.