chrono VS jelly-actix-web-starter

The problem is that this effects higher languages too, because they often build on libc. And on some OSes, they don't have a choice, because the system call interface is unstable and/or undocumented).

For example in rust, multiple time libraries were found to be unsound if `std::env::set_env` was ever called from a multi-threaded program. See:

https://github.com/time-rs/time/issues/293 and https://github.com/chronotope/chrono/issues/499

https://github.com/rust-lang/rust/issues/27970

https://github.com/rust-lang/rust/issues/90308

> I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often.

I indeed did this years ago---I'm the original author of Chrono [1]---and it wasn't well received [2] [3] [4]. To be fair, I knew it was a clear violation of semantic versioning but I didn't see any point of obeying that until we've reached 1.0 so I went ahead. People complained a lot and I had to yank the problematic release. By then I realized many enough people religiously expect semantic versioning (for good reasons though) and it's wiser to avoid useless conflict.

[1] https://github.com/chronotope/chrono

[2] https://github.com/chronotope/chrono/issues/146#issuecomment...

[3] https://github.com/chronotope/chrono/issues/156

[4] https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#...

On that note, it would also be good to configure cargo-deny so that a CI pipeline and any maintainer can easily audit the current dependency versions. Sometimes CVEs require a new major semver (looking at you, time 0.1.x and thus chrono 0.4.x), so it's not enough to rely on people installing the tool with semver-compatible updates. Automatically auditing dependencies is really important, and given how easy cargo-deny makes it, I don't think many projects have any excuse not to configure it.

The example has been randomly taken from the [Chrono][https://github.com/chronotope/chrono/blob/main/src/offset/utc.rs] crate.

libc isn't "just a wrapper". Is a massive legacy codebase filled with hacks, UBs and bugs: https://github.com/chronotope/chrono/issues/499

Would love to have people test this, you can leave feedback here: https://github.com/chronotope/chrono/issues/674.

Security issues? I'm looking at the open issues, but haven't noticed any that seem to be security related (no security related labels either). What am I missing here?

You can look at https://github.com/secretkeysio/jelly-actix-web-starter

My usual reminder that I have a Django-ish template for actix-web that I maintain: https://github.com/secretkeysio/jelly-actix-web-starter

Now that actix-web 4.0 is out I should be able to finally resolve one of the open issues/PRs, which I was waiting on 4.0 for.

For those interested in Django-in-Rust type approaches, I maintain an actix-web starter project that does exactly this: https://github.com/secretkeysio/jelly-actix-web-starter

I maintain a starter for all of this kind of stuff on top of actix-web, for anyone interested: https://github.com/secretkeysio/jelly-actix-web-starter/

Curious why you went with the mailbox approach - since a request is pretty much in-and-out, I found it sufficient to just write a trait for HttpRequest and have a custom render(...) method that pulls any flash messages from the session, thus clearing them. Wouldn't surprise me if I'm missing something tho.

I love Askama, but being tied to compile time changes is an absurd handicap on a web framework in the initial iteration phase. With Tera, you can implement a watcher for template changes and reload them without needing to recompile the entire framework.

If you want, I have an open source actix-web repo that does stuff like this for you already.

If you enjoy Python's web story but want something similar-ish in Rust, you can check out my actix boilerplate repo - it "mimics" Django in many ways. If nothing else, might be useful for picking apart.