21–30 of 115 posts
another web framework for rust (nice) I wonder how this par with something like https://loco.rs/
> And yes, there’s Loco (which, by the way, has started after the idea for Cot was born), which is a great framework, but [...]
The golden rule for making a website / readme for any programming language, web framework (or even GUI frameworks) is to have at least one or more code samples, so people can see what coding in your framework looks like.
I'll excuse it since it's a newish project it seems. :)
On that note, I'll be keeping a close eye on this one. This is the kind of web framework I look for, batteries included.
Cot's homepage:
Earlier quoted context omitted.
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.
I don't think it's a good idea to have a mix of both in a codebase, because then you'll have to be good at both - kind of defeats the purpose.
I actually find myself on crosspath where I did start with just SQL but now the database has grown a lot and it is just too much effort to keep writing queries as features pile up. Switching to ORM in one take would be nearly impossible but probably it could work as a step-by-step process, so have both SQL and ORM. Still thinking about this.
> The ORM is very lacking at the moment and the automatic migration generator only works with a small subset of possible operations, I would have hoped that by 2025, new projects would have moved away from ORMs entirely. They really are a useless abstraction layer that always brings tons of trouble and usually makes queries harder to write. Looking at the first example in the docs https://cot.rs/guide/latest/db-model…
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.
> The ORM is very lacking at the moment and the automatic migration generator only works with a small subset of possible operations, I would have hoped that by 2025, new projects would have moved away from ORMs entirely. They really are a useless abstraction layer that always brings tons of trouble and usually makes queries harder to write. Looking at the first example in the docs https://cot.rs/guide/latest/db-model…
Composability is the often cited benefit. As an example, I can do the following in Active Record (Ruby): class Account { where.not(active_at: nil) } belongs_to :user end class User (born_on) { where(birthdate: born_on) } end active_users_with_birthdays_today = Account.active.joins(:user).merge(User.born_before(Date.today)) Contrived, of course, but it's not hard to see how you can use these sorts of things to build u…
> The ORM is very lacking at the moment and the automatic migration generator only works with a small subset of possible operations, I would have hoped that by 2025, new projects would have moved away from ORMs entirely. They really are a useless abstraction layer that always brings tons of trouble and usually makes queries harder to write. Looking at the first example in the docs https://cot.rs/guide/latest/db-model…
What is the competitive landscape looking like these days for Rust web frameworks? I couldn't help but feel a bit insecure last time I was exploring the various options because none of them seemed to have the maturity or longevity of frameworks from other languages (for obvious reasons). Is there one framework that stands out from the rest from an "investment risk" perspective? In other words, if my company is going…
My go to is Axum + sqlx most of the time.
What about Django?
> The ORM is very lacking at the moment and the automatic migration generator only works with a small subset of possible operations, I would have hoped that by 2025, new projects would have moved away from ORMs entirely. They really are a useless abstraction layer that always brings tons of trouble and usually makes queries harder to write. Looking at the first example in the docs https://cot.rs/guide/latest/db-model…
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 mu…
Well sqlx checks at compile time your raw query if you use their macro, at the expense of increased compile times.