Reddit Programming
212 subscribers
1.22K photos
125K links
I will send you newest post from subreddit /r/programming
Download Telegram
LLMs are a 400-year-long confidence trick
https://www.reddit.com/r/programming/comments/1qci8z5/llms_are_a_400yearlong_confidence_trick/

<!-- SC_OFF -->LLMs are an incredibly powerful tool, that do amazing things. But even so, they aren’t as fantastical as their creators would have you believe. I wrote this up because I was trying to get my head around why people are so happy to believe the answers LLMs produce, despite it being common knowledge that they hallucinate frequently. Why are we happy living with this cognitive dissonance? How do so many companies plan to rely on a tool that is, by design, not reliable? <!-- SC_ON --> submitted by /u/SwoopsFromAbove (https://www.reddit.com/user/SwoopsFromAbove)
[link] (https://tomrenner.com/posts/400-year-confidence-trick/) [comments] (https://www.reddit.com/r/programming/comments/1qci8z5/llms_are_a_400yearlong_confidence_trick/)
The Unbearable Frustration of Figuring Out APIs
https://www.reddit.com/r/programming/comments/1qcio2v/the_unbearable_frustration_of_figuring_out_apis/

<!-- SC_OFF -->or: Writing a Translation Command Line Tool in Swift. This is a small adventure in SwiftLand. <!-- SC_ON --> submitted by /u/M1M1R0N (https://www.reddit.com/user/M1M1R0N)
[link] (https://blog.ar-ms.me/thoughts/translation-cli/) [comments] (https://www.reddit.com/r/programming/comments/1qcio2v/the_unbearable_frustration_of_figuring_out_apis/)
Caching Playbook for System Design Interviews
https://www.reddit.com/r/programming/comments/1qcpk06/caching_playbook_for_system_design_interviews/

<!-- SC_OFF -->Here’s an article on caching, one of the most important component in any system design. This article covers the following : - What is cache ? - When should we cache ? - Caching Layers - Caching Strategies - Caching eviction policies - Cache production edge cases and how to handle them Also contains brief cheatsheets and nice diagrams check it out. <!-- SC_ON --> submitted by /u/Comfortable-Fan-580 (https://www.reddit.com/user/Comfortable-Fan-580)
[link] (https://pradyumnachippigiri.substack.com/p/caching-playbook-for-system-design) [comments] (https://www.reddit.com/r/programming/comments/1qcpk06/caching_playbook_for_system_design_interviews/)
<!-- SC_OFF -->I have been building parser for NASDAQ ITCH. That is the binary firehose behind real time order books. During busy markets it can hit millions of messages per second, so anything that allocates or copies per message just falls apart. This turned into a deep dive into zero copy parsing, SIMD, and how far you can push Rust before it pushes back. The problem allocating on every message ITCH is tight binary data. Two byte length, one byte type, fixed header, then payload. The obvious Rust approach looks like this: ```rust fn parse_naive(data: &[u8]) -> Vec { let mut out = Vec::new(); let mut pos = 0; while pos < data.len() { let len = u16::from_be_bytes([data[pos], data[pos + 1]]) as usize; let msg = data[pos..pos + len].to_vec(); out.push(Message::from_bytes(msg)); pos += len; } out } ``` This works and it is slow. You allocate a Vec for every message. At scale that means massive heap churn and awful cache behavior. At tens of millions of messages you are basically benchmarking malloc. Zero copy parsing and lifetime pain The fix is to stop owning bytes and just borrow them. Parse directly from the input buffer and never copy unless you really have to. In my case each parsed message just holds references into the original buffer. ```rust use zerocopy::Ref; pub struct ZeroCopyMessage<'a> { header: Ref<&'a [u8], MessageHeaderRaw>, payload: &'a [u8], } impl<'a> ZeroCopyMessage<'a> { pub fn read_u32(&self, offset: usize) -> u32 { let bytes = &self.payload[offset..offset + 4]; u32::from_be_bytes(bytes.try_into().unwrap()) } } ``` The zerocopy crate does the heavy lifting for headers. It checks size and alignment so you do not need raw pointer casts. Payloads are variable so those fields get read manually. The tradeoff is obvious. Lifetimes are strict. You cannot stash these messages somewhere or send them to another thread without copying. This works best when you process and drop immediately. In return you get zero allocations during parsing and way lower memory use. SIMD where it actually matters One hot path is finding message boundaries. Scalar code walks byte by byte and branches constantly. SIMD lets you get through chunks at once. Here is a simplified AVX2 example that scans 32 bytes at a time: ```rust use std::arch::x86_64::*; pub fn scan_boundaries_avx2(data: &[u8], pos: usize) -> Option { let chunk = unsafe { _mm256_loadu_si256(data.as_ptr().add(pos) as *const __m256i) }; let needle = _mm256_set1_epi8(b'A'); let cmp = _mm256_cmpeq_epi8(chunk, needle); let mask = _mm256_movemask_epi8(cmp); if mask != 0 { Some(pos + mask.trailing_zeros() as usize) } else { None } } ``` This checks 32 bytes in one go. On CPUs that support it you can do the same with AVX512 and double that. Feature detection at runtime picks the best version and falls back to scalar code on older machines. The upside is real. On modern hardware this was a clean two to four times faster in throughput tests. The downside is also real. SIMD code is annoying to write, harder to debug, and full of unsafe blocks. For small inputs the setup cost can outweigh the win. Safety versus speed Rust helps but it does not save you from tradeoffs. Zero copy means lifetimes everywhere. SIMD means unsafe. Some validation is skipped in release builds because checking everything costs time. Compared to other languages. Cpp can do zero copy with views but dangling pointers are always lurking. Go is great at concurrency but zero copy parsing fights the GC. Zig probably makes this cleaner but you still pay the complexity cost. This setup focused to pass 100 million messages per second. Code is here if you want the full thing https://github.com/lunyn-hft/lunary Curious how others deal with this. Have you fought Rust lifetimes this hard or written SIMD by hand for binary parsing? How would you do this in your language without losing your mind? <!-- SC_ON --> submitted by /u/capitanturkiye (https://www.reddit.com/user/capitanturkiye)
How do you build serious extension features within the constraints of VS Code’s public APIs?
https://www.reddit.com/r/programming/comments/1qcuy8d/how_do_you_build_serious_extension_features/

<!-- SC_OFF -->Most tools don’t even try. They fork the editor or build a custom IDE so they can skip the hard interaction problems. I'm working on an open-source coding agent and was faced with the dilemma of how to render code suggestions inside VS Code. Our NES is a VS Code–native feature. That meant living inside strict performance budgets and interaction patterns that were never designed for LLMs proposing multi-line, structural edits in real time. In this case, surfacing enough context for an AI suggestion to be actionable, without stealing attention, is much harder. That pushed us toward a dynamic rendering strategy instead of a single AI suggestion UI. Each path gets deliberately scoped to the situations where it performs best, aligning it with the least disruptive representation for a given edit. If AI is going to live inside real editors, I think this is the layer that actually matters. Full write-up in in the blog <!-- SC_ON --> submitted by /u/National_Purpose5521 (https://www.reddit.com/user/National_Purpose5521)
[link] (https://docs.getpochi.com/developer-updates/dynamic-rendering-stratergies-for-ai-edits/) [comments] (https://www.reddit.com/r/programming/comments/1qcuy8d/how_do_you_build_serious_extension_features/)
Responsible disclosure of a Claude Cowork vulnerability that lets hidden prompt injections exfiltrate local files by uploading them to an attacker’s Anthropic account
https://www.reddit.com/r/programming/comments/1qdg7i4/responsible_disclosure_of_a_claude_cowork/

<!-- SC_OFF -->From the article: Two days ago, Anthropic released the Claude Cowork research preview (a general-purpose AI agent to help anyone with their day-to-day work). In this article, we demonstrate how attackers can exfiltrate user files from Cowork by exploiting an unremediated vulnerability in Claude’s coding environment, which now extends to Cowork. The vulnerability was first identified in Claude.ai chat before Cowork existed by Johann Rehberger, who disclosed the vulnerability — it was acknowledged but not remediated by Anthropic. <!-- SC_ON --> submitted by /u/sean-adapt (https://www.reddit.com/user/sean-adapt)
[link] (https://www.promptarmor.com/resources/claude-cowork-exfiltrates-files) [comments] (https://www.reddit.com/r/programming/comments/1qdg7i4/responsible_disclosure_of_a_claude_cowork/)
Programmer in Wonderland
https://www.reddit.com/r/programming/comments/1qdglkv/programmer_in_wonderland/

<!-- SC_OFF -->Hey Devs, Do not become The Lost Programmer in the bottomless ocean of software abstractions, especially with the recent advent of AI-driven hype; instead, focus on the fundamentals, make the magic go away and become A Great One! <!-- SC_ON --> submitted by /u/BinaryIgor (https://www.reddit.com/user/BinaryIgor)
[link] (https://binaryigor.com/programmer-in-wonderland.html) [comments] (https://www.reddit.com/r/programming/comments/1qdglkv/programmer_in_wonderland/)