I tried Diesel years ago, it was too "Rusty" for me. It made you define your schema twice, and couldn't use the same structs for inserts and selects (so 3 times, really). Overall, great first attempt at matching database types to Rust types, but the ORM needs to be more flexible and ergonomic - it's supposed to make writing queries easier, not harder :)

As for templates, writing your own language is almost a right of passage into 30s+ nerd club. I never read the dragon book, but I always wanted to take that class in school. There will always be different implementations of the same thing, and writing this one that mimics very closely what ERB (Rails) does felt right.

Same: I was put off by keeping track of models in triplicate, and the lack of automatic migrations. These are considered features, vice bugs; it's not for me.

I tried diesel about 5 years ago. I needed to do relationships where the foreign key lived on the other side of the relationship from what diesel wanted. IIRC diesel only supported the key on a specific side, I think it was a M:1 relationship. Diesel docs said this was unsupported. I was still learning traits at the time but navigating how to implement this in diesel was beyond me. I used sqlx and moved on.

Never been a fan of ORMs in general. Working with the extra abstraction layer on top of SQL can be painful.

Re ORM: fair enough, I don't have any experience with Diesel, just wanted to know if you have an actual reason or if it's just a case of NIH [0] syndrome :)

Re templates: I understand that writing a new template engine can be a very fun task (it is both hard enough not to be boring and easy enough not to feel daunting). I also thought many times of creating my own template engine to fix things that I don't like in the language that I am currently using (mostly jinja2).

But if you intend this project to become an actual production ready solution, I see a lot of good reasons not to reinvent template language:

1. Forcing users to learn yet another template language is an additional entrance barrier

2. Tooling support. Existing languages might already have a good tooling support (coming from Python world: PyCharm supports both Django templates and jinja2 very well) including syntax highlighting, auto-complete, auto-formatting, linting etc. Are you going to create all of it yourself?

3. You mentioned planned migration from Python. How exactly I am supposed to manage templates during the transition period? Do I have to have two copies of each template: one in legacy language and one in your new language? If you had a template language compatible with Django/jinja2 [1] this problem would not arise.

4. Whether we like it or not more and more people are using LLMs for coding. This potentially could solve the issue of migrating templates. I expect LLMs to perform really well on the task of "translating" a template from a <popular template language A> to a <popular template language B>. The problem is that if your template language is brand new, LLMs probably didn't have enough examples in their training sets to "learn" its syntax. So, basically, you are setting up your users for a boring, tedious and error prone task of rewriting each template manually without a proper support from their IDE/editor. Meh.

BTW, Django makes it very easy to bring your own template engine [2].

[0] https://en.wikipedia.org/wiki/Not_invented_here

[1] https://github.com/mitsuhiko/minijinja

[2] https://docs.djangoproject.com/en/5.1/howto/custom-template-...

In random order:

1 & 2. It's not really a new language. It's very similar to ERB, so existing tooling, including syntax highlighting, etc., shouldn't be an issue.

4. LLMs are actually pretty good at "understanding" programming language syntax and replicating it to generate code, so even a new language would work. Besides, there is really nothing new under the sun, so similarities with existing languages would help here.

3. I migrated once from Jinja to Sailfish [1], it wasn't so bad. All template languages are roughly the same: start code tag, some simple code, end code tag, maybe a loop or an if statement, but the vast majority of it is print a variable. It would be nice to bring your templates over during a migration, but they are typically a small portion of your code compared to business logic, so I don't think it'll be a roadblock, if someone wanted to attempt this at all.

[1] https://github.com/rust-sailfish/sailfish

By skimming docs I notice that you use <%- %> tags for outputting un-escaped strings. In contrast ERB uses <%- and -%> for trimming leading and trailing whitespace of the surroundings. In security sensitive context of escaping output you might not want to appear as mimicing ERB while deviating at the same time. A user might end up using un-escaped output all over the place by accident.

But great work overall!

Know of any similar frameworks that work the other way around? Where you can Keep an openapi definition as the source of truth and validate that your server follows it, I mean.

I agree. API-first is the way! Change your schema, auto-generate types into your code and use them for your server definition. It's just faster and more secure this way. Use api-fiddle.com or spotlight.io to work with the schemas (branching, sync with Github).

In a fully typesafe world, it should be pretty hard to derive from the shema this way.

Rswag is still my favorite openapi-related project. You write integration tests against the server and get an openapi spec as output. But thats for rails.

Just have to be a bit careful mentioning it in front of non tech folks who'll inevitably ask "what's arsewag?"

As others suggested, I would diff against a generated one, then potentially treat the generated one as source of truth in the future... Then diff accordingly as it changes.

You can simply diff it. Define the OpenAPI spec, have the framework generate a spec, compare.

You could generate a spec for the service and then diff to the expected perhaps.

Just FYI - since this is an asynchronous framework you probably would want something like sqlx versus Diesel (which is sync if I recall correctly)

diesel_async works great, and it's made by the lead diesel maintainer

https://github.com/poem-web/poem is one Rust framework with swagger definitions out of the box.

100% agree that generating OpenAI from your server is a killer feature, it works well for us with Dropshot.

>I would kinda expect REST framework to be able to generate Swagger (aka OpenAPI) definitions out of the box.

Me too, but, as I understand, this is a MVC framework that is returning HTML, not a framework to build web APIs.

It advertises "Built-in REST framework with JSON serialization" in the readme, that's why I asked.

Looks like it also supports some kind of models for JSON validation [0], it shouldn't be too hard to generate Swagger from them, just like FastAPI generates Swagger from Pydantic models.

[0] https://github.com/levkk/rwf/tree/main/examples/rest