burntsushi

9 ms·

91.
by burntsushi 11mo ago
You can't model all invariants in the type system. My blog even shows examples of this too.
92.
by burntsushi 11mo ago
I'm on libs-api. We will never get rid of unwrap(). It is absolutely okay to use unwrap(). It's just an assertion. Assertions appear in critical code all the time, including the standard library. Just like it's okay to use `s
93.
by burntsushi 11mo ago
> No, it's a principled position. Correct code doesn't `.unwrap()`, but code that hides failure cases -- or foists invariant enforcement onto programmers remembering not to screw up -- does. I don't think you understand wh
94.
by burntsushi 11mo ago
I'm finding this exchange frustrating, and now we're going in circles. I'll say this one last time in as clear language as I can. They said this: > unwrap(), expect(), bad math, etc. - this is all caused by lazy Rust devel
95.
by burntsushi 11mo ago
The commenter also said: > We shouldn't be using unwrap() or expect() at all. So the context of their comment is not some specific nuanced example. They made a blanket statement. > Note that they're not criticizing the langu
96.
by burntsushi 11mo ago
`slice[i]` is just sugar for `slice.get(i).unwrap()`. And whether it's a "local" invariant or not is orthogonal. And `unwrap()` does not "require lying about invariants across your API surface." > The blog post d
97.
by burntsushi 11mo ago
They said: > unwrap(), expect(), bad math, etc. - this is all caused by lazy Rust developers or Rust developers not utilizing the language's design features. That's factually incorrect. (And insulting.)
98.
by burntsushi 11mo ago
The blog linked in the GP anticipates this rebuttal and already addresses it. Your argument also implies that things like `slice[i]` are never okay.
99.
by burntsushi 11mo ago
I'm on the Rust libs-api team and you're mistaken. I use `unwrap()` all the time. My blog on this topic was linked above, you should read it: https://burntsushi.net/unwrap/
100.
by burntsushi 1y ago
I don't deny that there are downsides. But your original comment was misleading. Hence my clarification. Your comment was too absolute. It is possible to avoid duplication and build some sound abstractions. I use the same technique i
101.
by burntsushi 1y ago
> And yes my argument is weak because I’m actually not an expert on core utility development. Yes, and I'm trying to point out why your argument is weak. You said things like this: > But I wonder if the core utils which have be
102.
by burntsushi 1y ago
It lacks a hybrid duration type. Instead, it splits durations into calendar and time durations and conflates the length of a `day` depending on whether it's in `Period` or `Duration`. And AFAIK, it doesn't support time zone aware
103.
by burntsushi 1y ago
There's no optimal portable `movemask` operation. Because aarch64 NEON doesn't have it.
104.
by burntsushi 1y ago
> Given the “blazingly fast” branding, I too would have thought this would be in stable Rust by now. It's the exact opposite. It's the portable SIMD abstraction that isn't stable yet. But the vendor specific SIMD intrinsic
105.
by burntsushi 1y ago
It's not quite that dire. The `memchr` crate uses abstraction to limit the code duplication: https://github.com/BurntSushi/memchr/blob/1230fc5c638a4d922f... That is, the `memchr` crate has a `Vector` tra
106.
by burntsushi 1y ago
But what if we did that 5 years ago? Oops. And even Java's API has problems too. Why not let it be provide by the ecosystem where it can qctually evolve?
107.
by burntsushi 1y ago
If Chrono were in std, that would have been a disaster IMO.
108.
by burntsushi 1y ago
So then your original comment should be amended to say, "and this is actually all fine when the authors use a license I personally like." So it's not actually the rewriting you don't like, but the licensing choices. Whic
109.
by burntsushi 1y ago
Writing tools that are POSIX compatible doesn't mean one puts it on the pedestal of the "holy grail of OS design." I've certainly used POSIX to guide design aspects of things I build. Not because I think POSIX is the b
110.
by burntsushi 1y ago
> And again the question why not simply write something new. The world isn't black or white. Some people write Rust programs with the intent to be drop-in compatible programs of some other program. (And, by the way, that "some
111.
by burntsushi 1y ago
> You're right that the language itself is pretty stable and doesn't make breaking changes. Regardless, right now, we're clearly talking about the community and libraries No, I know. I am talking about community/libra
112.
by burntsushi 1y ago
This is the context of the discussion I'm talking about: >>> Rust still has a very "Ready to make breaking changes on a whim" >>> reputation >> >> No it doesn't. What on ea
113.
by burntsushi 1y ago
That doesn't address my point, which is that you are conflating communication of a thing with the thing itself . Moreover, it's unclear to me if you're aware that, in the Rust ecosystem, 0.x and 0.(x+1) are treated as semv
114.
by burntsushi 1y ago
You are conflating what actually _is_ with what you perceive version numbers communicate. The comments above that you are seemingly commenting in support of are talking about "Ready to make breaking changes on a whim," which is fa
115.
by burntsushi 1y ago
> I know this isn't the perfect place for a feature request, but I've recently found it quite annoying that ripgrep ignores .github directories because they're hidden. As has been suggested elsewhere in this thread, have y
116.
by burntsushi 1y ago
It has since day 1. And you can use the `-e/--regexp` flag too, just like grep.
117.
by burntsushi 1y ago
Yes, I agree, `git ls-files` can indeed be faster than just `rg --files`. On my Chromium checkout: $ hyperfine --output pipe 'rg --files' 'git ls-files' Benchmark 1: rg --files Time (mean ± σ): 141.2
118.
by burntsushi 1y ago
ripgrep's -Q is just -F, like grep. This is not enabled by default in either tool. Otherwise, ag enables multiline search (assuming you have a version of ag where that even works) and smart case by default. With ripgrep, that's `
119.
by burntsushi 1y ago
Idk what "still nuclear" means. And yes, ripgrep doesn't do any kind of Unicode normalization. Few tools do. But that doesn't mean what I said was wrong. ripgrep has a whole host of Unicode features that ag doesn't
120.
by burntsushi 1y ago
I was extremely careful with my wording. Re-quoting, with added emphasis: > ripgrep should generally already be approximating `git ls-files` by respecting gitignore. See also: https://news.ycombinator.com/item?id=456295

More ›