4 ms·

> why did they [...] kept the slow one? For compatibility with legacy systems > why did they get rid of the optimized implementations Probably to give people

by fooyc 8y ago

> why did they [...] kept the slow one? For compatibility with legacy systems > why did they get rid of the optimized implementations Probably to give people less reasons to choose rc4, in case this was enough reasons for these people to choose rc4. Also because this is less code to maintain.

johnisgood 8y ago
> For compatibility with legacy systems I understand, so why didn't they keep the optimized version? > Probably to give people less reasons to choose rc4, in case this was enough reasons for these people to choose rc4. Also because this is less code to maintain. But they just said that they kept it for legacy reasons. It has already been chosen, and most of the time you simply can't choose to move to another one. The only difference is now that legacy systems will be stuck with a slower implementation. For what reason exactly? Is "less code to maintain" really a valid concern? Do they actually have to maintain it after it's been written? Do you have to touch the already-existing optimized code? I assume there are no bugs in there, so I don't know what there is to maintain about it.
- secure 8y ago
  The optimized versions (plural!) were only available for a few platforms, so a portable version needs to be kept around anyway. https://github.com/golang/go/commit/30eda6715c6578de2086f03df36c4a8def838ec2 https://github.com/golang/go/commit/30eda6715c6578de2086f03d... is the removal commit, which also points out that the optimization didn’t seem to have mattered much (depending on the CPU).
  - johnisgood 8y ago
    > which also points out that the optimization didn’t seem to have mattered much (depending on the CPU). OK, this reason makes more sense to me. Thanks.
- bradfitz 8y ago
  > Is "less code to maintain" really a valid concern? Do they actually have to maintain it after it's been written? Yes, it really is. And yes, you still have to maintain code that's been written. See discussion at https://github.com/golang/go/issues/25417 https://github.com/golang/go/issues/25417 The pure Go code was already faster than the assembly on some CPUs. For the other CPUs where the assembly was faster, we'd rather just fix the compiler to optimize better.
  - johnisgood 8y ago
    > The pure Go code was already faster than the assembly on some CPUs. For the other CPUs where the assembly was faster, we'd rather just fix the compiler to optimize better. Yeah, it makes more sense to me than the reason (perhaps it was not intended to be the reason but I read it as such) provided on that page. Thanks for clearing it up.

by fooyc 8y ago

johnisgood 8y ago

> For compatibility with legacy systems I understand, so why didn't they keep the optimized version? > Probably to give people less reasons to choose rc4, in case this was enough reasons for these people to choose rc4. Also because this is less code to maintain. But they just said that they kept it for legacy reasons. It has already been chosen, and most of the time you simply can't choose to move to another one. The only difference is now that legacy systems will be stuck with a slower implementation. For what reason exactly? Is "less code to maintain" really a valid concern? Do they actually have to maintain it after it's been written? Do you have to touch the already-existing optimized code? I assume there are no bugs in there, so I don't know what there is to maintain about it.

secure 8y ago
The optimized versions (plural!) were only available for a few platforms, so a portable version needs to be kept around anyway. https://github.com/golang/go/commit/30eda6715c6578de2086f03df36c4a8def838ec2 https://github.com/golang/go/commit/30eda6715c6578de2086f03d... is the removal commit, which also points out that the optimization didn’t seem to have mattered much (depending on the CPU).
- johnisgood 8y ago
  > which also points out that the optimization didn’t seem to have mattered much (depending on the CPU). OK, this reason makes more sense to me. Thanks.
bradfitz 8y ago
> Is "less code to maintain" really a valid concern? Do they actually have to maintain it after it's been written? Yes, it really is. And yes, you still have to maintain code that's been written. See discussion at https://github.com/golang/go/issues/25417 https://github.com/golang/go/issues/25417 The pure Go code was already faster than the assembly on some CPUs. For the other CPUs where the assembly was faster, we'd rather just fix the compiler to optimize better.
- johnisgood 8y ago
  > The pure Go code was already faster than the assembly on some CPUs. For the other CPUs where the assembly was faster, we'd rather just fix the compiler to optimize better. Yeah, it makes more sense to me than the reason (perhaps it was not intended to be the reason but I read it as such) provided on that page. Thanks for clearing it up.