Runtime performance is entirely unaffected by the use of macros. It can have a negative impact on compile-time performance though, if you overdo it.
arendjr
joined 2 years ago
Issue resolved
I was aware that indeed the trait and lifetime bounds were an artifact of the Tokio work-stealing behavior, but Evan makes a very well-explained case for why we might want to consider stepping away from such behavior as a default in Rust. If anything, it makes me thankful the Rust team is taking a slow-and-steady approach to the whole async thing instead of just making Tokio part of the standard library as some have wished for. Hopefully this gets the consideration it deserves and we all end up with a more ergonomic solution in the end.
As someone who doesn’t like AI-based auto-complete but will happily use AI occasionally to ask questions every now and then, it looks like these guys might be on to something.
I’m not using Zed yet, but this is giving me some incentive to try it out.
Does the Rust compiler use their std sort algorithms, or does it already use specialized ones? If the former, it would be a great side-effect if the compiler itself receives additional speed ups because of this.
For a little bit I thought this library might be a subtle joke, seeing the #define _SHITPRESS_H at the start. That combined with the compress() and decompress() not taking any arguments and not having a return value, I thought we were being played. Not to mention the library appears to be plain C rather than C++... surely the author should know the difference?
Then I saw how the interface actually works:
// interface for the library user, implement these in your program:
unsigned int SPR_in(); // Return next byte from input or value > 255 on EOF.
void SPR_out(unsigned char); // Output byte.
This seems extremely poorly thought out. Calling into global functions for input and output means that your library will be a pain to use in any program that has to (de)compress anything more than a single input.
Ah yes, exactly.