HN Reader

The post mentions an ORM, but the docs don’t provide any examples of how it works. How does the Cot ORM compare to Diesel? There are certainly places where I find Diesel falls short of, say, ActiveRecord (like traversing relationships via “includes”/“eager_load”/etc.). I’m not convinced that these shortcomings warrant a separate ORM as opposed to making contributions to Diesel, but I’m open to being wrong. Are there any particular shortcomings that motivated starting from scratch? One thing I really like about Rust dev is the way ORM and API server concerns are separated. Will Cot’s server support using Diesel? Can it be used without the ORM package being involved at all?

The Rust ecosystem needs more high-level frameworks like this. However, I've been shipping Django since 0.96, and I don't think Cot really addresses the main issues Django currently has. Performance isn't in the top 5.

Django's biggest issue is their aging templating system. The `block`, `extend` and `include` style of composition is so limited when compared to the expressiveness of JSX. There are many libraries that try to solve Django's lack of composition/components, but it's all a band-aid. Today, making a relatively complex page with reusable components is fragile and verbose.

The second-biggest issue is lack of front end integration. Even just a blessed way of generating an OpenAPI file from models would go a long way. Django Ninja is a great peek at what that could look like. However, new JS frameworks go so much further.

The other big issue Django has _is_ solved by Cot (or Rust), which is cool (but not highlighted): complicated deployments. Shipping a bunch of Python files is painful. Also, Python's threading model means you really have to have Gunicorn (and usually Nginx) in front. Cot could have all that compiled into one binary.

I would love a Django clone in Rust that does NOT do async. Dead simple to debug instead of performance oriented.

I think Django's marketing for perfectionists with deadlines is a bit better than "for lazy developers" :) but excited to see people build "Django, but compiled"

another web framework for rust (nice)

I wonder how this par with something like https://loco.rs/

The “Ready to Get Started?“ section on the Cot site is line-breaking awkwardly on mobile.

Good stuff, can't wait to see more features :)

Also, +1 for

> struct GownoApp;

Frameworks that do “everything” are not a good idea. I’m from the Java ecosystem. Spring is the “batteries included” framework there. If you have migrated any real world application to a new major version once, you’ve learned forever that “all in one” frameworks are bad. Please don’t do it!

Instead, use scaffolding tools, that give you a head start on creating a new project, using smaller, specialized libs.

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

What's funny is its obviously in early stages, but its homepage doesn't show an immediate code sample. I find it funny because you are trying to appeal to lazy devs but making them work to get to any code samples.

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:

https://cot.rs/

Anything that has Oauth2 integration with Github, Google, Facebook, etc. out of the box is going to win this by a country mile. That's by far the most annoying thing about setting up any website that has user accounts in my experience.

>Cot was born out of frustration - the kind that every Rust developer feels when searching for a batteries-included, Django-like web framework

What about Django?

Leaving a mention of Tuono to those looking for new Rust web frameworks. It's closer to Next.js and allows fast server-side rendering of React apps:

https://github.com/tuono-labs/tuono

I would suggest avoiding the frontend proc like SCSS pre processors and use a proper bundler like Tailwind instead.

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 to choose a framework to build a website, which one has the lowest odds of burning me by becoming abandoned or unsupported?

Ok(Response::new_html(StatusCode::OK, Body::fixed(rendered)))

no thank you. if you like it good for you, for me this looks worse than

Body body = BodyFactory.newInstance(BodyConfiguration.OK)

which is still SHORTHER and less cancer

Blog post date says 18th February 2024. Is this a 1yr anniversary post, or a typo? :)

Lots of “Rails but for X” projects exist in various states, for various languages, but have failed to gain traction and stand abandoned.

…like, a lot.

I thiiiink, fundamentally, it’s a harder-than-it-looks problem space and if you come out with something that’s rough and broken, it never gains enough critical mass for it to become self sustaining.

What’s the “pitch”? It’s can’t be “Django but for rust but it’s kind of not ready yet”, bluntly.

So it needs to have some outstanding feature or accumulation of features that let it stand out from the other 30 rust web frameworks. Is there something here?

You really need to call out the “why another rust web framework” in more than just terms of ambition, imo.

> 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-models/#retrieving-models

    let link = query!(Link, $slug == LimitedString::new("cot").unwrap()).get(request.db()).await?;

I really don't get the point, and that'll certainly get worse with any somewhat non-trivial query.

Why go through all the trouble of reinventing a new DSL when the SQL equivalent would be so much cleaner?

    SELECT * FROM link WHERE slug = 'cot';