Hacker News Reader

Comment by mplanchard | Hacker News Reader

Why would code dependent on third party libraries break? It’s not like crates.io is going to stop hosting them when they become unmaintained. Barring security vulnerabilities, a library that does a well encapsulated task like parsing json might work just fine without updates for ten or more years.

In cases where libraries don’t keep up with changes in standards or whatever, yeah, you’re going to have to find another library. This is a part of our job that is pretty much unavoidable no matter the language. We should learn lessons like sticking dependencies you’re not certain about behind an interface to minimize the cost of switching if possible.

View on HN

> Barring security vulnerabilities, a library that does a well encapsulated task like parsing json might work just fine without updates for ten or more years.

JSON library updates are a constant tedious chore for many in the Java world. Jackson and Gson have both had several we've needed to make over the years. Now, _most_ of these are due to non-default features where you allow it to deserialize arbitrary types that we don't use. But clients big enough to insist on a BOM and internal security teams both just see "Jackson version x.y.z has a RCE on it, you need to update", even if it's literally impossible to trigger without changing the application code to enable insecure features.

You’re right, a json parser may have been a poor choice. Perhaps something like a UUID generator, or a parser for some more well-established and stable text format would be a better example.

On the other hand, something like a json parser needing to change all the time to support the ecosystem is another good reason to keep it out of the stdlib, IMO. There are limited hands to work on Rust itself, and I’d rather they spend their time making improvements to the core of the language, stabilizing features, and so on. As a user of rust, I’m willing to pay the cost of finding a good json library if it means I don’t need to update rust versions just to deal with some issue in JSON parsing.

At the same time, code that is "one and done" like a uuid generator is a much lower maintenance burden for the standard library.

Very true! I think the philosophy of letting external crates handle it and seeing how stable they are before considering inclusion in the stdlib is a good one here. Maybe in a few years we see that the uuid crate never needs updates and is super stable, so someone opens an RFC to pull it into std.

The thing is it’s easy to be wrong if you’re trying to predict up front what is going to wind up being stable and low maintenance and what isn’t, so the precautionary nature of what gets into the stdlib I think reflects that.

Lol, I do remember how an upgrade of a JSON serializer (JSON.NET in that case) broke an application. So, there was a .NET service publishing events to a queue with a bunch of consumers - a bunch of Golang service and (our) Scala service. One day our service starts crashing cause it can't parse the payload. We asked developers of the upstream service if they had change anything and they said "no, and by the way, other consumers are doing fine".

Turns out, they upgraded JSON.NET and it started to name fields in different case. Golang parser didn't really care about snake_case, camelCase or PascalCase but whatever parser we were using in Scala at the time actually did.

Reply on news.ycombinator.com