Reddit Programming – Telegram
Reddit Programming
211 subscribers
1.22K photos
125K links
I will send you newest post from subreddit /r/programming
Download Telegram
chr2 - a deterministic replicated log with a durable outbox for side effects
https://www.reddit.com/r/programming/comments/1q9jc36/chr2_a_deterministic_replicated_log_with_a/

<!-- SC_OFF -->Existing consensus libraries replicate logs and elect leaders. They do not solve the part that actually breaks production systems: crash safe side effects. The moment your state machine sends an email, charges a card, or fires a webhook, you’ve stepped outside consensus. If the leader crashes after performing the side effect but before committing it, failover turns retries into duplicates unless you bolt on a second protocol. I kept re implementing that second protocol. chr2 is my attempt to make it explicit. mechanism: -deterministic apply context: application code receives block_time from the log header and a deterministic RNG seed derived from the previous hash, so replay produces identical state transitions. - crash safe WAL: entries are CRC’d, payload hashed, and hash chained. Recovery is strict, torn tails are truncated; mid-log corruption halts. - durable fencing for view changes: a manifest persists the highest view and votes using atomic tmp+fsync+rename, rejecting messages from zombie leaders after restart. - replicated outbox: side effects are stored as "pending" in replicated state. Only the leader executes them under a fencing token. Completion is recorded by committing an acknowledge event, so failover only re-executes effects that were never durably acknowledged. Trade-offs (because there always are): Side effects are intentionally at-least-once; “exactly once” requires sinks to dedupe using stable effect IDs. The system prefers halting on ambiguous disk states over guessing. Some pieces are still being tightened (e.g. persisting client request dedupe state as replicated data rather than an in memory cache). Repo: https://github.com/abokhalill/chr2 If you’ve ever had “exactly once” collapse the first time a leader died mid-flight, this problem shape will look familiar. <!-- SC_ON --> submitted by /u/AdministrativeAsk305 (https://www.reddit.com/user/AdministrativeAsk305)
[link] (https://github.com/abokhalill/chr2) [comments] (https://www.reddit.com/r/programming/comments/1q9jc36/chr2_a_deterministic_replicated_log_with_a/)
Built a real-time vessel tracker using H3 hexagonal spatial indexing for proximity detection
https://www.reddit.com/r/programming/comments/1q9jplj/built_a_realtime_vessel_tracker_using_h3/

<!-- SC_OFF -->Wrote up the full implementation here if you're interested in the technical details: https://dev-jeb.com/deliberate/portal/blog/ocean-terminal-vessel-tracker <!-- SC_ON --> submitted by /u/dev_jeb (https://www.reddit.com/user/dev_jeb)
[link] (https://dev-jeb.com/deliberate/portal/showcase/ocean-terminal-vessel-tracker) [comments] (https://www.reddit.com/r/programming/comments/1q9jplj/built_a_realtime_vessel_tracker_using_h3/)
Reading CPython bytecode with dis: stack execution walkthrough (Length: 3:43)
https://www.reddit.com/r/programming/comments/1q9wonq/reading_cpython_bytecode_with_dis_stack_execution/

<!-- SC_OFF -->Short walkthrough of how CPython executes bytecode using the stack model (push/pop), using Python’s built-in dis module. Covers LOAD_CONST, STORE_NAME/STORE_FAST, LOAD_NAME, BINARY_OP, plus PUSH_NULL, CALL, POP_TOP in a print() call flow. Useful if you’ve seen dis output and wanted a mental model. <!-- SC_ON --> submitted by /u/mdns-99 (https://www.reddit.com/user/mdns-99)
[link] (https://youtu.be/LH2Y15OkG64?si=inerlenGM8r8DfH6) [comments] (https://www.reddit.com/r/programming/comments/1q9wonq/reading_cpython_bytecode_with_dis_stack_execution/)
We default to addition
https://www.reddit.com/r/programming/comments/1qa64pk/we_default_to_addition/

<!-- SC_OFF -->Subtracting usually takes more effort and is not our default approach to solving problems; after all, how deleting something can produce value? Doesn't less mean worse? But so often, reducing complexity and streamlining process by simplifying them - taking something out, rather than adding something in - leads to true improvement, instead of adding more and more and more - tools, technologies and features. Useful perspective to have when solving the next problem - maybe the solution is to delete/simplify, instead of adding? <!-- SC_ON --> submitted by /u/BinaryIgor (https://www.reddit.com/user/BinaryIgor)
[link] (https://www.ufried.com/blog/addition_bias/) [comments] (https://www.reddit.com/r/programming/comments/1qa64pk/we_default_to_addition/)
Domain-Composed Models (DCM): a pragmatic middle ground between Active Record and Clean DDD
https://www.reddit.com/r/programming/comments/1qast8w/domaincomposed_models_dcm_a_pragmatic_middle/

<!-- SC_OFF -->I wrote an article exploring a pattern we converged on in practice when Active Record became too coupled, but repository-heavy Clean DDD felt like unnecessary ceremony for the problem at hand. The idea is to keep domain behavior close to ORM-backed models, while expressing business rules in infra-agnostic mixins that depend on explicit behavioral contracts (hooks). The concrete model implements those hooks using persistence concerns. It’s not a replacement for DDD, and not a defense of Active Record either — more an attempt to formalize a pragmatic middle ground that many teams seem to arrive at organically. The article uses a simple hotel booking example (Python / SQLAlchemy), discusses trade-offs limits of the pattern, and explains where other approaches fit better. Article: https://medium.com/@hamza-senhajirhazi/domain-composed-models-dcm-a-pragmatic-middle-ground-between-active-record-and-clean-ddd-e44172a58246 I’d be genuinely interested in counter-examples or critiques—especially from people who’ve applied DDD in production systems. <!-- SC_ON --> submitted by /u/senhaj_h (https://www.reddit.com/user/senhaj_h)
[link] (https://medium.com/@hamza-senhajirhazi/domain-composed-models-dcm-a-pragmatic-middle-ground-between-active-record-and-clean-ddd-e44172a58246) [comments] (https://www.reddit.com/r/programming/comments/1qast8w/domaincomposed_models_dcm_a_pragmatic_middle/)
Bring back opinionated architecture
https://www.reddit.com/r/programming/comments/1qayazp/bring_back_opinionated_architecture/

<!-- SC_OFF -->Enterprise architecture claims to bring clarity, but often hides behind ambiguity. And maybe that’s something we need to confront. When I was a developer, I was always attracted to highly opinionated libraries and frameworks. I always preferred a single way of doing things, over three different ways to do it, and they all have their pros and cons. This is something Enterprise Architecture really struggles with I feel. We tend to overengineer things. We would rather build a tool with 3 different data interfaces, than commit to 1 well thought out interface. Don’t get me wrong, I’m not advocating here for abandoning backup plans and putting all your eggs in one basket. What I am advocating for is architectural courage. Are all these “it depends” and “future-proofing” mantras there to get to a more correct solution, or just there to minimize your personal responsibility if it all goes haywire? You also have to calculate the cost of it all. In the above scenario where you cover all your bases and build a REST API and an sFTP connection because “you might need it in the future”, you will have to maintain, secure, document, train and test both. For years to come. Just another think that can break. That would be ok if that scenario actually plays out. If the company strategy changes, and the company never connects the two applications, all of that has been for nothing. Then there is the conversation of the easy-off ramp in implementing new software. It’s cool that you can hot swap your incoming data from one service to a different one in less than a week! Now we just need six months of new training, new processes, new KPIs, new goal setting and hiring to use said new data source. I’m not suggesting we should all become architectural “dictators” who refuse to listen to edge cases. But I am suggesting that we stop being so deep into “what-if” and start focusing more on “what-is.” Being opinionated doesn’t mean being rigid, it’s more about actually having a plan. It means having the courage to say, “This is the path we are taking because it is the most efficient one for today.” If the strategy changes in two years, you deal with it then, with the benefit of two years of lower maintenance costs and a leaner system. <!-- SC_ON --> submitted by /u/GeneralZiltoid (https://www.reddit.com/user/GeneralZiltoid)
[link] (https://frederickvanbrabant.com/blog/2026-01-09-bring-back-opinionated-architecture/) [comments] (https://www.reddit.com/r/programming/comments/1qayazp/bring_back_opinionated_architecture/)