> In C, you can see what the machine is doing. Allocations don’t hide behind constructors, and destructors don’t quietly run during stack unwinding. You can profile at the machine-code level without feeling like you’re peeling an onion, appropriately shedding tears the whole time.
This is why explicit control flow is important design goal for systems programming language. This is basically 2/3 of core design principles in Zig.
The control flow is explicit; there is no language "magic" here. Non-local gotos in the former case and asynchronous callbacks from the OS in the latter case are pretty well known.
These are low-level api and hence if you know the caveats to follow, then using them correctly is not difficult; Eg. keep the context of the function calling setjmp active, don't use jmp_bufs allocated on a stack etc.
Not knowing how to do something is the fault of the programmer and not the language/tool.
That one's always a good read, particularly the discussion of the tension between 100% coverage testing and defensive programming. We go for maximum defensive programming, so huge numbers of code paths that can't be exercised in testing but that will prevent things running off into the weeds if something does manage to trigger them. Another organisation in contrast had a client who required 100% code coverage in testing so they spent six months removing all the non-testable defensive code in their code base.
That's a classic! (https://news.ycombinator.com/item?id=46306724) ... but too far from this particular topic to make sense on the list - otherwise we'd probably have to add all SQLite stories, which are legion.
It's perfectly clear: if you need to run a Windows app on another Windows PC, you just open the Windows app store on your Windows PC to download the Windows app Windows App, a Windows app that lets you connect to and run Windows apps on other Windows PCs.
The IETF really dragged their heels on CGNAT because they thought that IPv6 is easy™ (of course not, it's intentionally designed not to be "almost the same but wider" but include unworkable stuff like Mobile IPv6[1] which is just a fancy VPN) until they were forced to allocate 100.64.0.0/10 because some ISPs are not just using 10.0.0.0/8 but also US-DoD addresses (especially 11.0.0.0/8, because it's basically 10.0.0.0/7) as "private" addresses.
[1] Not IPv6 on mobile devices but a fully-owned IPv6 range that is supposed to be the address for a device regardless of where it is, see RFC 3775
Are those usually visible to clients sitting behind routers though? I'm not super familiar but the things I'm seeing make it seem like that should only be visible IPs on the internal network of carriers which is not a place I am ever connecting from.
reply