We’re talking about this pattern, right?
f, err := os.Open("filename.ext")
if err != nil {
log.Fatal(err)
}
Nothing stops you from leaving out the
if, right? 🤔
We’re talking about this pattern, right?
f, err := os.Open("filename.ext")
if err != nil {
log.Fatal(err)
}
Nothing stops you from leaving out the
We’re talking about this pattern, right?
f, err := os.Open("filename.ext")
if err != nil {
log.Fatal(err)
}
Nothing stops you from leaving out the
if, right? 🤔
!! was a sudo argument and never used it out of that context! Thanks for the $(!!) tip 🤘
https://racingbunny.com/@mookie/114718466149264471
> 18 rules of Software Engineering
>
> 0. You will regret complexity when on-call
> 1. Stop falling in love with your own code
> 2. Everything is a trade-off. There's no "best" 3. Every line of code you write is a liability 4. Document your decisions and designs
> 5. Everyone hates code they didn’t write
> 6. Don't use unnecessary dependencies
> 7. Coding standards prevent arguments
> 8. Write meaningful commit messages
> 9. Don't ever stop learning new things
> 10. Code reviews spread knowledge
> 11. Always build for maintainability
> 12. Ask for help when you’re stuck
> 13. Fix root causes, not symptoms
> 14. Software is never completed
> 15. Estimates are not promises
> 16. Ship early, iterate often
> 17. Keep. It. Simple.
Solid list, even though 14 is up for debate in my opinion: Software can be completed. You have a use case / problem, you solve that problem, done. Your software is completed now. There might still be bugs and they should be fixed – but this doesn’t “add” to the program. Don’t use “software is never done” as an excuse to keep adding and adding stuff to your code.
https://racingbunny.com/@mookie/114718466149264471
> 18 rules of Software Engineering
>
> 0. You will regret complexity when on-call
> 1. Stop falling in love with your own code
> 2. Everything is a trade-off. There's no "best" 3. Every line of code you write is a liability 4. Document your decisions and designs
> 5. Everyone hates code they didn’t write
> 6. Don't use unnecessary dependencies
> 7. Coding standards prevent arguments
> 8. Write meaningful commit messages
> 9. Don't ever stop learning new things
> 10. Code reviews spread knowledge
> 11. Always build for maintainability
> 12. Ask for help when you’re stuck
> 13. Fix root causes, not symptoms
> 14. Software is never completed
> 15. Estimates are not promises
> 16. Ship early, iterate often
> 17. Keep. It. Simple.
Solid list, even though 14 is up for debate in my opinion: Software can be completed. You have a use case / problem, you solve that problem, done. Your software is completed now. There might still be bugs and they should be fixed – but this doesn’t “add” to the program. Don’t use “software is never done” as an excuse to keep adding and adding stuff to your code.
Option and error handling. (Or the more complex Result, but it’s easier to explain with Option.)fn mydiv(num: f64, denom: f64) -> Option
// (Let’s ignore precision issues for a second.)
if denom 0.0 {
return None;
} else {
return Some(num / denom);
}
}
fn main() {
// Explicit, verbose version:
let num: f64 = 123.0;
let denom: f64 = 456.0;
let wrapped_res = mydiv(num, denom);
if wrapped_res.is_some() {
println!("Unwrapped result: {}", wrapped_res.unwrap());
}
// Shorter version using "if let":
if let Some(res) = mydiv(123.0, 456.0) {
println!("Here’s a result: {}", res);
}
if let Some(res) = mydiv(123.0, 0.0) {
println!("Huh, we divided by zero? This never happens. {}", res);
}
}
You can’t divide by zero, so the function returns an “error” in that case. (
Option isn’t really used for errors, IIUC, but the basic idea is the same for Result.)`Option` is an enum. It can have the value
Some or None. In the case of Some, *you can attach additional data* to the enum. In this case, we are attaching a floating point value.The caller then has to decide: Is the value
None or Some? Did the function succeed or not? If it is Some, the caller can do .unwrap() on this enum to get the inner value (the floating point value). If you do .unwrap() on a None value, the program will panic and die.The
if let version using destructuring is much shorter and, once you got used to it, actually quite nice.Now the trick is that you *must* somehow handle these two cases. You *must* either call something like
.unwrap() or do destructuring or something, otherwise you can’t access the attached value at all. As I understand it, it is impossible to just completely ignore error cases. And *the compiler enforces it*.(In case of
Result, the compiler would warn you if you ignore the return value entirely. So something like doing write() and then ignoring the return value would be caught as well.)=
Option and error handling. (Or the more complex Result, but it’s easier to explain with Option.)fn mydiv(num: f64, denom: f64) -> Option
// (Let’s ignore precision issues for a second.)
if denom 0.0 {
return None;
} else {
return Some(num / denom);
}
}
fn main() {
// Explicit, verbose version:
let num: f64 = 123.0;
let denom: f64 = 456.0;
let wrapped_res = mydiv(num, denom);
if wrapped_res.is_some() {
println!("Unwrapped result: {}", wrapped_res.unwrap());
}
// Shorter version using "if let":
if let Some(res) = mydiv(123.0, 456.0) {
println!("Here’s a result: {}", res);
}
if let Some(res) = mydiv(123.0, 0.0) {
println!("Huh, we divided by zero? This never happens. {}", res);
}
}
You can’t divide by zero, so the function returns an “error” in that case. (
Option isn’t really used for errors, IIUC, but the basic idea is the same for Result.)`Option` is an enum. It can have the value
Some or None. In the case of Some, *you can attach additional data* to the enum. In this case, we are attaching a floating point value.The caller then has to decide: Is the value
None or Some? Did the function succeed or not? If it is Some, the caller can do .unwrap() on this enum to get the inner value (the floating point value). If you do .unwrap() on a None value, the program will panic and die.The
if let version using destructuring is much shorter and, once you got used to it, actually quite nice.Now the trick is that you *must* somehow handle these two cases. You *must* either call something like
.unwrap() or do destructuring or something, otherwise you can’t access the attached value at all. As I understand it, it is impossible to just completely ignore error cases. And *the compiler enforces it*.(In case of
Result, the compiler would warn you if you ignore the return value entirely. So something like doing write() and then ignoring the return value would be caught as well.)=
https://www.uninformativ.de/desktop/2025%2D06%2D21%2D%2Dkatriawm%2Dold%2Dxorg%2Dapps.png
Good luck figuring out which of these UI elements are click-able – unless you examine every pixel on the screen.
https://www.uninformativ.de/desktop/2025%2D06%2D21%2D%2Dkatriawm%2Dold%2Dxorg%2Dapps.png
Good luck figuring out which of these UI elements are click-able – unless you examine every pixel on the screen.
Skimming through the manual: I had no idea that keeping the “up” cursor pressed actually slows you down at some point. 🤦
Skimming through the manual: I had no idea that keeping the “up” cursor pressed actually slows you down at some point. 🤦
Alt+. all the time, it’s great. 👌FWIW, another thing I often use is
!! to recall the entire previous command line:$ find -iname '*foo*'
./This is a foo file.txt
$ cat "$(!!)"
cat "$(find -iname '*foo*')"
This is just a test.
Yep!
Or:
$ ls -al subdir
ls: cannot open directory 'subdir': Permission denied
$ sudo !!
sudo ls -al subdir
total 0
drwx------ 2 root root 60 Jun 20 19:39 .
drwx------ 7 jess jess 360 Jun 20 19:39 ..
-rw-r--r-- 1 root root 0 Jun 20 19:39 nothing-to-see
Alt+. all the time, it’s great. 👌FWIW, another thing I often use is
!! to recall the entire previous command line:$ find -iname '*foo*'
./This is a foo file.txt
$ cat "$(!!)"
cat "$(find -iname '*foo*')"
This is just a test.
Yep!
Or:
$ ls -al subdir
ls: cannot open directory 'subdir': Permission denied
$ sudo !!
sudo ls -al subdir
total 0
drwx------ 2 root root 60 Jun 20 19:39 .
drwx------ 7 jess jess 360 Jun 20 19:39 ..
-rw-r--r-- 1 root root 0 Jun 20 19:39 nothing-to-see
$ ls > /dev/null
$ echo $_
--color=tty
Yeah, exactly what you think:
$ which ls
ls: aliased to ls --color=tty
Alt+. is going to be my favorite one! In the above, it would also give me /dev/null, which might be probably more what I would expect.
https://movq.de/v/7531158962/etr.mp4
https://movq.de/v/7531158962/etr.mp4
https://www.dn.pt/sociedade/miss%C3%A3o-escola-p%C3%BAblica-diz-n%C3%A3o-estarem-reunidas-condi%C3%A7%C3%B5es-de-equidade-para-provas-e-exames
https://www.dn.pt/sociedade/miss%C3%A3o-escola-p%C3%BAblica-diz-n%C3%A3o-estarem-reunidas-condi%C3%A7%C3%B5es-de-equidade-para-provas-e-exames
@lyse Yeah, YMMV. Some games work(ed) great in Wine, others not at all. I just use it because it’s easier than firing up my WinXP box. (I don’t use Wine for regular applications, just games.)
@lyse Yeah, YMMV. Some games work(ed) great in Wine, others not at all. I just use it because it’s easier than firing up my WinXP box. (I don’t use Wine for regular applications, just games.)
Find May's twts at the feed: https://tilde.pt/~marado/twtxt-2025M05.txt , or see them on the web: https://tilde.pt/~marado/twtxt-2025M05.html
Find May's twts at the feed: https://tilde.pt/~marado/twtxt-2025M05.txt , or see them on the web: https://tilde.pt/~marado/twtxt-2025M05.html
tt. Sure, I can easily edit my feed in vim to fix typos. But then I still have to manually remove the old message from the cache so that the new message is inserted on next reload and I don't end up with "duplicates" in the message tree.
pledge(…) and unveil(…) before, right? I somewhere ran across them once before. Never tried them out, but these syscalls seem to be really useful. They also have the potential to make one really rethink about software architecture. I should probably give this a try and see how I can improve my own programs.
- 16-bit support is gone.
- Performance of 3D games is horrible and unplayable.
Arch is shipping a WoW64 build now, which is not yet ready for prime time.
And *then* I realized that there’s actually only one stable Wine release per year but Arch has been shipping development releases all the time. That’s quite unusual. I’m used to Arch only shipping stable packages … huh.
Hopefully things will improve again. I’m not eager to build Wine from source. I’d rather ditch it and resort to my real Windows XP box for the little (retro)gaming that I do … 🫤
- 16-bit support is gone.
- Performance of 3D games is horrible and unplayable.
Arch is shipping a WoW64 build now, which is not yet ready for prime time.
And *then* I realized that there’s actually only one stable Wine release per year but Arch has been shipping development releases all the time. That’s quite unusual. I’m used to Arch only shipping stable packages … huh.
Hopefully things will improve again. I’m not eager to build Wine from source. I’d rather ditch it and resort to my real Windows XP box for the little (retro)gaming that I do … 🫤
GUESS WHAT WORKED
GUESS WHAT WORKED