I still maintain stabilizing async rust in its current form was a massive mistake and we're worse off for it.
Jason King
- 31 Followers
- 32 Following
- 164 Posts
illumos. Ex-Joyeur. I write C, Rust (when I can), and other languages and enjoy building end-to-end systems.
Dany 
I felt that Microsoft Copilot, formerly known as Office, could use a mascot. So I asked Copilot to design something in the spirit of Clippy.
Let me introduce you to Sloppy, a cheerful slightly gooey assistant with glasses and a headset.
Found an issue where go binaries would have intermittent DNS errors while the rest of the system was fine. Turns out the go runtime will often use its own built in resolver. In this case, the go resolver couldn't deal with the responses while the system resolver has no problems.
This trend of reinventing things that work fine (this isn't unique to go), leading to potentially divergent views of the world on the same system is both obnoxious (I'm looking at you DNS over HTTP) and just leads to lower software quality. Stop it!
Phil Spectrum
@sjorge Not sure. My feeling is it's more fundamental in that there's almost always an implicit assumption by pretty much every OS about the reliability of the host's connection to storage than what you actually get with most ethernet networks. They also tend to react poorly when that assumption is violated. I'm not sure why NVMe would be much different in that respect.
Every time I have to deal with iSCSI, I'm feel like channeling Mrs. White at the end of Clue
@ocratato The problem is if you have something like:
typedef int foo_t;
typedef int bar_t;
void f(foo_t a, bar_t b) { .. }
foo_t myfoo = 1;
bar_t mybar = 2;
f(mybar, myfoo);
Compiles just fine.
That's why I was thinking about wrapping it in a struct -- you can still pass by value, but get an error if you mess something like the above up.
Has anyone else (in C) wrapped an int type in a struct to avoid accidental mixing of ints with different semantic values?
Oh firmware, will you ever not stop being terrible?