burntsushi

5 ms·

61.
by burntsushi 9mo ago
"niche" doesn't mean "unimportant." It just means "uncommon." It's a relative term. The vast vast majority of people using general purpose datetime libraries are not in need of GPS handling or high pr
62.
by burntsushi 9mo ago
Why should they though? To me it seems like a niche of a niche. I think there is plenty of room for scientific datetime libraries to service this need in a way that is likely better than what a general purpose datetime library would provide
63.
by burntsushi 9mo ago
> but the datetime APIs refuse to expose leap-second info because they're too committed to "only UTC is in-scope for this project". This doesn't make sense on at least two different levels. First, pedantically, the de
64.
by burntsushi 9mo ago
Nice. Yeah I'd have to actually look at what it did. For the task of substring search, it's extremely easy to fall into a local optima. The `memchr` crate has oodles of benchmarks, and some of them are very much in tension with ot
65.
by burntsushi 9mo ago
> How about porting BurntSushi's absurdly great Rust optimized string search routines to C and making them faster? How did it do? :-)
66.
by burntsushi 9mo ago
> With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks. I suppose it's poss
67.
by burntsushi 9mo ago
Not necessarily at all. Go peruse the `regex` crate source code, including its dependencies. The biggest `unsafe` sections are probably for SIMD accelerated search. There's no "unnatural abstractions" there. Just a memmem-lik
68.
by burntsushi 10mo ago
> It may just be a matter of perspective -- if you don't count rust pre 1.0, then yeah it "never" involved backtrace. Yes. I'm only counting what has been part of the stable API since Rust 1.0. I agree that following
69.
by burntsushi 10mo ago
Sure, I've done it too: https://docs.rs/ignore/latest/ignore/enum.Error.html It's not necessarily about frequency, but about extensibility. There's lot of grey area there. If you're very c
70.
by burntsushi 10mo ago
That can be tricky because there may be a trade-off between error message quality and something else. Like, perhaps, the size of an error, code size or even runtime performance. Another trade-off with too-detailed errors---especially when t
71.
by burntsushi 10mo ago
If something is asking for `&mut [T]`, then yes, it's required that it be initialized. This is a good thing, because a `&mut [T]` permits reading that `T` in safe code, which would be UB if the `T` were uninitialized. It seems
72.
by burntsushi 10mo ago
To clarify, I'm on libs-api. I've been on it since the beginning. Stabilizing `std::error::Error` was absolutely the right thing to do. There were oodles of things in Rust 1.0 that weren't stable yet that embedded use cases r
73.
by burntsushi 10mo ago
> I do think that `std::error::Error` is mostly pointless. That's a value judgment, and reasonable people can disagree. I took it as a statement of fact. It is a factual matter of whether `std::error::Error` has a point to it or not
74.
by burntsushi 10mo ago
I doubt epage is suggesting that. And note that in that case, the thing distinguishing the cause is not `std::io::Error`, but `std::io::ErrorKind`. The latter is not the error type, but something that forms a part of the I/O error type
75.
by burntsushi 10mo ago
Yeah I used the weasel-y "something like" for exactly these reasons. :-)
76.
by burntsushi 10mo ago
I don't see any reason for something like `rootcause` to become foundational. Most errors are a linear chain and that's good enough for most use cases. It's correct to say that `std::error::Error` does not support a tree of e
77.
by burntsushi 10mo ago
> It was `std` only and linked to a concept of backtraces, which made it a non-started for embedded. It just seemed to me that it was a bad idea ever to use it in a library and that it would harm embedded users. It was never linked to ba
78.
by burntsushi 10mo ago
I'm on libs-api and I'd personally be on board with something like `thiserror` coming into `std`. But it would need a champion I think.
79.
by burntsushi 10mo ago
> or you yolo it with reserve+set_len, which is invalid Rust because you didn't properly use MaybeUninit for locations which are only ever written `Vec::spare_capacity_mut`[1] gives you a view into the unused capacity. There's
80.
by burntsushi 10mo ago
Have you seen Biff? It can do this and it will use your system's tzdb, unlike chrono. https://github.com/BurntSushi/biff
81.
by burntsushi 11mo ago
Yes, we are lacking information. But the operative point in this sub thread is whether unwrap() specifically is load bearing. If instead they bubbled up the error, printed it and then exited the program---without ever using unwrap---then pr
82.
by burntsushi 11mo ago
Nope. Because you've completely mischaracterized not only the actual problem here, but the value proposition of Rust. You're tilting at windmills. Nobody credible has ever said that Rust will fix all your problems 100% of the time
83.
by burntsushi 11mo ago
The fact that this wasn't RCE or anything other than denial of service is a raging success of Rust. “If it compiles it’s probably correct” has always been a tongue-in-cheek pithy exaggeration. I heard it among Haskell programmers long
84.
by burntsushi 11mo ago
> As it stands, I'm pretty mortified that some transitive dependency might use unwrap() deep in its internals. You'll have to go without std and even the `core` library then.
85.
by burntsushi 11mo ago
If you haven't read my blog on this topic, I suggest you do so before replying further: https://burntsushi.net/unwrap It should very clearly state my position. And it provides the examples that I previously referenced.
86.
by burntsushi 11mo ago
I've presented examples. They haven't. They haven't even bothered to engage with the examples I've provided. I want to read code they've written using this philosophy so that I can see what it looks like in real wor
87.
by burntsushi 11mo ago
Show me code you've published that is used by real people in real systems that follows the philosophy you've espoused here. Otherwise I'm calling shenanigans.
88.
by burntsushi 11mo ago
Your definition of "correct" is completely incoherent. Just because an invariant that could be modeled by a type system is not modeled by the type system in any given scenario does not make it incorrect. You can't engage
89.
by burntsushi 11mo ago
You said: > Rust needs to get rid of .unwrap() and its kin. Now you say: > You can keep unwrap() and panics. So which is it? > I just want a static first class method to ensure it never winds up in our code or in the dependencies w
90.
by burntsushi 11mo ago
I already had a conversation with the GP specifically: https://news.ycombinator.com/item?id=45979127 They aren't presenting a coherent philosophy. And when asked for examples, or to engage directly with examples in my

More ›