Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Cot: a Rust web framework for lazy developers

mackow.ski

Post reply on HN
Print view View original

91–100 of 115 posts

Re: Show HN: Cot: a Rust web framework for lazy developers

#91

Post by m4tx »

TransAtlToonz wrote: post #90
IshKebab wrote: post #87

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.

I understand people use these logins, but I'm not trusting a third-party login to gate access to anything I might miss. It's already annoying enough that there are virtually no access guarantees for a service , but to add a second point of failure is a risk I'm not going to take if I have any fear of losing access. For something like TikTok where I can download the recipe videos the risk is appropriately low, but tha…

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.

Re: Show HN: Cot: a Rust web framework for lazy developers

#92

Post by cess11 »

iterateoften wrote: post #46
sgarland wrote: post #32

Earlier quoted context omitted.

The thought process can be the same in SQL. You can start by writing SELECT * FROM Account; then add your JOIN to User, then add your predicates. Then you can refine it – here, if I’m understanding the code correctly, you’re using User for a JOIN but never return anything from that table, so you could turn it into a semi-join (WHERE EXISTS) and likely get a speed-up.

> then add your predicates How are you canonically storing these predicates in code to reuse over 5-10 queries?

Why would you want to?

Re: Show HN: Cot: a Rust web framework for lazy developers

#93

Post by throwway120385 »

ygouzerh wrote: post #77
ldng wrote: post #75

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

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

There are two competing use cases for web frameworks. In embedded systems you might have one or two users for a web page, and the page exists because you don't want to put a display on the device. That's where a synchronous approach really shines because it's easy to reason about and therefore doesn't break very often. Contrast that with a traditional web site with a backend, frontend, and thousands or millions of users. In that case, async code is easier to reason about because each visitor probably isn't interacting with the same elements of your model at the same time, and if they are you can define how those interactions work and enforce synchronization using the database. So it's not an either/or, but rather two approaches that address totally different situations.

Re: Show HN: Cot: a Rust web framework for lazy developers

#94

Post by TransAtlToonz »

m4tx wrote: post #91
TransAtlToonz wrote: post #90

Earlier quoted context omitted.

I understand people use these logins, but I'm not trusting a third-party login to gate access to anything I might miss. It's already annoying enough that there are virtually no access guarantees for a service , but to add a second point of failure is a risk I'm not going to take if I have any fear of losing access. For something like TikTok where I can download the recipe videos the risk is appropriately low, but tha…

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…

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.

Re: Show HN: Cot: a Rust web framework for lazy developers

#95

Post by submain »

iterateoften wrote: post #63
submain wrote: post #37

Earlier quoted context omitted.

ORMs are one of those things that make sense for really tiny projects but fail to scale once complexity settles in.

Exact opposite experience. “SQL strings are one of those things that make sense for really tiny projects but fail to scale once complexity settles in“ Large projects require reuse, composability and easy refactoring. All things ORMs excel at. On a small code base it is easy to rename a column or add a column, etc. On a large code base with already 100s of queries using that table, without an ORM it isn’t as straightf…

Type checking is indeed an advantage of ORMs. You pay for it with object relational impedance mismatch. That impedance grows as your schema grows.

In my experience, the way to get the best of both worlds is to use a query builder as opposed to a full ORM.

Re: Show HN: Cot: a Rust web framework for lazy developers

#96

Post by hu3 »

ygouzerh wrote: post #77
ldng wrote: post #75

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

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

Usually non-async frameworks spawn some kind of thread so that it never blocks or crashes the main process regardless of what happens to the threads.

I know Go frameworks are usually like that. They spawn green threads and you can write HTTP handlers using simpler sync code to handle requests without worry.

Re: Show HN: Cot: a Rust web framework for lazy developers

#97

Post by nicoburns »

m4tx wrote: post #88
blopker wrote: post #84

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…

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 (temp…

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.

(Disclaimer: I work on dioxus's native renderer)

Re: Show HN: Cot: a Rust web framework for lazy developers

#98

Post by iterateoften »

cess11 wrote: post #92
iterateoften wrote: post #46

Earlier quoted context omitted.

> then add your predicates How are you canonically storing these predicates in code to reuse over 5-10 queries?

Why would you want to?

The fundamentals of software design. DRY

If you have a complex predicate that defines a set of rows, and you use that set in many different queries, are you rewriting it each time?

Re: Show HN: Cot: a Rust web framework for lazy developers

#99

Post by tcfhgj »

bkummel wrote: post #35

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…

I pulled a WebApp from Angular 4 to Angular 18
Post reply on HN