How I estimate work as a staff software engineer
https://www.reddit.com/r/programming/comments/1qoj5mb/how_i_estimate_work_as_a_staff_software_engineer/
submitted by /u/Ordinary_Leader_2971 (https://www.reddit.com/user/Ordinary_Leader_2971)
[link] (https://www.seangoedecke.com/how-i-estimate-work/) [comments] (https://www.reddit.com/r/programming/comments/1qoj5mb/how_i_estimate_work_as_a_staff_software_engineer/)
https://www.reddit.com/r/programming/comments/1qoj5mb/how_i_estimate_work_as_a_staff_software_engineer/
submitted by /u/Ordinary_Leader_2971 (https://www.reddit.com/user/Ordinary_Leader_2971)
[link] (https://www.seangoedecke.com/how-i-estimate-work/) [comments] (https://www.reddit.com/r/programming/comments/1qoj5mb/how_i_estimate_work_as_a_staff_software_engineer/)
The Cost of Certainty: Why Perfect is the Enemy of Scale in Distributed Systems
https://www.reddit.com/r/programming/comments/1qokaan/the_cost_of_certainty_why_perfect_is_the_enemy_of/
<!-- SC_OFF -->Even in 2026, no AI can negotiate with the speed of light. ⚛️ As an architect, I’ve realized our biggest expense isn't compute—it’s the Certainty Tax. We pay a massive premium to pretend the world isn't chaotic, but production is pure entropy. I just wrote a deep dive on why we need to stop chasing 100% consistency at scale. Using Pokémon GO as a sandbox, I audited: The Math: Why adding a sidecar can cost you 22 hours of sleep a year. The Sandbox: Why catch history can lie, but player trading must be painfully slow. The Law: How Little’s Law proves that patience in a concurrent system is a liability. If you’ve ever wrestled with PACELC or consensus algorithms, I’d love to hear your thoughts on where you choose to relax your constraints. <!-- SC_ON --> submitted by /u/Level-Sink3315 (https://www.reddit.com/user/Level-Sink3315)
[link] (https://open.substack.com/pub/qianarthurwang/p/the-cost-of-certainty-why-perfect?r=6wytu0) [comments] (https://www.reddit.com/r/programming/comments/1qokaan/the_cost_of_certainty_why_perfect_is_the_enemy_of/)
https://www.reddit.com/r/programming/comments/1qokaan/the_cost_of_certainty_why_perfect_is_the_enemy_of/
<!-- SC_OFF -->Even in 2026, no AI can negotiate with the speed of light. ⚛️ As an architect, I’ve realized our biggest expense isn't compute—it’s the Certainty Tax. We pay a massive premium to pretend the world isn't chaotic, but production is pure entropy. I just wrote a deep dive on why we need to stop chasing 100% consistency at scale. Using Pokémon GO as a sandbox, I audited: The Math: Why adding a sidecar can cost you 22 hours of sleep a year. The Sandbox: Why catch history can lie, but player trading must be painfully slow. The Law: How Little’s Law proves that patience in a concurrent system is a liability. If you’ve ever wrestled with PACELC or consensus algorithms, I’d love to hear your thoughts on where you choose to relax your constraints. <!-- SC_ON --> submitted by /u/Level-Sink3315 (https://www.reddit.com/user/Level-Sink3315)
[link] (https://open.substack.com/pub/qianarthurwang/p/the-cost-of-certainty-why-perfect?r=6wytu0) [comments] (https://www.reddit.com/r/programming/comments/1qokaan/the_cost_of_certainty_why_perfect_is_the_enemy_of/)
4 Pyrefly Type Narrowing Patterns that make Python Type Checking more Intuitive
https://www.reddit.com/r/programming/comments/1qolknv/4_pyrefly_type_narrowing_patterns_that_make/
<!-- SC_OFF -->Since Python is a duck-typed language, programs often narrow types by checking a structural property of something rather than just its class name. For a type checker, understanding a wide variety of narrowing patterns is essential for making it as easy as possible for users to type check their code and reduce the amount of changes made purely to “satisfy the type checker”. In this blog post, we’ll go over some cool forms of narrowing that Pyrefly supports, which allows it to understand common code patterns in Python. To the best of our knowledge, Pyrefly is the only type checker for Python that supports all of these patterns. Contents: 1. hasattr/getattr 2. tagged unions 3. tuple length checks 4. saving conditions in variables Blog post: https://pyrefly.org/blog/type-narrowing/ Github: https://github.com/facebook/pyrefly <!-- SC_ON --> submitted by /u/BeamMeUpBiscotti (https://www.reddit.com/user/BeamMeUpBiscotti)
[link] (https://pyrefly.org/blog/type-narrowing/) [comments] (https://www.reddit.com/r/programming/comments/1qolknv/4_pyrefly_type_narrowing_patterns_that_make/)
https://www.reddit.com/r/programming/comments/1qolknv/4_pyrefly_type_narrowing_patterns_that_make/
<!-- SC_OFF -->Since Python is a duck-typed language, programs often narrow types by checking a structural property of something rather than just its class name. For a type checker, understanding a wide variety of narrowing patterns is essential for making it as easy as possible for users to type check their code and reduce the amount of changes made purely to “satisfy the type checker”. In this blog post, we’ll go over some cool forms of narrowing that Pyrefly supports, which allows it to understand common code patterns in Python. To the best of our knowledge, Pyrefly is the only type checker for Python that supports all of these patterns. Contents: 1. hasattr/getattr 2. tagged unions 3. tuple length checks 4. saving conditions in variables Blog post: https://pyrefly.org/blog/type-narrowing/ Github: https://github.com/facebook/pyrefly <!-- SC_ON --> submitted by /u/BeamMeUpBiscotti (https://www.reddit.com/user/BeamMeUpBiscotti)
[link] (https://pyrefly.org/blog/type-narrowing/) [comments] (https://www.reddit.com/r/programming/comments/1qolknv/4_pyrefly_type_narrowing_patterns_that_make/)
The Age of Pump and Dump Software
https://www.reddit.com/r/programming/comments/1qon4yu/the_age_of_pump_and_dump_software/
<!-- SC_OFF -->A new worrying amalgamation of crypto scams and vibe coding emerges from the bowels of the internet in 2026 <!-- SC_ON --> submitted by /u/Gil_berth (https://www.reddit.com/user/Gil_berth)
[link] (https://tautvilas.medium.com/software-pump-and-dump-c8a9a73d313b) [comments] (https://www.reddit.com/r/programming/comments/1qon4yu/the_age_of_pump_and_dump_software/)
https://www.reddit.com/r/programming/comments/1qon4yu/the_age_of_pump_and_dump_software/
<!-- SC_OFF -->A new worrying amalgamation of crypto scams and vibe coding emerges from the bowels of the internet in 2026 <!-- SC_ON --> submitted by /u/Gil_berth (https://www.reddit.com/user/Gil_berth)
[link] (https://tautvilas.medium.com/software-pump-and-dump-c8a9a73d313b) [comments] (https://www.reddit.com/r/programming/comments/1qon4yu/the_age_of_pump_and_dump_software/)
Glaze is getting even faster – SIMD refactoring and crazy whitespace skipping in the works
https://www.reddit.com/r/programming/comments/1qoonvl/glaze_is_getting_even_faster_simd_refactoring_and/
submitted by /u/PalpitationUnlikely5 (https://www.reddit.com/user/PalpitationUnlikely5)
[link] (https://github.com/stephenberry/glaze/pull/2270) [comments] (https://www.reddit.com/r/programming/comments/1qoonvl/glaze_is_getting_even_faster_simd_refactoring_and/)
https://www.reddit.com/r/programming/comments/1qoonvl/glaze_is_getting_even_faster_simd_refactoring_and/
submitted by /u/PalpitationUnlikely5 (https://www.reddit.com/user/PalpitationUnlikely5)
[link] (https://github.com/stephenberry/glaze/pull/2270) [comments] (https://www.reddit.com/r/programming/comments/1qoonvl/glaze_is_getting_even_faster_simd_refactoring_and/)
GNU C Library moving from Sourceware to Linux Foundation hosted CTI
https://www.reddit.com/r/programming/comments/1qophgl/gnu_c_library_moving_from_sourceware_to_linux/
submitted by /u/Fcking_Chuck (https://www.reddit.com/user/Fcking_Chuck)
[link] (https://www.phoronix.com/news/GNU-C-Library-To-CTI-LF) [comments] (https://www.reddit.com/r/programming/comments/1qophgl/gnu_c_library_moving_from_sourceware_to_linux/)
https://www.reddit.com/r/programming/comments/1qophgl/gnu_c_library_moving_from_sourceware_to_linux/
submitted by /u/Fcking_Chuck (https://www.reddit.com/user/Fcking_Chuck)
[link] (https://www.phoronix.com/news/GNU-C-Library-To-CTI-LF) [comments] (https://www.reddit.com/r/programming/comments/1qophgl/gnu_c_library_moving_from_sourceware_to_linux/)
Panoptic Segmentation using Detectron2
https://www.reddit.com/r/programming/comments/1qopi7p/panoptic_segmentation_using_detectron2/
<!-- SC_OFF -->For anyone studying Panoptic Segmentation using Detectron2, this tutorial walks through how panoptic segmentation combines instance segmentation (separating individual objects) and semantic segmentation (labeling background regions), so you get a complete pixel-level understanding of a scene. It uses Detectron2’s pretrained COCO panoptic model from the Model Zoo, then shows the full inference workflow in Python: reading an image with OpenCV, resizing it for faster processing, loading the panoptic configuration and weights, running prediction, and visualizing the merged “things and stuff” output. Video explanation: https://youtu.be/MuzNooUNZSY Medium version for readers who prefer Medium : https://medium.com/image-segmentation-tutorials/detectron2-panoptic-segmentation-made-easy-for-beginners-9f56319bb6cc Written explanation with code: https://eranfeit.net/detectron2-panoptic-segmentation-made-easy-for-beginners/ This content is shared for educational purposes only, and constructive feedback or discussion is welcome. Eran Feit <!-- SC_ON --> submitted by /u/Feitgemel (https://www.reddit.com/user/Feitgemel)
[link] (https://eranfeit.net/detectron2-panoptic-segmentation-made-easy-for-beginners/) [comments] (https://www.reddit.com/r/programming/comments/1qopi7p/panoptic_segmentation_using_detectron2/)
https://www.reddit.com/r/programming/comments/1qopi7p/panoptic_segmentation_using_detectron2/
<!-- SC_OFF -->For anyone studying Panoptic Segmentation using Detectron2, this tutorial walks through how panoptic segmentation combines instance segmentation (separating individual objects) and semantic segmentation (labeling background regions), so you get a complete pixel-level understanding of a scene. It uses Detectron2’s pretrained COCO panoptic model from the Model Zoo, then shows the full inference workflow in Python: reading an image with OpenCV, resizing it for faster processing, loading the panoptic configuration and weights, running prediction, and visualizing the merged “things and stuff” output. Video explanation: https://youtu.be/MuzNooUNZSY Medium version for readers who prefer Medium : https://medium.com/image-segmentation-tutorials/detectron2-panoptic-segmentation-made-easy-for-beginners-9f56319bb6cc Written explanation with code: https://eranfeit.net/detectron2-panoptic-segmentation-made-easy-for-beginners/ This content is shared for educational purposes only, and constructive feedback or discussion is welcome. Eran Feit <!-- SC_ON --> submitted by /u/Feitgemel (https://www.reddit.com/user/Feitgemel)
[link] (https://eranfeit.net/detectron2-panoptic-segmentation-made-easy-for-beginners/) [comments] (https://www.reddit.com/r/programming/comments/1qopi7p/panoptic_segmentation_using_detectron2/)
Introducing Script: JavaScript That Runs Like Rust
https://www.reddit.com/r/programming/comments/1qosew5/introducing_script_javascript_that_runs_like_rust/
submitted by /u/SecretAggressive (https://www.reddit.com/user/SecretAggressive)
[link] (https://docs.script-lang.org/blog/introducing-script) [comments] (https://www.reddit.com/r/programming/comments/1qosew5/introducing_script_javascript_that_runs_like_rust/)
https://www.reddit.com/r/programming/comments/1qosew5/introducing_script_javascript_that_runs_like_rust/
submitted by /u/SecretAggressive (https://www.reddit.com/user/SecretAggressive)
[link] (https://docs.script-lang.org/blog/introducing-script) [comments] (https://www.reddit.com/r/programming/comments/1qosew5/introducing_script_javascript_that_runs_like_rust/)
JSON vs XML in Embedded Linux - system design trade-offs
https://www.reddit.com/r/programming/comments/1qp07z1/json_vs_xml_in_embedded_linux_system_design/
<!-- SC_OFF -->Data formats define whether systems are lean or bloated. I explored how JSON and XML flow through embedded Linux: - Hardware → Driver → Kernel → Middleware → Application - Real code examples (I²C, sysfs, cJSON, libxml2) - Debugging strategies at every layer - Performance insights: JSON vs XML. Curious how others here approach data structuring in embedded or system-level projects — JSON, XML, or custom formats? <!-- SC_ON --> submitted by /u/ImaginaryPin1768 (https://www.reddit.com/user/ImaginaryPin1768)
[link] (https://codewafer.com/blogs/json-xml-in-embedded-linux-full-stack-guide-with-drivers-middleware/) [comments] (https://www.reddit.com/r/programming/comments/1qp07z1/json_vs_xml_in_embedded_linux_system_design/)
https://www.reddit.com/r/programming/comments/1qp07z1/json_vs_xml_in_embedded_linux_system_design/
<!-- SC_OFF -->Data formats define whether systems are lean or bloated. I explored how JSON and XML flow through embedded Linux: - Hardware → Driver → Kernel → Middleware → Application - Real code examples (I²C, sysfs, cJSON, libxml2) - Debugging strategies at every layer - Performance insights: JSON vs XML. Curious how others here approach data structuring in embedded or system-level projects — JSON, XML, or custom formats? <!-- SC_ON --> submitted by /u/ImaginaryPin1768 (https://www.reddit.com/user/ImaginaryPin1768)
[link] (https://codewafer.com/blogs/json-xml-in-embedded-linux-full-stack-guide-with-drivers-middleware/) [comments] (https://www.reddit.com/r/programming/comments/1qp07z1/json_vs_xml_in_embedded_linux_system_design/)
I tried learning compilers by building a language. It got out of hand.
https://www.reddit.com/r/programming/comments/1qp1j5m/i_tried_learning_compilers_by_building_a_language/
<!-- SC_OFF -->Hi all, I wanted to share a personal learning project I’ve been working on called sr-lang. It’s a small programming language and compiler written in Zig, with MLIR as the backend. I started it as a way to learn compiler construction by doing. Zig felt like a great fit, and its style/constraints ended up influencing the language design more than I expected. For context, I’m an ML researcher and I work with GPU-related stuff a lot, which is why you’ll see GPU-oriented experiments show up (e.g. Triton). Over time the project grew as I explored parsing, semantic analysis, type systems, and backend design. Some parts are relatively solid, and others are experimental or rough, which is very much part of the learning process. A bit of honesty up front I’m not a compiler expert. I used LLMs occasionally to explore ideas or unblock iterations. The design decisions and bugs are mine. If something looks awkward or overcomplicated, it probably reflects what I was learning at the time. It did take more than 10 months to get to this point (I'm slow). Some implemented highlights (selected) Parser, AST, and semantic analysis in Zig MLIR-based backend Error unions and defer / errdefer style cleanup Pattern matching and sum types comptime and AST-as-data via code {} blocks Async/await and closures (still evolving) Inline MLIR and asm {} support Triton / GPU integration experiments What’s incomplete Standard library is minimal Diagnostics/tooling and tests need work Some features are experimental and not well integrated yet I’m sharing this because I’d love feedback on design tradeoffs and rough edges help spotting obvious issues (or suggesting better structure) contributors who want low-pressure work (stdlib, tests, docs, diagnostics, refactors) Repo: https://github.com/theunnecessarythings/sr-lang Thanks for reading. Happy to answer questions or take criticism. <!-- SC_ON --> submitted by /u/theunnecessarythings (https://www.reddit.com/user/theunnecessarythings)
[link] (https://github.com/theunnecessarythings/sr-lang) [comments] (https://www.reddit.com/r/programming/comments/1qp1j5m/i_tried_learning_compilers_by_building_a_language/)
https://www.reddit.com/r/programming/comments/1qp1j5m/i_tried_learning_compilers_by_building_a_language/
<!-- SC_OFF -->Hi all, I wanted to share a personal learning project I’ve been working on called sr-lang. It’s a small programming language and compiler written in Zig, with MLIR as the backend. I started it as a way to learn compiler construction by doing. Zig felt like a great fit, and its style/constraints ended up influencing the language design more than I expected. For context, I’m an ML researcher and I work with GPU-related stuff a lot, which is why you’ll see GPU-oriented experiments show up (e.g. Triton). Over time the project grew as I explored parsing, semantic analysis, type systems, and backend design. Some parts are relatively solid, and others are experimental or rough, which is very much part of the learning process. A bit of honesty up front I’m not a compiler expert. I used LLMs occasionally to explore ideas or unblock iterations. The design decisions and bugs are mine. If something looks awkward or overcomplicated, it probably reflects what I was learning at the time. It did take more than 10 months to get to this point (I'm slow). Some implemented highlights (selected) Parser, AST, and semantic analysis in Zig MLIR-based backend Error unions and defer / errdefer style cleanup Pattern matching and sum types comptime and AST-as-data via code {} blocks Async/await and closures (still evolving) Inline MLIR and asm {} support Triton / GPU integration experiments What’s incomplete Standard library is minimal Diagnostics/tooling and tests need work Some features are experimental and not well integrated yet I’m sharing this because I’d love feedback on design tradeoffs and rough edges help spotting obvious issues (or suggesting better structure) contributors who want low-pressure work (stdlib, tests, docs, diagnostics, refactors) Repo: https://github.com/theunnecessarythings/sr-lang Thanks for reading. Happy to answer questions or take criticism. <!-- SC_ON --> submitted by /u/theunnecessarythings (https://www.reddit.com/user/theunnecessarythings)
[link] (https://github.com/theunnecessarythings/sr-lang) [comments] (https://www.reddit.com/r/programming/comments/1qp1j5m/i_tried_learning_compilers_by_building_a_language/)
Selectively Disabling HTTP/1.0 and HTTP/1.1
https://www.reddit.com/r/programming/comments/1qp7yqj/selectively_disabling_http10_and_http11/
submitted by /u/self (https://www.reddit.com/user/self)
[link] (https://markmcb.com/web/selectively_disabling_http_1/) [comments] (https://www.reddit.com/r/programming/comments/1qp7yqj/selectively_disabling_http10_and_http11/)
https://www.reddit.com/r/programming/comments/1qp7yqj/selectively_disabling_http10_and_http11/
submitted by /u/self (https://www.reddit.com/user/self)
[link] (https://markmcb.com/web/selectively_disabling_http_1/) [comments] (https://www.reddit.com/r/programming/comments/1qp7yqj/selectively_disabling_http10_and_http11/)
Cloudflare claimed they implemented Matrix on Cloudflare workers. They didn't
https://www.reddit.com/r/programming/comments/1qp836e/cloudflare_claimed_they_implemented_matrix_on/
submitted by /u/f311a (https://www.reddit.com/user/f311a)
[link] (https://tech.lgbt/@JadedBlueEyes/115967791152135761) [comments] (https://www.reddit.com/r/programming/comments/1qp836e/cloudflare_claimed_they_implemented_matrix_on/)
https://www.reddit.com/r/programming/comments/1qp836e/cloudflare_claimed_they_implemented_matrix_on/
submitted by /u/f311a (https://www.reddit.com/user/f311a)
[link] (https://tech.lgbt/@JadedBlueEyes/115967791152135761) [comments] (https://www.reddit.com/r/programming/comments/1qp836e/cloudflare_claimed_they_implemented_matrix_on/)
Agentic Memory Poisoning: How Long-Term AI Context Can Be Weaponized
https://www.reddit.com/r/programming/comments/1qp94gs/agentic_memory_poisoning_how_longterm_ai_context/
submitted by /u/JadeLuxe (https://www.reddit.com/user/JadeLuxe)
[link] (https://instatunnel.my/blog/agentic-memory-poisoning-how-long-term-ai-context-can-be-weaponized) [comments] (https://www.reddit.com/r/programming/comments/1qp94gs/agentic_memory_poisoning_how_longterm_ai_context/)
https://www.reddit.com/r/programming/comments/1qp94gs/agentic_memory_poisoning_how_longterm_ai_context/
submitted by /u/JadeLuxe (https://www.reddit.com/user/JadeLuxe)
[link] (https://instatunnel.my/blog/agentic-memory-poisoning-how-long-term-ai-context-can-be-weaponized) [comments] (https://www.reddit.com/r/programming/comments/1qp94gs/agentic_memory_poisoning_how_longterm_ai_context/)
Whatsapp rewrote its media handler to rust (160k c++ to 90k rust)
https://www.reddit.com/r/programming/comments/1qpdiio/whatsapp_rewrote_its_media_handler_to_rust_160k_c/
submitted by /u/NYPuppy (https://www.reddit.com/user/NYPuppy)
[link] (https://engineering.fb.com/2026/01/27/security/rust-at-scale-security-whatsapp/) [comments] (https://www.reddit.com/r/programming/comments/1qpdiio/whatsapp_rewrote_its_media_handler_to_rust_160k_c/)
https://www.reddit.com/r/programming/comments/1qpdiio/whatsapp_rewrote_its_media_handler_to_rust_160k_c/
submitted by /u/NYPuppy (https://www.reddit.com/user/NYPuppy)
[link] (https://engineering.fb.com/2026/01/27/security/rust-at-scale-security-whatsapp/) [comments] (https://www.reddit.com/r/programming/comments/1qpdiio/whatsapp_rewrote_its_media_handler_to_rust_160k_c/)
Microsoft forced me to switch to Linux
https://www.reddit.com/r/programming/comments/1qpfz0l/microsoft_forced_me_to_switch_to_linux/
submitted by /u/Dear-Economics-315 (https://www.reddit.com/user/Dear-Economics-315)
[link] (https://www.himthe.dev/blog/microsoft-to-linux) [comments] (https://www.reddit.com/r/programming/comments/1qpfz0l/microsoft_forced_me_to_switch_to_linux/)
https://www.reddit.com/r/programming/comments/1qpfz0l/microsoft_forced_me_to_switch_to_linux/
submitted by /u/Dear-Economics-315 (https://www.reddit.com/user/Dear-Economics-315)
[link] (https://www.himthe.dev/blog/microsoft-to-linux) [comments] (https://www.reddit.com/r/programming/comments/1qpfz0l/microsoft_forced_me_to_switch_to_linux/)
Simple analogy to understand forward proxy vs reverse proxy
https://www.reddit.com/r/programming/comments/1qpg40g/simple_analogy_to_understand_forward_proxy_vs/
submitted by /u/Comfortable-Fan-580 (https://www.reddit.com/user/Comfortable-Fan-580)
[link] (https://pradyumnachippigiri.substack.com/p/client-side-proxy-vs-server-side) [comments] (https://www.reddit.com/r/programming/comments/1qpg40g/simple_analogy_to_understand_forward_proxy_vs/)
https://www.reddit.com/r/programming/comments/1qpg40g/simple_analogy_to_understand_forward_proxy_vs/
submitted by /u/Comfortable-Fan-580 (https://www.reddit.com/user/Comfortable-Fan-580)
[link] (https://pradyumnachippigiri.substack.com/p/client-side-proxy-vs-server-side) [comments] (https://www.reddit.com/r/programming/comments/1qpg40g/simple_analogy_to_understand_forward_proxy_vs/)
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/)
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/)
[Video] Code Comments - Cain On Games
https://www.reddit.com/r/programming/comments/1qpi3ut/video_code_comments_cain_on_games/
submitted by /u/levodelellis (https://www.reddit.com/user/levodelellis)
[link] (https://www.youtube.com/watch?v=GYp00o-sewY) [comments] (https://www.reddit.com/r/programming/comments/1qpi3ut/video_code_comments_cain_on_games/)
https://www.reddit.com/r/programming/comments/1qpi3ut/video_code_comments_cain_on_games/
submitted by /u/levodelellis (https://www.reddit.com/user/levodelellis)
[link] (https://www.youtube.com/watch?v=GYp00o-sewY) [comments] (https://www.reddit.com/r/programming/comments/1qpi3ut/video_code_comments_cain_on_games/)
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/)
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
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/)
[link] (https://pvizgenerator.com/test-cases) [comments] (https://www.reddit.com/r/programming/comments/1qpkt35/we_analyzed_6_realworld_frameworks_across_6/)