10 minutes based on my experience.
jameseb
To give a theological answer, no. A lich is usually understood as a sorcerer who has achieved an undead state or immortality, usually by binding their soul to the corporeal world in a phylactery. That does not apply in Jesus' case, since he did not pursue any sort of magic to avoid death, much less binding his soul to a phylactery. The resurrection of Jesus was a supernatural act of God, restoring Jesus to true life.
As to the second part of your question, I was not aware that holy water harming liches was a common trope in fiction (it is usually seen in reference to vampires), but even if it is applied to undead more widely, we have established that Jesus was restored to true life, not to any form of unnatural undeath. Moreover, holiness comes from God (that which is holy is set apart for God), and Jesus is fully God, so contact with holy things would not harm him. Indeed, Christ is now in the true holy place in heaven (Hebrews 9:24), which we can only enter when cleansed by his blood (Hebrews 10:19-22).
I'm glad my points we're helpful!
There is some documentation on examples in the Cargo book. The basic procedure is to put it in an examples
directory alongside the src
directory (and in its own subfolder if it has multiple files), and you can add an entry for it in the Cargo.toml
(although it should automatically detect it if you put it in the examples
directory, so that is only strictly necessary if you want to change the default settings).
A few things I noticed:
- In
http::request::parse()
, do you actually need aBufReader
? It would be better to make it generic over something implementingBufRead
, that allows what you have but also makes tests and examples easier since you wouldn't have to open a TCP connection just to do something that is essentially string parsing. - In
http::response::Response::to_string()
, that match on lines 78-85 makes me uneasy, because you are silently changing the status code if it isn't one you recognise. It would be better to signal an error. It would be even better to just check when the status code is set (perhaps with a status code enum to list the ones you support, since what you have isn't all the defined codes) so that you can't fail when converting to a string. - Consider whether you need a special
to_string()
method at all, or whether you can just implementDisplay
(which gives youto_string()
for free via theToString
trait). - You are using
String
as an error type pretty much everywhere. The better approach is to create an enum representing all the possible errors, so that a user of your library can match against them. Make the enum implementError
andDisplay
and it will fit fine into the rest of the error handling infrastructure. There are crates likethiserror
that can reduce the boilerplate around this. - You have an
io.rs
that doesn't appear to be connected to anything. - You have a
main.rs
, which seems off in something that sounds like it should be purely a library crate. You probably want that to be an example or an integration test instead.
That's all I could see with a quick look. In terms of general advice: remember to look at warnings, run cargo clippy
, and look at the API guidelines.
I can understand why people wouldn't specifically talk about the fediverse on other sites. It just seems like there is a lot of coverage of X and Meta in the news, but there doesn't seem to have been even a passing mention of fediverse sites in most of what I've seen. I guess the more established social media sites are still a lot more significant than fediverse alternatives though.
What's sad is that people aren't talking about Mastodon nearly as much as they are talking about Threads and X. It just doesn't seem to get much publicity outside of the fediverse.
Image uploads are currently disabled on lemm.ee: https://lemm.ee/post/5839513. Images were restricted in size before that as well to avoid using too much server space. The idea is to use image hosting sites instead.
The Rust book is the official standard resource for learning Rust. It assumes some experience in another programming language, but it doesn't matter which one (that is, it isn't aimed at teaching Rust as a first programming language), so there's no reason why you couldn't read it with some experience in C.
Depending on what sort of C programmer you are, you may find Learn Rust the Dangerous Way of interest as well.
I think the point being made is that the layout shown only applies for
Sized
T
. Layouts for&[T]
and&dyn Trait
are shown elsewhere on the sheet.&str
is noted under&[T]
.Edit: although, similar considerations would apply to other pointer types, but that isn't noted on the sheet except for
Box<[T]>