Earlier quoted context omitted.
I stumbled over use jiff::{Timestamp, ToSpan}; fn main() -> Result { let time: Timestamp = "2024-07-11T01:14:00Z".parse()?; I seem to remember Rust does that thing with interfaces instead of classes, is it that? How come I import a library and all of a sudden strings have a `parse()` method that despite its generic name results in a `Timestamp` object? or is it the left-hand side that determines which meaning `str.pa…
It’s because Timestamp implements the FromStr trait which is one of the first traits everyone learns about when learning rust. So when you say that your value is a Timestamp and the expression is string.parse()?, the compiler knows that it has to use the implementation which returns a Timestamp. There will never be two libraries that clash because of Rust’s orphan rule: you can only implement either a trait which you…
Jiff: Datetime library for Rust
231–240 of 249 posts
Re: Jiff: Datetime library for Rust
#232 impl Decimal {
...
/// Returns the ASCII representation of this decimal as a string slice.
pub(crate) fn as_str(&self) -> &str {
// SAFETY: This is safe because all bytes written to `self.buf` are
// guaranteed to be ASCII (including in its initial state), and thus,
// any subsequence is guaranteed to be valid UTF-8.
unsafe { core::str::from_utf8_unchecked(self.as_bytes()) }
}
}
https://github.com/BurntSushi/jiff/blob/08dfdde204c739e38147...How much performance does `from_utf8_unchecked` buy us over `from_utf8`? It's saving iterating over a 20-byte array. Because the array fits in a single cache line, the iteration will run at the CPU's internal clock rate. I expect that a benchmark would not be able to detect the CPU time saved. Even a program that was only serializing these Decimal types at GB/s, the difference would be barely measurable.
As software engineers, about 80% of our time is spent coding. And about 80% of coding time is spent learning how the thing works. If we prioritize code clarity, we speed up 64% of our future work.
Performance optimizations always make code less clear. Using `from_utf8_unchecked` is a performance optimization. It makes the code less clear so it needs a three-line comment.
Engineering is all about trade-offs. Performance optimizations can be worth their clarity cost when they bring tangible benefits. Therefore, we need to measure. The comment doesn't say "Using `from_utf8_unchecked` because it takes 1ns while `from_utf8` takes 5ns." To make sure we're making a good tradeoff between clarity and performance, we need to measure the impact of the optimization and document it in the code.
Using `unsafe` also has a cost. Safety depends on invariants. Future changes to the code can break these invariants. The compiler is the most reliable method for detecting invariant-breakage. Let's take advantage of it. This means using `unsafe` only when its use brings tangible benefits that outweigh the risks.
I started my professional life as a Windows sysadmin. Dealing with worms and viruses was a large and unpleasant part of my job. During university, I learned about formal verification of software. It has great potential for making our software secure. Unfortunately, the tools are very hard to use. To verify a program, one must translate it into the language of the verification tool. This is a lot of effort so few projects do it. Now with Rust, we get verification FOR FREE! It's amazing!!!! So let's use it and move our industry forward. Let's make worms, viruses, ransomware, and data theft, into things from the barbaric early days.
Re: Jiff: Datetime library for Rust
#233I have seen many people downplaying the complexity of a datetime library. "Just use UTC/Unix time as an internal representation", "just represent duration as nanoseconds", "just use offset instead of timezones", and on and on For anyone having that thought, try reading through the design document of Jiff ( https://github.com/BurntSushi/jiff/blob/master/DESIGN.md ), which, as all things burntsushi do, is excellent and…
Re: Jiff: Datetime library for Rust
#234Thanks for making this library, BurntSushi. impl Decimal { ... /// Returns the ASCII representation of this decimal as a string slice. pub(crate) fn as_str(&self) -> &str { // SAFETY: This is safe because all bytes written to `self.buf` are // guaranteed to be ASCII (including in its initial state), and thus, // any subsequence is guaranteed to be valid UTF-8. unsafe { core::str::from_utf8_unchecked(self.as_bytes())…
We've had discussions before about the use of `unsafe` in Rust and we have a pretty clear disagreement about how to balance the trade-offs surrounding it. I have zero interest in re-litigating that discussion with you. I also personally find your conversational style condescending, which makes it difficult for me to talk to you.
Re: Jiff: Datetime library for Rust
#235Overall this looks nice, but I found myself stumbling over the ToSpan syntax: let span = 5.days().hours(8).minutes(1); It feels sort of weird how the first number appears in front, and then all the other ones are function arguments. I suppose if you don't like that you can just write: let span = Span::new().days(5).hours(8).minutes(1); at the expense of a couple characters, which is not too bad.
let span = Span::days(5).hours(8).minutes(1);Re: Jiff: Datetime library for Rust
#236Overall this looks nice, but I found myself stumbling over the ToSpan syntax: let span = 5.days().hours(8).minutes(1); It feels sort of weird how the first number appears in front, and then all the other ones are function arguments. I suppose if you don't like that you can just write: let span = Span::new().days(5).hours(8).minutes(1); at the expense of a couple characters, which is not too bad.
Or even better: let span = Span::days(5).hours(8).minutes(1);
Re: Jiff: Datetime library for Rust
#237Earlier quoted context omitted.
You think your philosophy is stronger than any other philosophy? I mean it's philosophic design approach itself which is doubtful. Correctness is satisfaction of expectations. For any library there are expectations that it doesn't satisfy.
Is that relevant? If my philosophy is weak, you can prove it to be weak by providing me with an example of a library which conforms to a better philosophy; then I can see why it's better.
Re: Jiff: Datetime library for Rust
#238Earlier quoted context omitted.
Is that relevant? If my philosophy is weak, you can prove it to be weak by providing me with an example of a library which conforms to a better philosophy; then I can see why it's better.
Everybody thinks their philosophy is the best. Take for example C89 time library. You'll just say it doesn't satisfy your philosophy.
Time handling is one of the many cases where there is actually complexity in the domain, and if you refuse to model the complexity, that doesn't make the complexity go away; it just means you've got bugs.
Re: Jiff: Datetime library for Rust
#239Re: Jiff: Datetime library for Rust
#240Earlier quoted context omitted.
> That humans have invented timezones and DST won't change the physics of a CPU's internal clock ticking x billion times per second. Increasingly we are programming in distributed systems. One milli or nano on one node is not a milli or nano on another node, and that is physics that is more inviolable.
In which case, does being off a few milli actually matter that much in any significant number of those distributed instances? No precision is exact, so near enough, should generally be near enough for most things. It may depend in some cases, but as soon as you add network latency there will be variance regardless of the tool you use to correct for variance.