Jiff: A brand new Datetime library for Rust, from the builder of ripgrep

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

InfluxDB - Purpose built for real-time analytics at any scale.
InfluxDB Platform is powered by columnar analytics, optimized for cost-efficient storage, and built with open data standards.
www.influxdata.com
featured
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com
featured
  • jiff

    A date-time library for Rust that encourages you to jump into the pit of success.

    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.

  • InfluxDB

    Purpose built for real-time analytics at any scale. InfluxDB Platform is powered by columnar analytics, optimized for cost-efficient storage, and built with open data standards.

    InfluxDB logo
  • rfcs

    RFCs for changes to Rust

    https://github.com/rust-lang/rfcs/issues/323 is the oldest currently open tracking issue, as you can see it has 397 comments. And that thread you linked has 171. Basically, tons of people that feel basically every possible way.

    I also feel at this point it's basically a wontfix, but that's more because it's both controversial and huge, and arguably not as high of a priority as other things even if it weren't those two things. The reason it gets huge is that you really want to consider all three of {optional, named, variadric} at roughly the same time.

    I do think that people are generally more supportive of variadric than optional/named.

  • byteorder

    Rust library for reading/writing numbers in big-endian and little-endian.

    Burntsushi has written many important crates in the Rust ecosystem. He started with licensing under Unlicense exclusively, until people requested a dual license with MIT. See this issue from 2016 for more details - https://github.com/BurntSushi/byteorder/issues/26

    Almost all of the Rust ecosystem is dual licensed under MIT/Apache 2.0, so this combination is a bit unusual. But the presence of MIT means that it hasn’t been a problem in practice.

  • tz

    Time zone database and code

  • no-panic

    Discontinued Attribute macro to require that the compiler prove a function can't ever panic

    > How could be erased those panic! methods that are used in most of Rust's libraries is something that may be is beyond the possible?

    It's arguably quite possible, though not as straightforwards as one may hope. For example, there's no_panic, which results in a linker error if the compiler cannot prove a function cannot panic [0], albeit with some caveats.

    > So much correctness in the Rust language just for to promote to all the community to crash the program from libraries without handling the error is something I can not understand.

    Is there that much "promoting" of unchecked unwrap()/expect()/etc. going on? How do you distinguish that from "genuine" cases of violations of the programmer's assumptions?

    I ask because Result/? along with libraries like thiserror/anyhow/etc. are right there and arguably easier/more concise, so unwarranted unwrap()/etc. would seem "harder" to write/justify than the alternative. The main exception I can think of are more one-off cases where the author is intentionally sacrificing robust error handling for the sake of speed, but that's a more language-agnostic thing that pretty much "doesn't count" by definition.

    > I hope this philosophy do not reach the Linux kernel.

    IIRC this is being worked on, especially given Linus's position on panics in the kernel.

    [0]: https://github.com/dtolnay/no-panic

  • notes

    A collection of small notes that aren't appropriate for my blog. (by BurntSushi)

    I wrote down why I do it years ago: https://github.com/BurntSushi/notes/blob/master/2020-10-29_l...

    You may not agree with me, which is fine, but you should now understand.

  • Joda-Time

    Joda-Time is the widely used replacement for the Java date and time classes prior to Java SE 8.

    In Java they had the same problem. The Java standard library implementation wasn't great, Jodatime came along to address those issues. Java 8 then introduced a new DateTime API that was heavily influenced by Jodatime with the benefit that as it is in the standard library, it can be more heavily adopted by library-writers.

    https://www.joda.org/joda-time/

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

    SaaSHub logo
  • proposal-temporal

    Provides standard objects and functions for working with dates and times.

    There's an additional related stepping stone here (as it is name dropped in the library's design document as well) in that TC-39 has been hard at work on a proposal to standardize similar APIs into EcmaScript (JS) called Temporal: https://tc39.es/proposal-temporal/docs/

    Temporal benefits from the JodaTime/Java 8+ date work, but also includes more recent IETF and IANA standards as other influences.

  • toggl

    Wow! What timing. I need this. https://github.com/andrewarrow/toggl I’m doing UTC conversion in my head.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts

  • It's Time for a Change: Datetime.utcnow() Is Now Deprecated

    5 projects | news.ycombinator.com | 19 Nov 2023
  • Fedora to disallow CC0-licensed code

    2 projects | news.ycombinator.com | 25 Jul 2022
  • Hey Rustaceans! Got an easy question? Ask here (3/2022)!

    5 projects | /r/rust | 18 Jan 2022
  • Help with encoding variables of different types, taking into account endianness

    1 project | /r/rust | 24 Dec 2021
  • Why does rust change the byteorder of integer types if I print them as hex

    2 projects | /r/rust | 28 Jun 2021