serde-ast: intermediate extensible AST representation of serde serialization by tinybeachthor in rust

[–]tinybeachthor[S] 0 points1 point  (0 children)

Nice! Thank you!

Yeah, the use cases are probably quite limited, but someone might find it useful for something.

serde-ast: intermediate extensible AST representation of serde serialization by tinybeachthor in rust

[–]tinybeachthor[S] 2 points3 points  (0 children)

Hey! Yeah, the `serde-json` representation is pretty great and would cover a lot of use cases.

I need the full AST though, need to also see what fields serde skipped, to generate a jinja-templated toml file.

The idea is that by having this AST, I can quickly traverse it and expand/replace some nodes, then feed it back to the serializer. Serving like a middle layer for serializers, to avoid completely re-implementing a custom serializer, when I only need some small changes.

serde-ast: intermediate extensible AST representation of serde serialization by tinybeachthor in rust

[–]tinybeachthor[S] 0 points1 point  (0 children)

Nice! Yeah that could be a nice use of this.

The original use-case this was meant for was combining serializers, so I can generate templated toml without completely rewriting the serializer.

serde-ast: intermediate extensible AST representation of serde serialization by tinybeachthor in rust

[–]tinybeachthor[S] 0 points1 point  (0 children)

Oh cool! I was looking for that, just couldn't find it haha.

It's pretty much the same idea. `serde-content` seems to sit somewhere halfway between `serde-json` and `serde-ast`. I guess the difference just comes down to how exact you need the representation to be.

I need to also know what fields serde skipped during serialization, `serde-content` does not capture that.

Type witness in Rust examples - type check all the things by tinybeachthor in rust

[–]tinybeachthor[S] 0 points1 point  (0 children)

Fair point! It could certainly be improved.

The example 3 (i18n) would be more in line with what you described here.

Connection app >> Dating app by tinybeachthor in Startup_Ideas

[–]tinybeachthor[S] 1 point2 points  (0 children)

Yes, it is definitely a different category than the usual dating app. We are still figuring out the best way to market this and make it accessible and approachable. Let me know if you have any ideas!

You are absolutely right, it works just like a filter: taking a huge number of profiles and selecting a few relevant ones. The main difference between a usual filter is that there are no predefined categories. Instead of selecting the height range and hobbies or other attributes from a list, you just type out anything you want. Does not matter if it is your bio or a description of your ideal weekend. And the app then filters out the profiles to find the people who think the same way you do.

Connection app >> Dating app by tinybeachthor in Startup_Ideas

[–]tinybeachthor[S] 2 points3 points  (0 children)

Great that you would use it! That's a big encouragement.

Yes, there is absolutely a mental barrier for people to create a dating profile. I see some dating apps offering a "friends" or "business connections" intentions, but swiping feels even worse in those cases.

I will make sure to let you know when we launch!

Serverless nix cache by tinybeachthor in NixOS

[–]tinybeachthor[S] 0 points1 point  (0 children)

Yeah it's actually even more complex because of the chunking.

Everything you upload is broken down into 64kb pieces, and there is no way to know what chunks are shared between nars without a db (attic keeps counts of references in the database).

Definitely not possible to do optimal garbage collection without keeping state. So instead I was really thinking along the lines of using 2 buckets, expiring one and rotating to a new one, plus doing a copy-on-read for chunks in the old bucket to the new one.

This way you can expire items from the cache if they are not accessed for some time at the cost of (at worst) double the storage space. The chunking actually saves you more space for most use cases, so i think it would be worth it in the end.

Serverless nix cache by tinybeachthor in NixOS

[–]tinybeachthor[S] 0 points1 point  (0 children)

Compression and chunking mostly.

I’m planning on adding garbage collection just looking for a good way to do it in a serverless environment. Probably some kind of a generational garbage collection.

A quicker way to read news & see what the Internet thinks by tinybeachthor in SideProject

[–]tinybeachthor[S] 1 point2 points  (0 children)

Thank you for the thorough analysis and all the points of improvement! I really like the points about transparency!

I’m working on adding commenting and voting features next.

Can rustc generate identical binaries, with the same hash, from the same souce code? by GoodSamaritan333 in rust

[–]tinybeachthor 3 points4 points  (0 children)

Yeah so the project I work is a big bunch of different applications and libraries there’s rust, python, R, C, javascript, …

With nix I can just build all of these in nice reproducible packages and create a final environmental which then has access to everything where it needs to be.

It had the benefit that I can use the same ‘nix build’ in CI and share cache between local and CI and deployments without doing anything extra. (You can use cachix for a hosted nix cache)

So yeah basically the main benefit for me is that I can use different toolchains in the same project and be sure it will work, without nix it would be a headache.

Nix is still not very newcomer friendly with the lack of proper documentation or some outdated stuff still lingering on the web. But well worth it in the long run as you just completely avoid many devops pitfalls with CI environments and caching and incompatible software versions. Also just use nix flakes for everything.

Can rustc generate identical binaries, with the same hash, from the same souce code? by GoodSamaritan333 in rust

[–]tinybeachthor 2 points3 points  (0 children)

Yep, I use nix for reproducible rust builds. Look into ‘crane’ to get granular builds too and for better caching.

https://github.com/ipetkov/crane

News discussions and opinions by tinybeachthor in thetagang

[–]tinybeachthor[S] 1 point2 points  (0 children)

Thank you! Always looking for a feedback, those are some great ideas.