标签：#programming

Hey everyone, My background is in high-performance systems architecture and low-level optimization, and recently, the memory bloat in modern AI editors has been driving me crazy (WE OBVIOUSLY CAN DO BETTER, WHY ARENT WE???) So, I decided to build something significantly leaner and minimal. I built Axiom which uses up to 3.7x less memory than Cursor and 33% less than VSCode. To hit this benchmark, I took VSCode OSS and stripped Electron out completely. Instead of relying on the bundled Chromium instance, I made the editor run inside LaVista ( https://github.com/IASoft-PVT-LTD/LaVista ). This allowed me to drop the footprint of three idle windows down to just 759 MB, compared to the 2,802 MB you'd see in Cursor. What I added on top: AxiomAI: A Bring Your Own Key (BYOK) setup with a local autocomplete and local router system. Token Management: Built-in tracking to monitor, analyze, and set hard limits on your API token usage so you never get a surprise bill. FlowViz: A native visualization engine that lets you render plots, flowcharts, and fully interactive 3D scenes directly in the editor. I am currently rolling out the beta and would love for some technical folks to try it out and try to break it. You can check it out and register for the beta here: https://iasoft.dev/software-engineering/products/axiom/ Would def love to hear your thoughts on the native webview approach or answer any questions about the LaVista implementation! submitted by /u/I-A-S- [link] [留言]

I built a small Redis clone in C: a RESP parser, a command table, an append-only file for persistence. Recently I started building the same thing again in Rust, and rebuilding a project I had already finished has taught me more Rust than any from-scratch tutorial. The reason is simple. The second time, the design is already solved. I know what the AOF has to guarantee, what the command table dispatches, what the parser must reject. So none of my attention goes to what to build. All of it goes to how Rust wants it built. That turns the domain into a constant and the language into the only variable. Every difference I hit is pure signal about Rust, not noise about key-value stores. The first difference shows up before any logic runs. In C, I built the substrate first: my own dynamic strings, my own hashmap, my own linked list. Hundreds of lines before a single command worked. In Rust, Vec , String , and HashMap are just there, so that whole layer disappears and I start at the actual command logic. A standard library quietly decides where your project even begins. The sharper difference is in dispatch. In C it is a switch with argument counts I check by hand: if ( argc != 3 ) return err ( "wrong arg count" ); switch ( cmd ) { case CMD_SET : return do_set ( argv [ 1 ], argv [ 2 ]); case CMD_GET : return do_get ( argv [ 1 ]); /* forget a case and it is a runtime bug */ } In Rust the same dispatch is an enum and a match, and the compiler will not build until every case is handled: match cmd { Command :: Set { key , val } => self .set ( key , val ), Command :: Get { key } => self .get ( key ), } Same dispatch. One version cannot ship the missing-case bug I actually shipped in C. If you already know a project cold, rebuild it in the language you are learning. You stop thinking about the problem and start feeling the language.

I built SeamStress. It's a code reviewer with one rule: it only reports what it can prove against your actual code, quoting the exact lines. If it can't prove it, the finding gets demoted to a judgment call. Not presented as fact. That rule is enforced by one small piece of code: the verification gate. It decides whether a finding may be shown as verified_real. Every other part of the tool can be wrong and the damage is bounded. If the gate is wrong, the tool shows you a confident claim it never earned, with a proof label on it, and it renders as success. Silently. So before making the repo public, I ran the tool on the gate. Same pipeline it runs on anyone's code: three blind critics, then synthesis, then per finding verification. Eight model calls. It found two critical defects in its own foundation. Defect one: verified with no evidence behind it The status authority looked like this: const result = verifications . find (( v ) => v . findingId === finding . id ); return result ? result . status : " unverified " ; It trusted the verdict on a finding ID match. It never looked at the evidence. And the schema allowed an empty evidence array and an empty quoted code string. So a result shaped like {status: "verified_real", evidence: []} validated cleanly and certified a finding as proven. The report renderer would put that finding in the headline, under copy promising the exact lines quoted as proof, with nothing attached. The evidence block suppressed the display of the missing proof. It did not remove the finding from the verified set. The fix lives at the authority, not just the schema: if ( ! result ) return " unverified " ; const hasRealEvidence = result . evidence . some (( e ) => e . quotedCode . trim (). length > 0 ); return hasRealEvidence ? result . status : " unverified " ; A verdict is honored only when at least one non empty quote backs it. Checking at the authority also catches the whitespace quote variant that a naive schema minimum would miss. Fixed in

submitted by /u/gcampos [link] [留言]

A visual walkthrough of Linux eBPF. It goes through the basic pipeline: write a small C program, compile it with clang, load it with bpf(), get it past the verifier, JIT it, attach it to a kernel event, and read data back through maps/ring buffers. The second half gets into why people use it for tracing, XDP packet filtering, security hooks, and sched_ext, then ends with the less fun part: the verifier is the safety boundary, and eBPF gets a lot scarier when the person loading the program already has access. submitted by /u/Ok_Marionberry8922 [link] [留言]

Orasort, a sorting algorithm from Oracle, came into the public domain in 2024 after its patent expired, providing massive benefits to open-source software. submitted by /u/Ok_Stomach6651 [link] [留言]

submitted by /u/nee_- [link] [留言]

submitted by /u/Adventurous-Salt8514 [link] [留言]

ASP.NET Core: Building High-Performance Web Applications and APIs A practical guide to ASP.NET Core — the cross-platform framework for building REST APIs, MVC applications, and backend services on .NET, covering architecture, minimal APIs, middleware, performance, and modern patterns. Table of Contents Introduction Architecture Overview Minimal APIs MVC and Controllers Middleware Pipeline Dependency Injection Configuration and Options Authentication and Authorization Performance Features Testing and Observability Quick Reference Table Conclusion Introduction ASP.NET Core is a free, open-source, cross-platform framework for building web apps, APIs, and backend services. It's a ground-up rewrite of the original ASP.NET, designed around three priorities: Performance — it's consistently one of the fastest mainstream web frameworks in independent benchmarks (e.g., TechEmpower). Modularity — you opt into only the middleware and services your app actually needs, instead of a fixed, heavyweight pipeline. Cross-platform — runs identically on Windows, Linux, and macOS, and deploys to containers, serverless, or bare metal. This guide covers the core building blocks you'll use in almost any ASP.NET Core project, from a five-line minimal API to a full MVC application with authentication and background services. 1. Architecture Overview Every ASP.NET Core app starts from a unified entry point — Program.cs — using the minimal hosting model introduced in .NET 6. var builder = WebApplication . CreateBuilder ( args ); // Register services (dependency injection container) builder . Services . AddControllers (); builder . Services . AddEndpointsApiExplorer (); builder . Services . AddSwaggerGen (); var app = builder . Build (); // Configure the HTTP request pipeline (middleware) if ( app . Environment . IsDevelopment ()) { app . UseSwagger (); app . UseSwaggerUI (); } app . UseHttpsRedirection (); app . UseAuthorization (); app . MapControllers (); app . Run (); Two phases matter here:

Feels like most dev discourse assumes Mac/Linux by default, but the Windows tooling situation (WSL, terminal, package managers) has improved a ton the last couple years. Anyone else building daily on Windows and just not mentioned it because nobody asks? submitted by /u/JaveVictor [link] [留言]

Looking for the best AI UI design tool in 2026? I tested Flowstep, Google Stitch, Figma Make, Lovable, and Base44 with the exact same SaaS project management prompt to compare UI quality, design consistency, code generation, developer workflow, Figma integration, and overall usability. If you've searched for an AI UI design tool recently, you've probably noticed that every product claims it can turn a simple prompt into a polished interface in seconds. Landing pages are full of beautiful dashboards, glowing testimonials, and promises that you'll never have to start from a blank canvas again. The problem is that those demos rarely tell you what happens when you ask the AI design tool to generate something that looks like an actual product instead of a single screenshot. I wanted to know how these AI UI generator tools would perform on a realistic workflow. Could they keep a design system consistent across multiple screens? Would they generate layouts that developers could build on? Could they produce code that was worth keeping, or would I end up rebuilding everything from scratch anyway? Instead of trying different prompts for different tools, I decided to make things as fair as possible. I wrote one detailed prompt for a SaaS project management application and used it everywhere. The five AI design tools I tested were: Flowstep Google Stitch Figma Make Lovable Base44 They all approach AI-assisted UI generation differently, and after spending time with each one, it became clear that they're not really competing to solve the same problem. If you're trying to figure out which AI UI design tool is worth adding to your workflow in 2026, here's what I learned after putting all five through the exact same test. Why AI UI Design Tools Are Becoming Part of Every Developer's Workflow A year or two ago, most AI UI design tools were good at generating a nice-looking landing page and not much else. Today, the landscape looks very different. Some tools can generate an entire mul

Ran into this while working on a coordination primitive for a payments system: locks and consensus (Redis, Raft, etcd) all answer "who can act right now" none answer "did the action actually complete" once a crash happens. That's a harder, separate problem most systems just inherit Temporal's answer to (determinism + replay). Blog submitted by /u/munch_muffin_solas [link] [留言]

submitted by /u/wheatBread [link] [留言]

How I Cut Our AI API Bill by 95% — The Engineering Playbook When our finance lead forwarded me the AWS bill for March, I almost choked on my coffee. We were a team of nine engineers shipping AI features, and somehow we'd burned through enough on inference to cover two salaries. The worst part? I hadn't even noticed because the charges were scattered across OpenAI, Anthropic, and a couple of side experiments. That's the moment I decided to actually treat LLM spending like a real infrastructure problem instead of a credit card swipe. What follows is the playbook I wish I'd had on day one. These aren't theoretical tips — they're the exact moves I made across three products to get our run-rate down to roughly 5% of where it started, without shipping worse software. The Harsh Truth About Model Defaults Here's the dirty secret nobody tells you in the LLM hype cycle: most teams default to the most famous model for every single call. GPT-4o for everything. Claude Sonnet for everything. Then they wonder why their "simple AI feature" costs them a kidney. The model selection decision is where I recovered the majority of my budget. When you look at it rationally, the gap between the flagship tier and the cheap-tier models is absurd for tasks that don't require frontier reasoning. This is the matrix I landed on, and it still governs our routing today: Task What I Used To Use What I Use Now Cost Cut Simple chat GPT-4o ($10/M out) DeepSeek V4 Flash ($0.25/M) 97.5% Classification GPT-4o-mini ($0.60/M) Qwen3-8B ($0.01/M) 98.3% Code generation GPT-4o ($10/M) DeepSeek Coder ($0.25/M) 97.5% Summarization GPT-4o ($10/M) Qwen3-32B ($0.28/M) 97.2% Translation GPT-4o ($10/M) Qwen-MT-Turbo ($0.30/M) 97% I want you to really sit with the classification row. Qwen3-8B at $0.01 per million output tokens. That's sixty times cheaper than GPT-4o-mini. For a binary sentiment classifier, the accuracy difference in my benchmarks was under 1.5 percentage points. The ROI math isn't even close. The code

Notes: Prototype : a line that promises to a compiler that a certain function exists somewhere in the server or harddisk or files so it doesn't throw an error. In C, it is done with copying the declaration line of a function and adding a semicolon at the end of it. When we download / setup a specific programming language we download: the specific version of the language's compiler for your operating system and CPU the version of machine code of standard functions that the creator of the language has written that is fine tuned for our operating system and CPU the header files that has Only the prototype of the standard functions (aka functions like printf that are created by the creator of C) We need these in the compilation process: Pre-processing: compiler changing the header files calling line (#include line) with actual prototypes that are inside the header files and creates a temporary file with .i extension (temporary cause it gets deleted in the next step) that contains the prototype at the very top instead of #include line and your source code below compilation: compiler changes the entire contents of the .I file into assembly code (code written in assembly language). Here is why the specific version of compiler is important because every CPU has specific assembly language commands that are unique to it. Therefore when we setup a language we download specific assembly instructions for our own operating system and it comes handy in this step. Syntax check also happens in this step and the .I file also gets deleted. Now there comes a a.out file that we can actually see listed in our file explorer (but we only see the a.out file after the very end of compilation process but it does exist by this stage) Assembling: compiler changes assembly code (a.out file) to machine code (aka 0's and 1's). linking: compiler links your machine code and the machine code FOR the standard functions (because till now it ONLY has the prototypes of the function written in Binary, not

Alright, real talk moment. Last week I watched someone with zero coding background build a fully...

submitted by /u/jac08_h [link] [留言]

This post was originally published on MatrixTrak.com — the production reliability toolkit for trading bot operators and .NET engineers. Complete WebSocket auto-reconnect guide for trading bots. Implement automatic reconnection with exponential backoff, heartbeat ping-pong, message gap detection, and state recovery. WebSocket connections drop. Not maybe. Definitely. Exchanges reset connections every 24 hours. Networks glitch. Load balancers rotate. HTTP proxies timeout. Your trading bot will experience disconnects. The question isn't whether you'll disconnect—it's whether your bot recovers correctly when you do. If you only do three things Implement automatic reconnection with exponential backoff and jitter. Track sequence numbers to detect missed messages. Always verify state via REST after reconnect. Never trust WebSocket alone. WebSocket Auto-Reconnect Quick Start If you just need a working auto-reconnect loop right now, here's the minimum viable implementation: class AutoReconnectWebSocket { private ws : WebSocket | null = null ; private reconnectAttempts = 0 ; private maxRetries = 10 ; private shouldReconnect = true ; async connect ( url : string ): Promise < void > { return new Promise (( resolve , reject ) => { this . ws = new WebSocket ( url ); this . ws . onopen = () => { this . reconnectAttempts = 0 ; resolve (); }; this . ws . onclose = ( event ) => { if ( this . shouldReconnect ) { const delay = this . backoff (); console . log ( `[AutoReconnect] Closed ${ event . code } . Reconnecting in ${ delay } ms` ); setTimeout (() => this . connect ( url ), delay ); } }; this . ws . onerror = () => { /* onclose fires next */ }; }); } private backoff (): number { const base = 1000 ; const max = 30000 ; const delay = Math . min ( base * Math . pow ( 2 , this . reconnectAttempts ++ ), max ); return delay + delay * 0.2 * ( Math . random () * 2 - 1 ); // +20% jitter } close (): void { this . shouldReconnect = false ; this . ws ?. close (); } } This handles the core auto

Everyone talks about AI speeding up coding. Nobody talks about debugging AI-generated code. Last month, I spent three hours hunting down a bug in a 20-line function that an LLM wrote in thirty seconds. That's not a productivity gain—that's a productivity swap. You trade typing speed for debugging speed, and most of the time the trade is terrible. I've been using AI assistants for about a year now, mostly Claude and GPT-4, and I've noticed a pattern. The first version of any moderately complex piece of code always has at least one subtle mistake. Not syntax errors—those are easy. I'm talking about logical off-by-ones, missing edge cases, or completely hallucinated API calls. And the worst part? The AI writes the code with such confidence that you assume it's correct. You run it, it crashes, and you spend ten minutes thinking you misused the function before you finally look at the generated code with a suspicious eye. Let me show you a concrete example. I was building a small Node.js service that fetches data from a paginated REST API and merges the results. I asked the AI to write a function that handles pagination with a while loop and an offset parameter. Here's what it gave me: async function fetchAllPages ( baseUrl , limit = 100 ) { let offset = 0 ; let allData = []; let hasMore = true ; while ( hasMore ) { const response = await fetch ( ` ${ baseUrl } ?limit= ${ limit } &offset= ${ offset } ` ); const data = await response . json (); allData = allData . concat ( data . results ); hasMore = data . results . length === limit ; offset += limit ; } return allData ; } Looks clean, right? I pasted it in, ran my test, and got an infinite loop. The server returned a 400 error after a few requests, but the function kept going because response.ok was never checked. The AI assumed every call succeeds. I spent forty-five minutes debugging that—not because the bug was hard, but because I trusted the output. I added a try/catch and a status check, and then I found the real is

If your memory is hosted, your thoughts are leased. We did not just move our files to the cloud. We moved our working memory. Andy Clark and David Chalmers called it the extended mind in 1998. The thesis was simple. Cognition leaks into the tools we trust. A notebook can be part of your mind if you access it reliably. In 2026, that notebook is a vector database owned by a platform with a legal department. Your extended mind now has terms of service, retention policies, and a compliance team that answers subpoenas faster than you answer email. I am not interested in nostalgia for paper. I am interested in architecture that preserves agency. The fix is not to think less with machines. It is to think locally with machines you control. That is why I built a second brain that lives on a Raspberry Pi 5 with NVMe and a Hailo-8 accelerator, running Retrieval Augmented Generation completely offline. No API keys. No telemetry. No third party that can be compelled to hand over your associative graph. This is the expanded blueprint. More cohesive, more rigorous, and more useful than the usual cloud versus local sermon. The extended mind, now with a landlord The original extended mind argument was about trust and coupling. If you reach for a tool as automatically as you reach for a memory, it counts as cognition. The cloud broke that coupling by inserting a landlord. Your retrieval is fast, but it is also observed, logged, ranked, and retained. Three consequences follow. First, epistemic pollution. When your queries train their models, your future answers are shaped by everyone else’s queries. Your private context gets diluted by the median user. Second, legal exposure. Your prompts, your uploads, your retrieval history, and your embeddings are business records. In many jurisdictions they are discoverable. You cannot plead the fifth for data you gave to a provider. Third, strategic fragility. A policy change, a price hike, a region block, and your cognitive prosthesis goes dark.