Conrad Ludgate
Probably writing Rust
github.com/conradludgate
https://conradludgate.com
- Reposted by Conrad LudgateThis amazing group is excited to review your #rustconf26 talk submission! Apply to speak now through February 16: bit.ly/49EA31Y
- Reposted by Conrad LudgateThe #rustconf '26 Program Committee represents the breadth of the #rustlang ecosystem — from bioinformatics to safety-critical systems, from the UK to Argentina to Nigeria & beyond 🌍 Meet the group of community members that will be reviewing talk submissions: rustfoundation.org/media/announ...
- Working on an absolutely cracked project idea involving zero-trust federation, MLS, paxos, @iroh.computer and CRDTs 👀 I hope this works out because the idea is really really cool
- Quick brain dump github.com/conradludgat...
- I'm pretty against using AI in my own software but this latest wave of discourse is very 🍿
- Calling any LLM assisted development tainted slopware is definitely a take. I have played around with LLMs in software to help with accessibility (incase I have to stop using a keyboard). It was interesting but I didn't enjoy it, but not because it produced slop. Slop is purely what you make of it
- Don't get me wrong. Plenty of LLM produced code is slop. And I hate the companies behind the current wave. I'm definitely staying away from depending on them until we get more access to local hosted models. The incestuous nature of current training is also unlikely to end well.
- There definitely needs to be an overhaul of the technology and the society, but it's definitely not gonna go away because you make a list of shame. Social media lowered the bar for misinformation on the internet. LLMs lowered the bar for slop on the internet. But neither inherently cause them
- I'm so ready to set up my own git forge when I move. I'm very much looking forward to ditching github and owning my own code backups. Current plan is to set up a tangled.sh knot, hosted in my home (with backups in s3). I want to keep the social aspect of github, I hope tangled does this well
- I respect github charging for github actions self-hosted runners because their orchestrater isn't free. However, github actions sucks ass and it's not a compelling product. Not sure what I plan to replace it with. I've been somewhat bullish on CI=build system. Definitely not using nix though.
- CI=build system is great because it means you can always run CI locally. And you can often use remote build/cache servers natively. At work we use bazel. It's ok. Maybe I'll invest some time into learning it. Alternatively buck2. But definitely not nix.
- Reposted by Conrad LudgateNew post: a defense of lock poisoning in Rust. Followup to recent discussion: decided to write about lock poisoning, looking at the arguments on each side, and informed by our experience at @oxide.computer dealing with the parallel problem of unexpected async cancellations Please give it a read!
- Twitter is the new LinkedIn
- Reposted by Conrad LudgateIncredibly disappointed (shocked even) that the plan is to make the default Rust mutex not poisonable in the 2027 edition. Poisoning is one of the best examples of Rust focusing on rigor, and removing it from the default mutex would be a massive step backwards.
- In case you didn't know. Lightweight crypto(graphy) doesn't mean weak crypto. Lightweight constructions like ascon-aead are not designed to be faster than chacha20. I think in practice they're usually slower. They're actually intended to encrypt smaller block sizes with less working memory
- 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.
- 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
- github.com/tokio-rs/tok... 👀 Userspace Statically Defined Tracepoints is a cool concept. With root access, you can attach dtrace or bpftrace to your program and see what your program is up to at those tracepoints. Any other time, those tracepoints are literal NOP instructions.
- 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.
- 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 😅
