#pavex — Public Fediverse posts

➡️ What you want:
Reduce complexity for #RustLang backend development 🤔

➡️ What you actually do:
Let people write weird Rust code using macros generating more code in a crate that is fed to a custom transpiler that generates multiple Rust crates that you are supposed to then build and use in production 🫨

On top of that, you introduce weird licensing so that teams need an activation key with a MONTHLY FEE 🤢

Thanks #Pavex… 😐

Rustaceans, just use #Axum 😉

➡️ What you want:
Reduce complexity for #RustLang backend development 🤔

➡️ What you actually do:
Let people write weird Rust code using macros generating more code in a crate that is fed to a custom transpiler that generates multiple Rust crates that you are supposed to then build and use in production 🫨

On top of that, you introduce weird licensing so that teams need an activation key with a MONTHLY FEE 🤢

Thanks #Pavex… 😐

Rustaceans, just use #Axum 😉

New year, old habits: a monthly report on my work on Pavex.
Or, to be sincere, a small essay on what I think good documentation looks like.
https://www.lpalmieri.com/posts/this-month-in-pavex-08/

#rust #pavex

New year, old habits: a monthly report on my work on Pavex.
Or, to be sincere, a small essay on what I think good documentation looks like.
https://www.lpalmieri.com/posts/this-month-in-pavex-08/

#rust #pavex

I'm done with last-minute API changes—Pavex is now code-complete (and doc-complete) for the beta 🔥

Invites to the first batch of beta testers should go out tomorrow 📆

#rust #pavex

I'm done with last-minute API changes—Pavex is now code-complete (and doc-complete) for the beta 🔥

Invites to the first batch of beta testers should go out tomorrow 📆

#rust #pavex

Quickstart tutorial for Pavex ✅

Next on the checklist: adding links to the relevant items in the API reference as well as linting to make sure that examples don't go stale.

#rustlang #pavex

Quickstart tutorial for Pavex ✅

Next on the checklist: adding links to the relevant items in the API reference as well as linting to make sure that examples don't go stale.

#rustlang #pavex

Je n'ai pas de projet web en vue, mais si à l'avenir je devais en avoir un, vu que d'ici là ça aura eu le temps d'avancer, à coup sûr le framework #Pavex fera partie des candidats potentiels.

https://www.lpalmieri.com/posts/pavex-progress-report-03/

Si vous ne voyez pas de quoi il s'agit : https://www.lpalmieri.com/posts/a-taste-of-pavex-rust-web-framework/

#RustLang

Borrow checking was one of my nightmares for #pavex.

The framework must generate _valid_ #rust code, which implies that pavex itself needs to be aware of the borrow checker.

After a few days of head scratching, it's working!
There are a few edge cases left, but the core works 🚀

Borrow checking was one of my nightmares for #pavex.

The framework must generate _valid_ #rust code, which implies that pavex itself needs to be aware of the borrow checker.

After a few days of head scratching, it's working!
There are a few edge cases left, but the core works 🚀

This is related to #pavex—I need to build the packages in the current workspace in a specific order, making sure to execute the code generation step _before_ trying to compile the generated code or any other crate that depends on it.

I could introduce a `cargo` subcommand (e.g. `cargo pavex build`), but it'd be cool to make it transparent.

This is related to #pavex—I need to build the packages in the current workspace in a specific order, making sure to execute the code generation step _before_ trying to compile the generated code or any other crate that depends on it.

I could introduce a `cargo` subcommand (e.g. `cargo pavex build`), but it'd be cool to make it transparent.

It looks like the next step for #pavex is becoming more aware of the borrow checker.

In particular:

1. emit code that passes the borrow checker where possible;
2. emit errors when it's impossible;
3. provide a "clone where needed" strategy for when you don't care.

A bit scared of tackling 1. and 2., it could be a significant time sink.

It looks like the next step for #pavex is becoming more aware of the borrow checker.

In particular:

1. emit code that passes the borrow checker where possible;
2. emit errors when it's impossible;
3. provide a "clone where needed" strategy for when you don't care.

A bit scared of tackling 1. and 2., it could be a significant time sink.

The API for nesting in #pavex
is now more or less settled.
What's left? Dealing with all the ambiguous situations that arise!

An example:
- the top-level blueprint defines a constructor for a singleton type, u64.
- the nested blueprint overwrites it.

What should happen?

This is ambiguous!
The nested route expects a certain constructor to be used.
The parent route expects another one to be used.

But the type is supposed to be a singleton, we can't create it twice!

#rust

The API for nesting in #pavex
is now more or less settled.
What's left? Dealing with all the ambiguous situations that arise!

An example:
- the top-level blueprint defines a constructor for a singleton type, u64.
- the nested blueprint overwrites it.

What should happen?

This is ambiguous!
The nested route expects a certain constructor to be used.
The parent route expects another one to be used.

But the type is supposed to be a singleton, we can't create it twice!

#rust

#pavex can now detect at **compile-time** if you are trying to extract a parameter that doesn't exist in the route template!

It's taking a lot of work, but our router is shaping up to be incredibly robust and I'm thrilled about it.

#pavex can now detect at **compile-time** if you are trying to extract a parameter that doesn't exist in the route template!

It's taking a lot of work, but our router is shaping up to be incredibly robust and I'm thrilled about it.

Thanks for #zero2production, for exploring the design space with #pavex, and especially for your focus on helpful, elegant error handling. @algo_luca

Thank you @zkat for #miette, it makes me happy to look at its error reports.

Thanks for #zero2production, for exploring the design space with #pavex, and especially for your focus on helpful, elegant error handling. @algo_luca

Thank you @zkat for #miette, it makes me happy to look at its error reports.

Six weeks have passed, it's time for another update on #pavex, the new #rust web framework I've been working on.

I've focused on the router in March: trying to nail a good API and, most importantly, great error messages.
It's looking quite promising!

https://www.lpalmieri.com/posts/pavex-progress-report-02/

Six weeks have passed, it's time for another update on #pavex, the new #rust web framework I've been working on.

I've focused on the router in March: trying to nail a good API and, most importantly, great error messages.
It's looking quite promising!

https://www.lpalmieri.com/posts/pavex-progress-report-02/

Introducing the concept of scopes to a codebase later in the game is always a messy business.

The implicit assumption that everyone can see everything has a way to percolate *everywhere*.

Why are we here?
#pavex needs to check at compile-time if your path extractor makes sense (i.e. does each field map to a route parameter?), which implies a way to go from a component to the relevant route.

E.g. RouteParams<HomeParams> => /home/:home_id

Introducing the concept of scopes to a codebase later in the game is always a messy business.

The implicit assumption that everyone can see everything has a way to percolate *everywhere*.

Why are we here?
#pavex needs to check at compile-time if your path extractor makes sense (i.e. does each field map to a route parameter?), which implies a way to go from a component to the relevant route.

E.g. RouteParams<HomeParams> => /home/:home_id

The more I work on diagnostics for #pavex, the more I appreciate all the effort that went into #rust.

To call it "done" I have to find a way to include code snippets into the `help` section (using green/red for addition/deletions).

The more I work on diagnostics for #pavex, the more I appreciate all the effort that went into #rust.

To call it "done" I have to find a way to include code snippets into the `help` section (using green/red for addition/deletions).

How difficult is it going to be to support trivial specialization in #pavex? I'm about to find out 🔥

The idea being: you can register a generic constructor for a type (e.g. `Json<T>`) and provide a more specific one (e.g. `Json<u64>`) that will take precedence.

This is supposed to work exclusively in simplest case - i.e. your "more specific" constructor cannot have any unassigned generic type parameter.

How difficult is it going to be to support trivial specialization in #pavex? I'm about to find out 🔥

The idea being: you can register a generic constructor for a type (e.g. `Json<T>`) and provide a more specific one (e.g. `Json<u64>`) that will take precedence.

This is supposed to work exclusively in simplest case - i.e. your "more specific" constructor cannot have any unassigned generic type parameter.

Quite happy with how the route conflict error is shaping up in #pavex!

I have to do some work on sub-diagnostics (i.e. how to show multiple code snippets in a single error), but that's more of a general tech debt thing.

Quite happy with how the route conflict error is shaping up in #pavex!

I have to do some work on sub-diagnostics (i.e. how to show multiple code snippets in a single error), but that's more of a general tech debt thing.

Kicking off a new experiment: monthly progress reports for #pavex.

The first alpha is months out, so I want to try to keep the project on people's mind in the meantime.

The first report is _almost_ ready to go. I managed to do the tough part, writing the introduction 👀

Kicking off a new experiment: monthly progress reports for #pavex.

The first alpha is months out, so I want to try to keep the project on people's mind in the meantime.

The first report is _almost_ ready to go. I managed to do the tough part, writing the introduction 👀

The work on #pavex continues, slowly but surely.
I'll probably whip together a progress report in the next week or so.

In the meantime, crossed a new milestone: the #rust reflection engine can now handle all "common" response types!

The work on #pavex continues, slowly but surely.
I'll probably whip together a progress report in the next week or so.

In the meantime, crossed a new milestone: the #rust reflection engine can now handle all "common" response types!

@dragnucs this is a bit of a blind guess, but perhaps look up #pavex by @algo_luca, from what I understand it’s going in that direction.

@dragnucs this is a bit of a blind guess, but perhaps look up #pavex by @algo_luca, from what I understand it’s going in that direction.