While I generally agree with your comment, a lot of people actually use it because they don't use a password manager and it's more convenient then.
One additional benefit to having OAuth2 support though is that you can easily set up SSO if needed (and you don't care about SAML or other SSO protocols). For me personally this will be useful for an NGO that I'm running where we have Google Workspace effectively serving as a Single Sign On server.
Yea, I'm not ragging on the parent for the choice they made. There's a lot of services it's just not worth the effort, and many people do find oauth2 to work just fine.
About performance: I agree, and I'm not even trying to make performance a priority in Cot. I mean, of course, it's nice to have an actual compiled language, but I think a bigger perk in using Rust is having *a lot* of stuff checked in compile time, rather than in runtime. This is something I'm trying to make the main perk of, and it is reflected in multiple parts in Cot (templates checked at compile time, ORM that is fully aware of database schema at compile time, among many others).
About JSX: I think that's the one I'll need to explore further. In my defense, the templating system Cot currently uses (Rinja) is much more expressive and pleasant to use than Django's, but admittedly, the core concepts are very similar. This one might be difficult to address because of an ecosystem of templating engines that is pretty lacking in Rust, but I'll see what I can do to help this.
About front-end integration: that's something that will be (at least partially) addressed no later than v0.2. Django REST Framework is a pain (mostly because it's never been integrated in Django), Django Ninja is something I haven't personally used very much - good to have it mentioned so it can be a source of inspiration. Generating OpenAPI docs is something that's even mentioned in the article "Request Handler API is far from being ergonomic and there’s no automatic OpenAPI docs generation" so yeah, I'm aware of this.
Deployment is indeed something that's super nice – and a part of this is that newer Rust versions generally don't break compatibility with existing code, unlike Python. I agree this should be highlighted, thanks for suggestion!
You could potentially address both templating and front-end integration by adopting Dioxus which does full stack rendering with React-like components (but in Rust). A "batteries included" full-stack framework could be quite exciting I think.
Yeah, that's something I'm painfully aware of. Part of the reason I'm starting to push hard even though it's not ready yet is to gain as much feedback as early as possible to avoid expensive mistakes in the long run. Is that a mistake – I don't know, we'll see.
The main selling point for now is the admin panel and the custom ORM that handles automatic migration generation. There are a lot of finer differences as well, and I'll add a comparison table soon since that's something I'm (expectedly) getting asked about quite frequently.
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!
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.
Good call. Django's admin site functionality was the killer app for me, so if I'm going to hop off Django to something else then I'm going to want to compare that feature closely.
Agreed, and what you mention here are the main reasons Cot has been strongly inspired by Django. Whether we'll achieve the same level of stability and ORM ease-of-use for the Rust-preferring community, only time will tell.
