Stop spamming me with burning straw men bro. I am slightly irritated with you because I think you're trolling me or at least wasting my time by being an idiot. I have asked some rhetorical questions in my response below. Do not feel obligated to pipe up with more nonsense in response.
Have you used C++
I mainly work in C++, and have for the past 20 years. That also entails using a fair amount of C from time to time. Even if I didn't write C or C++, the performance of the standard library would affect me, as I use much software written in these languages as well.
Why would I do that when I don't use the C library for performance sensitive programs?
If you don't use C at all then you aren't using MUSL and won't need it to be fast. If you do use MUSL then you aren't using the fastest library, so you must not care that much about performance.
No one said anything about that, I think you're hallucinating or predicting something that never happened.
I expected that you might say "what about YOU" when I pointed out your obvious conflict of interest here. That would have been a baseless attack but more logically coherent than what you've been spamming me with.
The stuff made 50 years ago isn't the fastest possible stuff. It's still pretty fast and if you want something faster, do something else. It's not that complicated but it seems to really upset you.
Finally, just because a project or language is old doesn't mean it currently has bad performance. The article suggests that if you care about performance, don't use MUSL. That is "using something else" and exactly what I've been saying this whole time. Why are you so stubborn that you can't even admit that there could very well exist a scenario where the suggestion to switch to another standard library makes sense? Nevermind that these scenarios are common, and the article is presenting one. You have suggested everything from massive refactoring to switching languages, anything but switching to a more suitable library.
I'm not sure where the entitlement and expectation comes from that you can reply to me and that I won't reply back. This seems like a transparent hail mary to continue to avoid confronting what I already explained in detail.
You can try to call my single replies "spam", but I think if you could actually respond to the things I've said you would have done it already.
If you do use MUSL then you aren't using the fastest library,
You are contradicting yourself with logic that doesn't add up.
The default libc isn't the fastest way to do things anyway. So by your own logic the title should be "don't use libc if you care about performance". This of course doesn't make sense either because if you aren't using libc then musl wouldn't matter. This is why the title doesn't make sense and why your defense of it doesn't make sense either.
You having software that is not only slow but slow because it calls into the default libc has nothing to do with this. Why aren't you mentioning taking it further and linking in a better allocator?
Maybe because it's the same idea but contradicts what you keep trying to say to avoid the actual point, which is that the title is wrong.
If you're going on a long trip and you get better shoes and can walk to your car 25% faster, how much is that going to speed up your trip overall? It will be basically nothing, because you are optimizing something almost irrelevant.
I can use musl and create software that outperforms whatever someone else makes using the default standard library. If this is possible, and I explained why it is in detail, then why would the title be true? Explain that instead of getting upset and avoiding the heart of the discussion with irrelevant tangents about your own legacy programs.
Comments
Stop spamming me with burning straw men bro. I am slightly irritated with you because I think you're trolling me or at least wasting my time by being an idiot. I have asked some rhetorical questions in my response below. Do not feel obligated to pipe up with more nonsense in response.
I mainly work in C++, and have for the past 20 years. That also entails using a fair amount of C from time to time. Even if I didn't write C or C++, the performance of the standard library would affect me, as I use much software written in these languages as well.
If you don't use C at all then you aren't using MUSL and won't need it to be fast. If you do use MUSL then you aren't using the fastest library, so you must not care that much about performance.
I expected that you might say "what about YOU" when I pointed out your obvious conflict of interest here. That would have been a baseless attack but more logically coherent than what you've been spamming me with.
Finally, just because a project or language is old doesn't mean it currently has bad performance. The article suggests that if you care about performance, don't use MUSL. That is "using something else" and exactly what I've been saying this whole time. Why are you so stubborn that you can't even admit that there could very well exist a scenario where the suggestion to switch to another standard library makes sense? Nevermind that these scenarios are common, and the article is presenting one. You have suggested everything from massive refactoring to switching languages, anything but switching to a more suitable library.
I'm not sure where the entitlement and expectation comes from that you can reply to me and that I won't reply back. This seems like a transparent hail mary to continue to avoid confronting what I already explained in detail.
You can try to call my single replies "spam", but I think if you could actually respond to the things I've said you would have done it already.
If you do use MUSL then you aren't using the fastest library,
You are contradicting yourself with logic that doesn't add up.
The default libc isn't the fastest way to do things anyway. So by your own logic the title should be "don't use libc if you care about performance". This of course doesn't make sense either because if you aren't using libc then musl wouldn't matter. This is why the title doesn't make sense and why your defense of it doesn't make sense either.
You having software that is not only slow but slow because it calls into the default libc has nothing to do with this. Why aren't you mentioning taking it further and linking in a better allocator?
Maybe because it's the same idea but contradicts what you keep trying to say to avoid the actual point, which is that the title is wrong.
If you're going on a long trip and you get better shoes and can walk to your car 25% faster, how much is that going to speed up your trip overall? It will be basically nothing, because you are optimizing something almost irrelevant.
I can use musl and create software that outperforms whatever someone else makes using the default standard library. If this is possible, and I explained why it is in detail, then why would the title be true? Explain that instead of getting upset and avoiding the heart of the discussion with irrelevant tangents about your own legacy programs.