matsdis

Depends. I would flag it in a code review on our product, and same for most TODO comments. It’s bad practice to leave them for your team to deal with, or even for yourself two years later.

But for explorative coding (mostly just one person, things like game development or creative coding, or before finishing your branch) I think dead code warnings do more damage than they help. They make you look at things not worth looking at right now, until you figured out what you want to build. Like unused structs or imports just because you commented out some line to test something. I didn’t turn all annoyances off, but I feel I should. I have a hard time just ignoring them. I think it’s better to enable them later when the code is stabilizing, to clean up experiments that didn’t work out. When I just ignore them I also ignore a more important warnings, and waste time wondering why my stuff isn’t working while the compiler is actually telling me why.

Also, in Rust many clippy defaults are too pedantic IMO, so I turn them off for good. Here is what I currently use:

[lints.rust]  
dead_code = "allow"  

[lints.clippy]  
new_without_default = "allow"  
match_like_matches_macro = "allow"  
manual_range_patterns = "allow"  
comparison_chain = "allow"  
collapsible_if = "allow"  
collapsible_else_if = "allow"  
let_and_return = "allow"  
identity_op = "allow"  # I'll multiply by one whenever I like!  
# Just disable all style hints?  
# style = "allow"  

This is buildings. It could be just the usual resistance to change. Some companies have been installing gas or oil for decades, they know exactly what they are doing, how to calculate those systems with just enough margin. And the cost for “not working” is very high. So here comes some new tech, and they will suggest to build it too powerful just in case, and do extra stuff that doesn’t make sense except to keep the option open to install oil or gas later in case it doesn’t work. And the result is too expensive, so nobody wants to pay for it, and so they never gain the confidence to make it cheaper.

I found it interesting that key travel time was considered, often it isn’t.

A similarly interesting article: Measure and reduce keyboard input latency with QMK on the Kinesis Advantage (2021) (Basically, took an existing keyboard and replaced the controller.)

As for “why is it hard to self-host”, it is only NAT traversal.

TURN, STUN, ICE, etc. are not fun to debug. Not sure if anyone still bothers fiddling with TOS/DSCP on their router. You can build a voice server that just exposes a TCP port, but… latency. And corporate firewalls love to randomly block some UDP port ranges but not others.

Yes, I like it. It makes only one (big) mistake: a horizontal table-of-contents. Nobody does that. You can put it on the left, or above the text, but… not like that.