#Getty - A serialization framework and library

1 messages · Page 1 of 1 (latest)

wind jungle
#

Hello! 👋

The 0.2 release for both Getty and Getty JSON is out! This release comes with quite a bit of ergonomic changes (e.g., simpler interfaces, type-defined blocks, customization attributes), performance optimizations, API documentation, and bug fixes. Be sure to check it out if you're wanting to write a serializer or deserializer!

0.2 Release Notes:

For those of you new to Getty:

  • Getty (https://github.com/getty-zig/getty) is a serialization framework designed to help you write (de)serializers (think Serde, if you're familiar with Rust). By using it, (de)serializer implementations become much simpler and automatically gain features such as support for various std types and the ability to easily customize the (de)serialization process.

  • Getty JSON (https://github.com/getty-zig/json) is a serialization library for the JSON data format. With 0.2, Getty JSON is now as fast as or even faster than std.json for pretty much everything! 🎉

Resources

oak aurora
#

Do you have benchmarks?

wind jungle
#

Not any formal ones yet, I've just been using Hyperfine and (de)serializing a bunch of different values/types. I'm planning to add some though soon.

I did do this benchmark: https://github.com/kostya/benchmarks, and Getty JSON and std.json ended up being neck-and-neck. idk if they'd accept a PR for Getty though

#

Here's a run for that benchmark

$ make run
/Library/Developer/CommandLineTools/usr/bin/make run[target/json_zig]
../xtime.rb target/json_zig
"Zig"
test.Coordinate{ .x = -4.999670886454214e-30, .y = 5.0060955478879725e+30, .z = 4.9989645505898717e-01 }
0.567 s, 0 Mb, 0.0 J

/Library/Developer/CommandLineTools/usr/bin/make run[target/getty_zig]
../xtime.rb target/getty_zig
"Zig"
main.Coordinate{ .x = -4.999670886454214e-30, .y = 5.0060955478879725e+30, .z = 4.9989645505898717e-01 }
0.572 s, 0 Mb, 0.0 J
wind jungle
#

That benchmark's just for deserialization btw, for serialization Getty JSON is generally faster. For example,

  • Serializing a large integer 100,000 times is 71x faster in Getty JSON: https://zigbin.io/566237
  • Serializing a string 100,000 times is 1.45x faster in Getty JSON (larger strings or strings with lots of escaped characters can be 2-3x faster): https://zigbin.io/ac5eb3
analog whale
#

Question: why do you have to declare all the functions (.{ serializeBool = serializeBool }) instead of making a generic function that takes a struct with said methods? I haven't looked in-depth so excuse my ignorance.

wind jungle
# analog whale Question: why do you have to declare all the functions (`.{ serializeBool = seri...

np, here are a few reasons why I didn't want to do the struct approach:

  • Type safety becomes a lot more hacky as I'd have to manually write checks for each decl to see if they're correct instead of just letting the compiler do it for me.

  • Names become an issue. With struct fields, you can name your method impls whatever you want. But with struct decls you gotta make sure they have the same name as what the interface wants, which can cause conflicts or be inconvenient for types that implement multiple interfaces with similar required method names.

  • I like having the signatures for each required method in the signature of the interface. With struct decls, all you'd see is type. You'd have to actually look at how the interface is implemented to see which functions are required, which is an absolute pain.

  • This is a personal preference one, but I like to be able to see every interface method that a type implements up front. I don't want to have to search for them to find out, especially not for types that implement interfaces like getty.Serializer which has like 12 methods.

analog whale
#

Fair points, thanks! Getty looks really nice by the way.

wind jungle
#

Thanks! 😄

ocean oriole
#

This is neat! Beautiful website, and nice use of autodoc too. Encouraging use of usingnamespace in Serializers is an interesting choice.

I noticed the examples and explanations are JSON-centric. Does the fact that your intermediate data model has a limited set of types make it impossible to de/serialize formats with a more detailed set of primitives, like ASN.1 (insert preferred encoding here)?

wind jungle
#

Thanks for the kind words!

In general, any data format Serde supports, Getty should as well. You can see a non-comprehensive list here: https://serde.rs/#data-formats.

For ASN.1 specifically, it does seem to be a slightly poorer fit for Getty and Serde due to its complexity (https://users.rust-lang.org/t/comparison-of-way-too-many-rust-asn-1-der-libraries/58683/9?u=jschievink). Mapping it to Getty may be challenging/impossible, so you’d probably be better off implementing a (de)serializer by hand. That being said, there is a ASN.1 (DER) Serde crate so it may be possible for some encodings: https://github.com/alex/rust-asn1.

wind jungle
#

New project site for Getty is finished: https://getty.so

  • The site now uses mkdocs instead of Jekyll. And it is sooooo much nicer to use.
  • The guide has been updated and improved a ton.
  • The pages covering Getty's design and concepts have been fleshed out and improved.
  • There's a dark mode! The diagrams also change color, which is a neat feature in mkdocs.
nocturne lantern
#

Agh, getty is already a project name! x)

#

getty, short for "get tty", is a Unix program running on a host computer that manages physical or virtual terminals (TTYs). When it detects a connection, it prompts for a username and runs the 'login' program to authenticate the user.
Originally, on traditional Unix systems, getty handled connections to serial terminals (often Teletype machines)...

#

Also Getty is the name of a huge image site

wind jungle
#

it's also the name of a museum in LA. it was pretty awesome when I went there

nocturne lantern
#

Why "getty" then?

wind jungle
#

Named it after a character in a series I like

wind jungle
#

Yes

cursive wren
wind jungle
#

Getty 0.3.0 and Getty JSON 0.3.0 are out!

You can check the release notes down below for more details, but here are some notable changes:

  • Some new std types have made their way into Getty, including std.ArrayHashMap, std.PackedIntArray and std.net.Address.
  • With the new deserializeAny method, users can now deserialize from multiple possible data types.
  • The skip and rename attributes are now supported for unions.
  • Type-defined blocks no longer require an is function.
  • Deserialized values can now be ignored with the getty.de.Ignored type.

Release Notes

wind jungle
#

Getty 0.4.0 and Getty JSON 0.4.0 are out!

You can check the release notes down below for more details, but here are some notable changes:

• New std types have made their way into Getty: std.MultiArrayList, std.SemanticVersion, and std.IntegerBitSet.
• Support for the official Zig package manager has been added (and has replaced unofficial package managers).
• Serialization blocks can now allocate, if needed.
• Lots of bug fixes.

Release Notes

• Getty: https://getty.so/blog/announcing-getty-040/
• Getty JSON : https://github.com/getty-zig/json/releases/tag/0.4.0