Hacker News Reader

Comment by stu2b50 | Hacker News Reader

I’m not sure I understand the “infrastracture” label, but certainly for the cases the author listed as “infra” typing can be cumbersome. Famously just json deserialization can be rather painful in statically typed languages, especially ones without complex compile time features.

View on HN

> Famously just json deserialization can be rather painful in statically typed languages, especially ones without complex compile time features.

That's funny, because last time I had to write json-related code in Python, I really missed Rust's serde, which makes deserialization + validation much easier to write in Rust than in Python.

YMMV, of course.

Pydantic is that for Python

Thanks, you remind me why I wanted to try Pydantic :)

Hum... Almost all of the problems of serialization/deserialization in statically typed languages turn into testing problems in dynamically typed languages.

That's not a gain in any way.

In this case it’s more about shifting where the static typing occurs, since the author is still arguing for a typed business layer.

Since I/O is usually untyped, you need to cram it into a typed schema somewhere. In strictly typed languages, that must occur upon ingestion. The author is saying you can delay it by having a layer on top of the I/O transform the data in untyped fashion before being typed later on.

What's the benefit of delaying typing? By typing it at ingestion, you guarantee that invalid (with respect to structure) untrusted data will not break your code down the line. Doing otherwise means that you're manipulating untrusted data with a strong risk of forgetting that it is untrusted.

I have seen large applications (think hundreds of millions of daily users) break because of such oopses.

Serialization/deserialization can be really gross in something like Java, but TypeScript gives you some really good tools (zod, typebox, etc.) to validate and type-guard your inputs that I'm sure could be implemented in Python--if they're not already.

Pydantic will do that for Python.

Yeah, I assumed as much. I've only looked at Pydantic in the context of FastAPI, as Python's not really my thing, but it looks really well-thought-out.

If serialisation is painful in Java, you're doing it wrong.

Libraries like Jackson make it entirely painless.

I would assume JSON parsing is a solved problem in any typed language.

I've written a lot of code using Jackson and I strongly disagree that it's a solved problem. If you're Java on both ends, it's probably fine, but then your serde style is an implementation detail. And that's great, but if you're not, you are in a bear pit. The lingua franca for JSON specification is JSON Schema, and there is significant impedance mismatch between the standard JSON tools folks use in Java and with JSON Schema as used by most other folks. (Jackson has a nice JSON Schema module for exporting it, but importing/codegen is pretty gross.)

I find Java pretty nice for handling JSON serialization/deserialization these days. Just define some records for the expected structure, and Jackson's object mapper handles the rest.

It's the "defining some records" part that's slow and gritty. JSON is usually an interchange format, and Java class construction is either slow, tedious, and manual, or involves massaging a code generator (which, at least the last time I checked a few months ago, weren't very good in Java).

I don’t see how declaring a data model class is anymore difficult in Java than another typed language.

  record Thing(String name, int size, LocalDate when) {}

The only way I could see this being easier is to forgo type safety completely.

You're assuming you only have to define it in one language. JSON is an interchange format. The canonical way to express it is JSON Schema, and the tools are unpleasant in Java. So is dealing with structural typing of polymorphic responses. In an ideal world we wouldn't have those, but we live in this one.

These things are just better when you aren't in a nominatively typed language with some pretty crusty assumptions.

Reply on news.ycombinator.com