3 ms·
I really don't understand the hate, it's not 1.0 and majority of unsupported cases probably haven't seen use since 1990's and especially dumb cases where it's 1
by kachapopopow 10mo ago
I really don't understand the hate, it's not 1.0 and majority of unsupported cases probably haven't seen use since 1990's and especially dumb cases where it's 100x slower when providing unrealistic values like parsing e9000000 which is actually because it attempts to actually parse it due to bigint support instead of clamping to i128.
also people complaining about inclusion of it in ubuntu versions, wait till you find out about the linux kernel.
- mynameismon 10mo agoI mean, why is Ubuntu using it as default when it isnt 1.0?
- steveklabnik 10mo agoUbuntu is evaluating it as the default in order to see if it’s ready. That’s something you want to do before declaring something 1.0. If it’s not ready, they’ll roll it back. Part of why you have to do something like this is because the test suite just isn’t comprehensive, nor should we expect it to be. Real world usage is what shakes out the long tail of bugs. You just have to have some sort of stage like this in order to get things into a good state.
- pseudalopex 10mo ago> Ubuntu is evaluating it as the default in order to see if it’s ready. Did 100% of tests pass when Ubuntu made this decision? My understanding was no.
- steveklabnik 10mo agoNo. Because the tests that don’t pass are edge cases and corners that most people wouldn’t notice. It’s arguably more important to fix bugs that impact actual usage, so it can be a valid strategy to do this even before you hit 100% coverage, to help you prioritize the remaining bugs to fix. In other words, there may be more serious bugs not in the test suite than the ones that aren’t passing that are in the suite. And you only find that out through real usage.
- pseudalopex 10mo ago> Because the tests that don’t pass are edge cases and corners that most people wouldn’t notice. This standard may be justified when there is significant benefit. There is not in this case. And some projects have stricter standards.[1] > In other words, there may be more serious bugs not in the test suite than the ones that aren’t passing that are in the suite. And you only find that out through real usage. You should assume everyone understands how Ubuntu's decision would benefit this project. You should assume most Ubuntu users do not care. You replied to a comment which told you this before.[2] [1] https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75 [2] https://news.ycombinator.com/item?id=46267541 https://news.ycombinator.com/item?id=46267541
- tredre3 10mo agoMany of the utils, such as sort, aren't locale-aware. Considering that most of the world do not use English/ASCII, do you still consider that an irrelevant edge case?
- steveklabnik 10mo agoI don't consider it irrelevant, but neither does uutils. However, it's also not something that is currently at a zero. I'm not even sure that this percentage of tests is related to locale support specifically. I'm sure parity will be reached here. For example, sort has an open PR on it right now.
- pseudalopex 10mo ago> I'm sure parity will be reached here. And this project should be considered then. Not before.
- steveklabnik 10mo agoI would be surprised if they decided to go ahead without more robust locale support, I agree with that.
- 10mo ago
- egorfine 10mo ago> they’ll roll it back. They will absolutely not roll it back, not matter how broken they are. The reasons to switch from coreutils to the Rust rewrite are purely political.
- kachapopopow 10mo agoso they see issues that rise up from real world issues that tests might not cover? the same ubuntu version also bundles the latest kernel which is not considered stable to begin with.
- itsn0tm3 10mo agoThey are testing it in a real world scenario before putting it into a LTS of theirs.
- groundzeros2015 10mo ago> wait till you find out about the linux kernel Check the extent to which this is true. Also are we rewriting good kernel code that works?
- IshKebab 10mo ago> good kernel code that works The fallacy here is that code is either "good code that works" or "bad code that needs to be rewritten". It doesn't work like that. "If it aint broke don't fix it" is actually terrible advice.
- burnt-resistor 10mo agoYep, nuance is definitely needed. The greater issue is orthogonal: pushing out unfinished and incompatible code as production-usable rather code written in another language. Rust, by itself, isn't a panacea to add formal verification but one leg on the footstool of formal verification methodologies to produce safe(r/ish) software rather than subtly buggy software that's difficult to prove correct and more expensive to maintain. "If it aint broke don't fix it" =~= "I've never gotten into an accident until now, so airbags and seatbelts are pointless." ==> reactive methodology / failure / hubris
- groundzeros2015 10mo agoThe seat belt analogy makes no sense. The new tools have entirely new vulnerability and problems.
- groundzeros2015 10mo ago> If it aint broke don't fix it" is actually terrible advice. We want to give up good things to get better things. What is the vision for improving these tools with rust? What user benefit are they promising? I’ve heard nothing but nebulous arguments about memory or security purity. There is no insight into how to do them better or faster; and in most cases they have demonstrated they didn’t even understand them fully to begin with, such as missing locales. There isn’t even subjective value for users demanding it, it’s driven by rust developers.
- tormeh 10mo agoThe hateable part is the license. I love Rust but this is a huge step backwards.
- kachapopopow 10mo agoand that's what I was looking for, finally got a real answer.