Reddit Programming
212 subscribers
1.22K photos
125K links
I will send you newest post from subreddit /r/programming
Download Telegram
Walkthrough of X's algorithm that decides what you see
https://www.reddit.com/r/programming/comments/1qpharr/walkthrough_of_xs_algorithm_that_decides_what_you/

<!-- SC_OFF -->X open-sourced the algorithm behind the For You feed on January 20th (https://github.com/xai-org/x-algorithm). Candidate Retrieval Two sources feed the pipeline: Thunder: an in-memory service holding the last 48 hours of tweets in a DashMap (concurrent HashMap), indexed by author. It serves in-network posts from accounts you follow via gRPC. Phoenix: a two-tower neural network for discovery. User tower is a Grok transformer with mean pooling. Candidate tower is a 2-layer MLP with SiLU. Both L2-normalize, so retrieval is just a dot product over precomputed corpus embeddings. Scoring Phoenix scores all candidates in a single transformer forward pass, predicting 18 engagement probabilities per post - like, reply, retweet, share, block, mute, report, dwell, video completion, etc. To batch efficiently without candidates influencing each other's scores, they use a custom attention mask. Each candidate attends to the user context and itself, but cross-candidate attention is zeroed out. A WeightedScorer combines the 18 predictions into one number. Positive signals (likes, replies, shares) add to the score. Negative signals (blocks, mutes, reports) subtract. Then two adjustments: Author diversity - exponential decay so one author can't dominate your feed. A floor parameter (e.g. 0.3) ensures later posts still have some weight. Out-of-network penalty 0 posts from unfollowed accounts are multiplied by a weight (e.g. 0.7). Filtering 10 pre-filters run before scoring (dedup, age limit, muted keywords, block lists, previously seen posts via Bloom filter). After scoring, a visibility filter queries an external safety service and a conversation dedup filter keeps only the highest-scored post per thread. <!-- SC_ON --> submitted by /u/noninertialframe96 (https://www.reddit.com/user/noninertialframe96)
[link] (https://codepointer.substack.com/p/x-algorithm-how-x-decides-what-550) [comments] (https://www.reddit.com/r/programming/comments/1qpharr/walkthrough_of_xs_algorithm_that_decides_what_you/)
Locale-sensitive text handling (minimal reproducible example)
https://www.reddit.com/r/programming/comments/1qpjaj5/localesensitive_text_handling_minimal/

<!-- SC_OFF -->Text handling must not depend on the system locale unless explicitly intended. Some APIs silently change behavior based on system language. This causes unintended results. Minimal reproducible example under Turkish locale: "FILE".ToLower() == "fıle" Reverse casing example: "file".ToUpper() == "FİLE" This artifact exists to help developers detect locale-sensitive failures early. Use as reference or for testing. (You may download the .txt version of this post from the given link) <!-- SC_ON --> submitted by /u/BoloFan05 (https://www.reddit.com/user/BoloFan05)
[link] (https://drive.google.com/file/d/1Rgyxfzmw-rfchVi2oShJHHQ8YpMUqlgT/view?usp=sharing) [comments] (https://www.reddit.com/r/programming/comments/1qpjaj5/localesensitive_text_handling_minimal/)
We analyzed 6 real-world frameworks across 6 languages — here’s what coupling, cycles, and dependency structure look like at scale
https://www.reddit.com/r/programming/comments/1qpkt35/we_analyzed_6_realworld_frameworks_across_6/

<!-- SC_OFF -->We recently ran a structural dependency analysis on six production open-source frameworks, each written in a different language: Tokio (Rust) Fastify (JavaScript) Flask (Python) Prometheus (Go) Gson (Java) Supermemory (TypeScript) The goal was to look at structural characteristics using actual dependency data, rather than intuition or anecdote. Specifically, we measured: Dependency coupling Circular dependency patterns File count and SLOC Class and function density All results are from directly from the current GitHub main repository commits as of this week. The data at a glance Framework Language Files SLOC Classes Functions Coupling Cycles Tokio Rust 763 92k 759 2,490 1.3 0 Fastify JavaScript 277 70k 5 254 1.2 3 Flask Python 83 10k 69 520 2.1 1 Prometheus Go 400 73k 1,365 6,522 3.3 0 Gson Java 261 36k 743 2,820 3.8 10 Supermemory TypeScript 453 77k 49 917 4.3 0 Notes “Classes” in Go reflect structs/types; in Rust they reflect impl/type-level constructs. Coupling is measured as average dependency fan-out per parsed file. Full raw outputs are published for independent inspection (link below). Key takeaways from this set: 1. Size does not equal structural complexity Tokio (Rust) was the largest codebase analyzed (~92k SLOC across 763 files), yet it maintained: Very low coupling (1.3) Clear and consistent dependency direction This challenges the assumption that large systems inevitably degrade into tightly coupled “balls of mud.” 2. Cycles tend to cluster, rather than spread Where circular dependencies appeared, they were highly localized, typically involving a small group of closely related files rather than spanning large portions of the graph. Examples: Flask (Python) showed a single detected cycle confined to a narrow integration boundary. Gson (Java) exhibited multiple cycles, but these clustered around generic adapters and shared utility layers. No project showed evidence of cycles propagating broadly across architectural layers. This suggests that in well-structured systems, cycles — when they exist — tend to be contained, limiting their blast radius and cognitive overhead, even if edge-case cycles exist outside static analysis coverage. 3. Language-specific structural patterns emerge Some consistent trends showed up: Java (Gson)
Higher coupling and more cycles, driven largely by generic type adapters and deeper inheritance hierarchies
(743 classes and 2,820 functions across 261 files). Go (Prometheus)
Clean dependency directionality overall, with complexity concentrated in core orchestration and service layers.
High function density without widespread structural entanglement. TypeScript (Supermemory)
Higher coupling reflects coordination overhead in a large SDK-style architecture — notably without broad cycle propagation. 4. Class and function density explain where complexity lives Scale metrics describe how much code exists, but class and function density reveal how responsibility and coordination are structured. For example: Gson’s higher coupling aligns with its class density and reliance on generic coordination layers. Tokio’s low coupling holds despite its size, aligning with Rust’s crate-centric approach to enforcing explicit module boundaries. Smaller repositories can still accumulate disproportionate structural complexity when dependency direction isn’t actively constrained. Why we did this When onboarding to a large, unfamiliar repository or planning a refactor, lines of code alone are a noisy signal, and mental models, tribal knowledge, and architectural documentation often lag behind reality. Structural indicators like: Dependency fan-in / fan-out Coupling density Cycle concentration tend to correlate more directly with the effort
required to reason about, change, and safely extend a system. We’ve published the complete raw analysis outputs in the provided link: The outputs are static JSON artifacts (dependency graphs, metrics, and summaries) served directly by the public frontend. If this kind of structural information would be useful for a specific open-source repository, feel free to share a GitHub link. I’m happy to run the same analysis and provide the resulting static JSON (both readable and compressed) as a commit to the repo, if that is acceptable. Would love to hear how others approach this type of assessment in practice or what you might think of the analysis outputs. <!-- SC_ON --> submitted by /u/BaseDue9532 (https://www.reddit.com/user/BaseDue9532)
[link] (https://pvizgenerator.com/test-cases) [comments] (https://www.reddit.com/r/programming/comments/1qpkt35/we_analyzed_6_realworld_frameworks_across_6/)
AT&T Had iTunes in 1998. Here's Why They Killed It. (Companion to "The Other Father of MP3"
https://www.reddit.com/r/programming/comments/1qpsw4m/att_had_itunes_in_1998_heres_why_they_killed_it/

<!-- SC_OFF -->Recently I posted "The Other Father of MP3" about James Johnston, the Bell Labs engineer whose contributions to perceptual audio coding were written out of history. Several commenters asked what happened on the business side; how AT&T managed to have the technology that became iTunes and still lose. This is that story. Howie Singer and Larry Miller built a2b Music inside AT&T using Johnston's AAC codec. They had label deals, a working download service, and a portable player three years before the iPod. They tried to spin it out. AT&T killed the spin-out in May 1999. Two weeks later, Napster launched. Based on interviews with Singer (now teaching at NYU, formerly Chief of Strategic Technology at Warner Music for 10 years) and Miller (inaugural director of the Sony Audio Institute at NYU). The tech was ready. The market wasn't. And the permission culture of a century-old telephone monopoly couldn't move at internet speed. <!-- SC_ON --> submitted by /u/Traditional_Rise_609 (https://www.reddit.com/user/Traditional_Rise_609)
[link] (https://roguesgalleryprog.substack.com/p/the-a2b-spin-out-that-never-happened) [comments] (https://www.reddit.com/r/programming/comments/1qpsw4m/att_had_itunes_in_1998_heres_why_they_killed_it/)
40ns causal consistency by replacing consensus with algebra
https://www.reddit.com/r/programming/comments/1qpysme/40ns_causal_consistency_by_replacing_consensus/

<!-- SC_OFF -->Distributed systems usually pay milliseconds for correctness because they define correctness as execution order. This project takes a different stance: correctness is a property of algebra, not time. If operations commute, you don’t need coordination. If they don’t, the system tells you at admission time, in nanoseconds. Cuttlefish is a coordination-free state kernel that enforces strict invariants with causal consistency at ~40ns end-to-end (L1-cache scale), zero consensus, zero locks, zero heap in the hot path. Here, state transitions are immutable facts forming a DAG. Every invariant is pure algebra. The way casualty is tracked, is by using 512 bit bloom vector clocks which happen to hit a sub nano second 700ps dominance check. Non-commutativity is detected immediately, but if an invariant is commutative (abelian group/semilattice /monoid), admission requires no coordination. Here are some numbers for context(single core, Ryzen 7, Linux 6.x): Full causal + invariant admission: ~40ns
kernel admit with no deps: ~13ns
Durable admission (io_uring WAL): ~5ns For reference: etcd / Cockroach pay 1–50ms for linearizable writes. What this is: A low-level kernel for building databases, ledgers, replicated state machines Strict invariants without consensus when algebra allows it Bit-deterministic, allocation-free, SIMD-friendly Rust This is grounded in CALM, CRDT theory, and Bloom clocks, but engineered aggressively for modern CPUs (cache lines, branchless code, io_uring). Repo: https://github.com/abokhalill/cuttlefish I'm looking for feedback from people who’ve built consensus systems, CRDTs, or storage engines and think this is either right, or just bs. <!-- SC_ON --> submitted by /u/AdministrativeAsk305 (https://www.reddit.com/user/AdministrativeAsk305)
[link] (https://github.com/abokhalill/cuttlefish) [comments] (https://www.reddit.com/r/programming/comments/1qpysme/40ns_causal_consistency_by_replacing_consensus/)