m4tx

Shameless plug: I've been developing https://cot.rs/ for a while, which is strongly inspired by Django, and auto migrations, admin panel, auth, etc. are among the features supported by Cot.

Shameless plug: the lack of a fully batteries-included framework (with DB, auto migrations, admin, etc.) is one my biggest gripes in Rust - and that's why I've been developing https://cot.rs/ for a while.

Thanks - fixed!

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.

Agreed! This is also something that I personally want to use in my services, so this will definitely be a first-class citizen in Cot very soon.

Thanks a lot for this extensive feedback!

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!

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 point! I'll add some code samples soon, thanks!

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.

LOL, thanks for catching that ;) Will fix!

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.

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.

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.

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

Yes, the project was fun, yet simple and fast to write! I was thinking about doing some more advanced optimizations, although I believe the opportunities for that are pretty limited for Brainfuck. Also, I think the code is pretty nice and clean and generic enough to be partially moved to another possible project, which is the gain of doing things more generic than they actually needed to be.

You said you were working on another JIT - what was that? Also, do you have any suggestions of another project/language to implement compiler for to gain some knowledge about writing optimizations, actual intepretation/compilation logic, etc?

Thanks for the additional resources about the instruction encoding - seems like this is a bit easier to understand than AMD64 documentation!