Conrad Ludgate
@conrad.cafe
This lint is also allow-by-default.
November 19, 2025 at 4:57 PM
This lint is also allow-by-default.
What difference would it make for this to be in rustc?
November 19, 2025 at 3:30 PM
What difference would it make for this to be in rustc?
November 19, 2025 at 1:51 PM
I've disabled unwrap in my codebase at work, only expect() is allowed. For Mutex/JoinHandle I've added some ext helpers
github.com/neondatabase...
github.com/neondatabase...
github.com
November 19, 2025 at 1:50 PM
I've disabled unwrap in my codebase at work, only expect() is allowed. For Mutex/JoinHandle I've added some ext helpers
github.com/neondatabase...
github.com/neondatabase...
`#![feature(core_intrinsics)]`
November 17, 2025 at 4:32 PM
`#![feature(core_intrinsics)]`
I was inspired to write this because I remember people complaining that lightweight crypto doesn't make sense. Arguments like "crypto is either secure or it isn't" missed the point entirely
November 17, 2025 at 9:35 AM
I was inspired to write this because I remember people complaining that lightweight crypto doesn't make sense. Arguments like "crypto is either secure or it isn't" missed the point entirely
This is useful for embedded devices with less available memory.
Ascon, not needing addition like chacha20, is also easy to implement in hardware. It only needs bitshifts and xor. While this isn't important for off-the-shelf CPUs, this matters for an FPGA that wants to run encryption or hashing.
Ascon, not needing addition like chacha20, is also easy to implement in hardware. It only needs bitshifts and xor. While this isn't important for off-the-shelf CPUs, this matters for an FPGA that wants to run encryption or hashing.
November 17, 2025 at 9:35 AM
This is useful for embedded devices with less available memory.
Ascon, not needing addition like chacha20, is also easy to implement in hardware. It only needs bitshifts and xor. While this isn't important for off-the-shelf CPUs, this matters for an FPGA that wants to run encryption or hashing.
Ascon, not needing addition like chacha20, is also easy to implement in hardware. It only needs bitshifts and xor. While this isn't important for off-the-shelf CPUs, this matters for an FPGA that wants to run encryption or hashing.
The only limitation at the moment is in rustc/llvm/linker. Unfortunately the only workaround I've found forces us to marginally bloat the binary size. It has no runtime impact but it's still annoying. My attempt to modify rustc caused crazy link errors so I gave up 😅
November 14, 2025 at 1:18 PM
The only limitation at the moment is in rustc/llvm/linker. Unfortunately the only workaround I've found forces us to marginally bloat the binary size. It has no runtime impact but it's still annoying. My attempt to modify rustc caused crazy link errors so I gave up 😅
I'm hoping one day that I can re-implement parts of tokio-console in eBPF with aya-rs so you can monitor your application without having to recompile it or without needing some extra runtime cost otherwise.
November 14, 2025 at 1:18 PM
I'm hoping one day that I can re-implement parts of tokio-console in eBPF with aya-rs so you can monitor your application without having to recompile it or without needing some extra runtime cost otherwise.
Something I have in my $work code
```
const HEADER_FOO: HeaderName = HeaderName::from_static("x-foo");
```
This contains a Bytes internally, which contains an AtomicUsize. This usize is never read/written to but it still marks it as interior mutable.
```
const HEADER_FOO: HeaderName = HeaderName::from_static("x-foo");
```
This contains a Bytes internally, which contains an AtomicUsize. This usize is never read/written to but it still marks it as interior mutable.
November 11, 2025 at 2:13 PM
Something I have in my $work code
```
const HEADER_FOO: HeaderName = HeaderName::from_static("x-foo");
```
This contains a Bytes internally, which contains an AtomicUsize. This usize is never read/written to but it still marks it as interior mutable.
```
const HEADER_FOO: HeaderName = HeaderName::from_static("x-foo");
```
This contains a Bytes internally, which contains an AtomicUsize. This usize is never read/written to but it still marks it as interior mutable.
ufotofu also is very explicit about not being cancel safe it seems.
I've had enough problems where code was documented as not cancel safe, but calling code still ended up with hidden cancellations.
From this point on I try not to write any cancel-unsafe functions. It's just impossible to satisfy
I've had enough problems where code was documented as not cancel safe, but calling code still ended up with hidden cancellations.
From this point on I try not to write any cancel-unsafe functions. It's just impossible to satisfy
November 10, 2025 at 6:02 PM
ufotofu also is very explicit about not being cancel safe it seems.
I've had enough problems where code was documented as not cancel safe, but calling code still ended up with hidden cancellations.
From this point on I try not to write any cancel-unsafe functions. It's just impossible to satisfy
I've had enough problems where code was documented as not cancel safe, but calling code still ended up with hidden cancellations.
From this point on I try not to write any cancel-unsafe functions. It's just impossible to satisfy
LocalSet is also being deprecated in favour of LocalRuntime.
November 9, 2025 at 10:54 AM
LocalSet is also being deprecated in favour of LocalRuntime.
Then you need to establish a consortium to justify that your change still indeed sparks joy
November 3, 2025 at 12:20 PM
Then you need to establish a consortium to justify that your change still indeed sparks joy
Once upon a time, someone implemented Default on `[T; 0]`. Now it's a conflicting impl to implement Default on `[T; N]`. Whoops
November 3, 2025 at 12:17 PM
Once upon a time, someone implemented Default on `[T; 0]`. Now it's a conflicting impl to implement Default on `[T; N]`. Whoops
Was this particular behaviour documented:
* yes - major
* no - minor
* yes, but the implementation was wrong - patch
If you're going to bother using minor versions, then you might also want a backporting procedure so that people who were subject to hyrums law still can have some level of support
* yes - major
* no - minor
* yes, but the implementation was wrong - patch
If you're going to bother using minor versions, then you might also want a backporting procedure so that people who were subject to hyrums law still can have some level of support
November 3, 2025 at 12:16 PM
Was this particular behaviour documented:
* yes - major
* no - minor
* yes, but the implementation was wrong - patch
If you're going to bother using minor versions, then you might also want a backporting procedure so that people who were subject to hyrums law still can have some level of support
* yes - major
* no - minor
* yes, but the implementation was wrong - patch
If you're going to bother using minor versions, then you might also want a backporting procedure so that people who were subject to hyrums law still can have some level of support
If this behaviour wasn't documented or couldn't be derived from the documentation then it's not a strict breaking change. But it could still be subject to hyrums law.
November 3, 2025 at 12:12 PM
If this behaviour wasn't documented or couldn't be derived from the documentation then it's not a strict breaking change. But it could still be subject to hyrums law.
Whether something is a breaking change depends on what's guaranteed.
The signature is one guarantee. Usually if it compiles today it should compile tomorrow. However the documented behaviour is another guarantee.
The signature is one guarantee. Usually if it compiles today it should compile tomorrow. However the documented behaviour is another guarantee.
November 3, 2025 at 12:12 PM
Whether something is a breaking change depends on what's guaranteed.
The signature is one guarantee. Usually if it compiles today it should compile tomorrow. However the documented behaviour is another guarantee.
The signature is one guarantee. Usually if it compiles today it should compile tomorrow. However the documented behaviour is another guarantee.
Send them a link to rosenpass and invoice them for a full month of development time
October 14, 2025 at 6:01 PM
Send them a link to rosenpass and invoice them for a full month of development time
Technologies: 🐭
Experience: 🐀
Education: 🐁
Experience: 🐀
Education: 🐁
October 10, 2025 at 5:46 PM
Technologies: 🐭
Experience: 🐀
Education: 🐁
Experience: 🐀
Education: 🐁