I was thinking Java for gluttony and Python for sloth. Also maybe PHP for greed (bc of $vars) and Js could be envy since it has basically nothing to do with java and they chose it to sound cool
this is a very fun idea 🤓
this is a very fun idea 🤓
August 6, 2025 at 11:43 AM
I was thinking Java for gluttony and Python for sloth. Also maybe PHP for greed (bc of $vars) and Js could be envy since it has basically nothing to do with java and they chose it to sound cool
this is a very fun idea 🤓
this is a very fun idea 🤓
Asahi linux is a thing! asahilinux.org
Works very very well, the only reason I don't daily drive it is because suspend power is not as good as macOS yet
Works very very well, the only reason I don't daily drive it is because suspend power is not as good as macOS yet
Asahi Linux
Porting Linux to Apple Silicon
asahilinux.org
July 15, 2025 at 7:57 PM
Asahi linux is a thing! asahilinux.org
Works very very well, the only reason I don't daily drive it is because suspend power is not as good as macOS yet
Works very very well, the only reason I don't daily drive it is because suspend power is not as good as macOS yet
It looks like sending it to the micro task queue (or whatever setTimeout sends it too, I don't exactly remember) solves it, so I guess there's some problem in doing the update on the main loop? Some sort of race condition? That's what jumps to mind at least, but who knows 🤷♂️
July 15, 2025 at 7:24 AM
It looks like sending it to the micro task queue (or whatever setTimeout sends it too, I don't exactly remember) solves it, so I guess there's some problem in doing the update on the main loop? Some sort of race condition? That's what jumps to mind at least, but who knows 🤷♂️
Vouch for typst and fletchter! I've used it and the results are nice and the code can be pretty consise
July 7, 2025 at 1:40 PM
Vouch for typst and fletchter! I've used it and the results are nice and the code can be pretty consise
I have never done this and I have no idea what I'm talking about, but can't you just allocate, put the bytes you want in your allocation and transmute? I feel you could even make a constructor function that has a safe API and everything
June 21, 2025 at 11:05 AM
I have never done this and I have no idea what I'm talking about, but can't you just allocate, put the bytes you want in your allocation and transmute? I feel you could even make a constructor function that has a safe API and everything
I feel that if you're not confident enough to use unsafe (which you probably shouldn't be indeed!) then having an error message just in case is worth it. It's just a few bytes after all 🤷
June 15, 2025 at 6:38 PM
I feel that if you're not confident enough to use unsafe (which you probably shouldn't be indeed!) then having an error message just in case is worth it. It's just a few bytes after all 🤷
Oh wow I was totally thinking of `let else` 😅
(but in my defense, let else is a more direct substitute to unwrap that if else)
(but in my defense, let else is a more direct substitute to unwrap that if else)
June 15, 2025 at 6:32 PM
Oh wow I was totally thinking of `let else` 😅
(but in my defense, let else is a more direct substitute to unwrap that if else)
(but in my defense, let else is a more direct substitute to unwrap that if else)
By "cascading messages" you mean propagation Option up the call stack?
I would say that having a possibility of your program crashing when calling a function is a worse violation of LoD, no? Saying "this function might not have something to return" doesn't break isolation, I think
I would say that having a possibility of your program crashing when calling a function is a worse violation of LoD, no? Saying "this function might not have something to return" doesn't break isolation, I think
June 15, 2025 at 2:50 PM
By "cascading messages" you mean propagation Option up the call stack?
I would say that having a possibility of your program crashing when calling a function is a worse violation of LoD, no? Saying "this function might not have something to return" doesn't break isolation, I think
I would say that having a possibility of your program crashing when calling a function is a worse violation of LoD, no? Saying "this function might not have something to return" doesn't break isolation, I think
I guess one might use unwrap for cases where it's very obvious why a panic won't occur but eh I'd rather write a reason quickly with expect. If I was really confident and didn't care about me being mistaken, maybe I'd even write an unwrap_unchecked.
imo unwrap is exclusively valid for prototyping 🤷
imo unwrap is exclusively valid for prototyping 🤷
June 15, 2025 at 1:41 PM
I guess one might use unwrap for cases where it's very obvious why a panic won't occur but eh I'd rather write a reason quickly with expect. If I was really confident and didn't care about me being mistaken, maybe I'd even write an unwrap_unchecked.
imo unwrap is exclusively valid for prototyping 🤷
imo unwrap is exclusively valid for prototyping 🤷
Hmm, idk, I like expect to describe the reason I expect something not to be None because if that case is hit you get an informative error message of what invariabt has been broken. If you used unwrap for when you "know" it won't panic you don't have a place to record this information.
June 15, 2025 at 1:41 PM
Hmm, idk, I like expect to describe the reason I expect something not to be None because if that case is hit you get an informative error message of what invariabt has been broken. If you used unwrap for when you "know" it won't panic you don't have a place to record this information.
I've found that oftentimes when there is friction and resistance in Rust it's because something could have been arquitected better. I've also had to learn to ignore that sometimes.
In this case, I think it's best to just let the formatter do its thing 🤷. Fighting it is a bit Sisyphean imo
In this case, I think it's best to just let the formatter do its thing 🤷. Fighting it is a bit Sisyphean imo
June 15, 2025 at 1:33 PM
I've found that oftentimes when there is friction and resistance in Rust it's because something could have been arquitected better. I've also had to learn to ignore that sometimes.
In this case, I think it's best to just let the formatter do its thing 🤷. Fighting it is a bit Sisyphean imo
In this case, I think it's best to just let the formatter do its thing 🤷. Fighting it is a bit Sisyphean imo
...and for the second example, if you want to keep those three field acesses in one line maybe you can declare a variable. Or in your case maybe it can be a method! I think it can make sense.
June 15, 2025 at 1:33 PM
...and for the second example, if you want to keep those three field acesses in one line maybe you can declare a variable. Or in your case maybe it can be a method! I think it can make sense.
But also weird rust formatting might be a bit of a code smell. Most likely it doesn't matter, but in your first example, the clone might be unnecessary and the unwrap should probably be removed and should return an Option instead...
June 15, 2025 at 1:33 PM
But also weird rust formatting might be a bit of a code smell. Most likely it doesn't matter, but in your first example, the clone might be unnecessary and the unwrap should probably be removed and should return an Option instead...
The problem with that it's that the things in one line might look like they're grouped together when semantically they might not need to be. With the current design, either everything is one line, or every dot is in a different line. It is easy to predict and kinda helps collaboration
June 15, 2025 at 1:33 PM
The problem with that it's that the things in one line might look like they're grouped together when semantically they might not need to be. With the current design, either everything is one line, or every dot is in a different line. It is easy to predict and kinda helps collaboration
But, of course, if it's a program you run once for yourself, its totally fine to use unwrap 🤷
buuut actually returning something like anyhow::Result might make the code cleaner!you only need to do ? instead of .unwrap(), and you get all the benefits above ^^
buuut actually returning something like anyhow::Result might make the code cleaner!you only need to do ? instead of .unwrap(), and you get all the benefits above ^^
June 15, 2025 at 1:04 PM
But, of course, if it's a program you run once for yourself, its totally fine to use unwrap 🤷
buuut actually returning something like anyhow::Result might make the code cleaner!you only need to do ? instead of .unwrap(), and you get all the benefits above ^^
buuut actually returning something like anyhow::Result might make the code cleaner!you only need to do ? instead of .unwrap(), and you get all the benefits above ^^
For instance, returning an error that bubbles up, says what went wrong exactly with a nice message (e.g.., "you've entered silly input") and is recoverable in case the program becomes bigger and you don't want the user to restart the program to try to write input again.
June 15, 2025 at 1:04 PM
For instance, returning an error that bubbles up, says what went wrong exactly with a nice message (e.g.., "you've entered silly input") and is recoverable in case the program becomes bigger and you don't want the user to restart the program to try to write input again.
For those cases you have `expect`, where you give the reason why you expect not a None. And you could also do a match and an unreachable (or unreachable_unchecked!). Or even better, encode it in the typesystem.
unwrap is generally used for the "I can't be bothered to handle this rn" case
unwrap is generally used for the "I can't be bothered to handle this rn" case
June 15, 2025 at 12:57 PM
For those cases you have `expect`, where you give the reason why you expect not a None. And you could also do a match and an unreachable (or unreachable_unchecked!). Or even better, encode it in the typesystem.
unwrap is generally used for the "I can't be bothered to handle this rn" case
unwrap is generally used for the "I can't be bothered to handle this rn" case
`if let` is relatively new tho. But yeah generally way better than unwrap!
June 15, 2025 at 12:52 PM
`if let` is relatively new tho. But yeah generally way better than unwrap!
In case you hadnt heard of it, lib.rs is a very nice alternative to crates.io that generally does a nicer job at finding and evaluating a crates and alternatives ^^
Lib.rs — home for Rust crates
List of Rust libraries and applications. An unofficial experimental opinionated alternative to crates.io
lib.rs
May 18, 2025 at 6:48 PM
i like naersk 🤠
but also buildRustPackage is very much usable
crane is just… too much for me
but also buildRustPackage is very much usable
crane is just… too much for me
May 16, 2025 at 9:05 PM
i like naersk 🤠
but also buildRustPackage is very much usable
crane is just… too much for me
but also buildRustPackage is very much usable
crane is just… too much for me
But the real problem is when you try to package stuff. I spent way too long trying to get a relatively simple pnpm app working and, really, the best option to this day in my opinion is to search all github for similar stuff which isn't intuitive and just isn't a nice experience... (still <3 nix tho)
May 14, 2025 at 4:07 PM
But the real problem is when you try to package stuff. I spent way too long trying to get a relatively simple pnpm app working and, really, the best option to this day in my opinion is to search all github for similar stuff which isn't intuitive and just isn't a nice experience... (still <3 nix tho)