That's actually a very good point. I was thinking a lot about whether to make async a requirement. Given that sync code is often easier to reason about and debug and Cot tries to be developer-friendly, I'm leaning towards "sync by default, async when you need to", but I'll need to explore this more. Thanks for this thought!

I just had an issue yesterday in my company where a backend keeps crashing, because a function blocking the main thread, which means that the healthcheck endpoint was not responding... Async is definitely a needs

No threading either. Just a single thread serving one client at a time.

About the docs, there is a guide chapter dedicated to the ORM: https://cot.rs/guide/latest/db-models/

There are several reasons I don't like the existing ORMs in Rust, many of them being overly verbose, some generating unnecessary files, and having somewhat weird DSLs being the main reasons. The main reason, I think, was that none of them supports automatically generated migrations, and I absolutely loved that feature in Django. The differences between existing ORMs sound like a neat idea for another blog post, to be honest, so I'll probably do that soon!

Diesel absolutely can be used, there is no reason it can't - database support is feature flag-gated, so disabling it as as easy as adding one line in your Cargo.toml file. This, however, will obviously also disable some other features that depend on the database, such as authentication through database.

Whether building a custom ORM will be a good idea - only time will tell.

Naah it's perfectly good marketing: "for lazy developers" is way more catchy than "for perfectionists". Look how we discuss that.

You raised a good point

That would require programming in python, which as everyone knows, is not Rust.

If Django works for you, I'm absolutely not saying you should switch to Cot immediately! Some people like to have as many type-safety and compile-time checks as possible, so that's the crowd we're trying to satisfy.

this is rust community, "we" even try oxidizing linux

aside from joke, "I want every good thing about C++ but easiness of high level language" seems the norm

For people who don't understand: "gowno" means "shit" in Polish.

LOL, thanks for catching that ;) Will fix!

From the article:

> And yes, there’s Loco (which, by the way, has started after the idea for Cot was born), which is a great framework, but [...]

Good point! I'll add some code samples soon, thanks!

> Also, don’t use an ORM. Just write that SQL. Your future self will be thankful.

I have never understood this. I've been using the ORM for twenty years now, it's saved me countless hours, and I've very rarely needed to break out of it. When I did, I just wrote an SQL query, and that was it. What's the big deal?

Every one of the three points you made in your comment has been disapproved by Django.

It's a framework that does (or at least tries) to do everything (or as much as possible), and it's good. Really, really good.

I'm in the process of upgrading an app of mine after months of abandonment, and the process is so smooth it's boring.

Also, Django's ORM is the closest thing to a perfect tool. Sure, it has some dark corners here and there, but Django's ORM has considerably improved my quality of life as a programmer. Heck, I even moved from SQLite to PostgreSQL in an old project, and all I needed to do is to change a couple of config code.

Oh, and Django is both stable and enjoys a constant pace of updates adding useful features practically at every major version.

Composability is the often cited benefit. As an example, I can do the following in Active Record (Ruby):

  class Account < ApplicationRecord
    scope :active, -> { where.not(active_at: nil) }

    belongs_to :user
  end

  class User < ApplicationRecord
    scope :born_before, ->(born_on) { where(birthdate: born_on) }
  end

  active_users_with_birthdays_today = Account.active.joins(:user).merge(User.born_before(Date.today))

I've yet to see an ORM which doesn't just eventually make everything harder. Especially when it comes to automatic migrations, which seldom seem to take into account production necessities like multi-node deployment, downtime considerations and not destroying your production data silently because it doesn't fit.

Writing raw SQL is perhaps indeed easier for simple queries, but put some foreign keys inside or slightly more complex relationships between tables and you'll probably quickly fall into the trap of having to remember your entire database schema to write anything. Yes, the example from the documentation is slightly more complicated, but it checks at compile time the exact column names and types, so you get feedback much quicker than actually running the SQL query.

In addition to that, over the years of writing web services, I always found raw queries much less maintainable. The ORM immediately tells you that you messed up your refactoring, whether it is just renaming a column, or removing a table completely.

Pretty much every ORM (including the one in Cot) also allows you to write your own custom queries if the abstractions are not enough, so there's always this fallback option.

As long as it's still possible to also use SQL queries with it it's fine, right? I know some people who prefer using ORMs and some who like writing SQL.

ORMs, in my experience, fail the hardest when DB admins and web devs butt heads in when and where to create models. It can be an extra hurdle for data flexibility, but it clarifies data architecture at the beginning. In our Django environment, the DB admins won and we added `MIGRATE = False`.

It's 2025, and some ORMs are quite good (eg. Django, ActiveRecord). You can have an ORM with escape hatch of SQL. I do not understand the people who are so against ORMs.

I use ORM query interfaces 80% of the time, and for performance critical queries I can use direct SQL. But the query sanitization, smart preloading and performance checks, schema management and migration tools they often provide, and type checks / hints are really nice features of ORMs.

Furthermore, ORMs are ESPECIALLY useful in teams where you have more junior devs who need these guardrails.

I think the issue here is trying to reinvent a new ORM.

Nah. The query is $slug == LimitedString::new("cot")

Also, people like ORMs. Type safety is nice too without having to map manually. Sqlx is also great

I never worked with Rust, but maybe the complexity is due to how the language works.

Using Django's ORM, that would simply be: link=Link.objects.get(slug="cot")

It'd still be very readable and manageable even for complex queries.

ORMs are great. They afford abundant opportunities to look like a hero by swooping into a project and cutting a page load of forty seconds to under one second.

if you can decompose the query, you can unit test the logic against inmemory sets(or language specific equivalent).

Axum is most likely to be supported long term since it has quite a bit of support and is a Tokio project but it's not nearly as batteries included as something like Rails or Django. I doubt any of the current batteries included Rust web frameworks will last.

I would say pick Axum or Actix, these are the go to right now with lower risk to be abandoned, But they aren't batteries included. Here is a list of blessed[0] libraries that might help you to choose the most popular ones in their respective category, but at the end depends on you to pick the one that has the biggest community.

My go to is Axum + sqlx most of the time.

[0] https://blessed.rs

Yeah, it was a typo, just deploying a fix. Thanks!

That's one of the issues explicitly mentioned in the article ("Request Handler API is far from being ergonomic"). This will get better in the nearest future as it's a major pain point, I'm just thinking of the best API for doing request/responses.

Your BodyFactory example isn't even functionally the same as the quoted code snippet. Nowhere is the Body::fixed(rendered) equivalent seen, for example.