Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Rust API Inspired by Python, Powered by Serde

ohadravid.github.io

Post reply on HN
Print view View original

21–27 of 27 posts

Re: A Rust API Inspired by Python, Powered by Serde

#21

Post by olalonde »

dundarious wrote: post #20
olalonde wrote: post #19

Earlier quoted context omitted.

Why? It's much more verbose and error prone (e.g. "stringly typed"). Do you never deserialize JSON?

What's the difference between mistyping in the string here and mistyping in the struct definition? And yes I have.

You only need to get it right once, and from then on the compiler will catch any mistakes if you use it incorrectly. In contrast, every time you write obj.get_attr("DesiredSpeed"), there's a chance you'll make a typo and the compiler won't warn you about it.

Re: A Rust API Inspired by Python, Powered by Serde

#22

Post by LtWorf »

dundarious wrote: post #18
LtWorf wrote: post #15

Earlier quoted context omitted.

I wrote typedload in python. Once they show you an API with hundreds of types you appreciate not having to do like that all the time.

I don't see the issue with just using an equivalent to `impl Deserializer for ValueDeserializer` then.

There's unions, there's stuff that uses reserved words in the language as field names... You are obviously not familiar with this task.

Re: A Rust API Inspired by Python, Powered by Serde

#23

Post by dundarious »

LtWorf wrote: post #22
dundarious wrote: post #18

Earlier quoted context omitted.

I don't see the issue with just using an equivalent to `impl Deserializer for ValueDeserializer` then.

There's unions, there's stuff that uses reserved words in the language as field names... You are obviously not familiar with this task.

The "generic macro over struct definitions" approach is the one that has at least some trouble dealing with these situations, not the "getter function with string argument" approach. I've had to do plenty of json and protocol buffers wrangling (meaningfully different, I know), and versioned packed struct memcpy/reinterpret_cast "parsing" as well.

My point is I don't want to do "this task" at all if "this task" means layering funky auto-generated machinery on top of what is already a perfectly reasonable API.

Re: A Rust API Inspired by Python, Powered by Serde

#24

Post by unrealhoang »

lnyng wrote: post #10

Interesting post. We wrote this “below” utility [1] that monitor system metrics similar to atop. We want the ability to collect all metrics into a single object, pass it around and visualize it elsewhere. Naturally we need some way to query into fields or even nested-struct fields. For example, to get the file cache usage of a particular process, we need to go through sample->processes->pid->memory->file cache. To do…

Yes, serde is just a struct to visitors codegen infrastructure that you can rely on to do anything. https://serde.rs/data-model.html

Re: A Rust API Inspired by Python, Powered by Serde

#25

Post by snthpy »

ohr wrote: post #2

(Author here) I needed to do a bit of "reflection" in a Rust crate but didn't want to implement a procedural macro, so I used Serde (which is a (de)serialization crate) instead. This is also a deep dive into Serde internals - hope you'll like it!

Yes, great post! Thank you.

Re: A Rust API Inspired by Python, Powered by Serde

#26

Post by throw_a_grenade »

That's wdat minijinja does internally. As an argument to Template::render() you can give it any struct that implements Deserialize. That's how you can get varying (sic) variables to a single function and even attributes on "objects" processed by tte template.

Re: A Rust API Inspired by Python, Powered by Serde

#27

Post by xpe »

ohr wrote: post #13
xpe wrote: post #12

The title is vague in my opinion. What kind of API? What problem does it hope to solve? The article uses querying system data as examples, but after skimming it, I’m not sure why I would care. My comment is also a criticism of the article, since I couldn’t skim in quickly to figure out if I should spend more time on it.

(Author here) Thanks! That's useful feedback. I also agree - the final article isn't skim-friendly enough, which drives away some readers.

Glad you are open to feedback. My top question is: What kind of people do you want to read this and why?
Post reply on HN