Hacker News Reader

Comment by cetra3 | Hacker News Reader

Are you talking about the crate `crypto` or `rust-crypto`? Both have not been updated in a couple of years.

The `ring` library is a bit more modern, but still requires a bit of a run around. Here's an example of encrypting a cookie: https://github.com/alexcrichton/cookie-rs/blob/master/src/se...

View on HN

Why does everyone leap to suggesting that 2016 was some kind of dark age of Rust when no one could be expected to do anything right? You're not the first [1].

I'm reminded of the Onion article about "Stating current year still the leading argument for reform" [2] (e.g. "It's 2019, people!")

I guess the corollary is, "That was 3 years ago" still leading excuse for shoddy work :-p

[1] https://news.ycombinator.com/item?id=18943056

[2] https://www.theonion.com/report-stating-current-year-still-l...

I don't believe that's what the comment you're replying to stated. The fact that `rust-crypto`, for example, has not been updated since 2016 doesn't imply that the code was necessarily bad in 2016, but that the project itself may not be maintained anymore. Static, perfect code is rare.

I know they didn't state it. I said they suggested it. Which they, and the linked comment, did.

When your immediate reply is to dismiss the dominant rust crypto library in 2016 as being understandably bad because the development ended in 2016, you're suggesting that the year (and before) was some kind of dark age for rust.

>Static, perfect code is rare.

My criticism isn't "hey, there's a lingering bug that no one fixed and which broke my use case". My criticism is, "The design of the exposed interface to the core library functionality forces me to care about irrelevant implementation details and enable attributes (mutability) that my use case doesn't need."

When you say that a project developed in 2016 can be expected to fail on that front, what you're saying is, 2016 was too early to expect developers of a major project (in a hot language followed by a lot of smart people) to understand the concept of separation of concerns and abstraction of irrelevant details.

Do you see why I might be skeptical of the relevance of the year of development?

There's a similar point to be made about (the lack of) clear examples, a concept that didn't spring into existence in 2017.

> When your immediate reply is to dismiss the dominant rust crypto library in 2016 as being understandably bad because the development ended in 2016, you're suggesting that the year (and before) was some kind of dark age for rust.

I was there and it actually was.

Rust 1.0 was just released and the ecosystem was mostly maturing at that point.

You're talking about version 0.2.36 of a library that had been in development for less than two years during a quite tempestuous time in Rust. I'm sure they were more concerned with making the code work, making it secure, etc.

When somebody says "have not been updated in a couple of years," they are really just saying that the code is unmaintained. Unmaintained code is bad code, no matter what year it is from.

Unmaintained code can explain edge-case bugs.

Lack of clear examples is not an edge case bug, it's failing to think about your user.

Breaking separation of concerns is not an edge-case bug.

I'm old, so I can assure you that, as of 2016, developers were well aware of the concepts of separation of concerns and abstraction. It being 2016 does not address the criticism I made. See also my longer reply.

https://news.ycombinator.com/item?id=19109660

For a security library to have no updates in a couple of years, I would consider it to be unmaintained and a huge risk.

I don't doubt that 2016 had some great libraries in rust, of which a lot are still used today. But most of them are updated to use new language features like `?` instead of `try!`, new macros system, async libraries, etc..

Take a look at a library like `serde`, which has been around since 2015 (https://crates.io/crates/serde/versions) and is awesome.

Rust 1.0 was in May 2015. No one's saying 2016 was a dark age, but the language has been moving quite fast since then. Even fundamental concepts like error handling have seen a major generation or two go by in that time (e.g. error-chain and failure). Many libraries from 2016 are still going strong, but a Rust library that hasn't gotten a commit in a couple years is much deader than the C++ equivalent.

Reply on news.ycombinator.com