标签：#programming

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

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

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

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

Every engineering team that ships an AI feature eventually has the same meeting: someone pulls up a pricing page, someone else pastes a benchmark screenshot from a forum post, and the decision gets made on vibes. That's a bad way to pick the model provider your product will depend on for the next two years. The OpenAI vs Anthropic API decision isn't really about which model is "smarter" this quarter — model quality leapfrogs every few months, and today's edge is gone by the next release cycle. What actually determines whether your AI feature is pleasant to build, cheap to run, and easy to maintain is the shape of the API underneath it: how it handles conversation state, how reliably it calls tools, how it prices repeated context, and how much application logic ends up welded to one vendor's conventions. This post is a practical, engineering-first look at those structural differences, written for teams past the demo stage trying to ship something that works in production, at scale, for paying customers. Why the OpenAI vs Anthropic API Comparison Matters More Than Model Quality It's tempting to treat this as a leaderboard question — whichever model scores higher on the latest benchmark wins. That's the wrong axis to optimize for a production SaaS feature. Benchmarks measure narrow tasks under ideal conditions; your feature has to survive malformed input, network failures, cost constraints, and the reality that whatever model you pick today will be superseded within months. What doesn't change as quickly is the API contract: request and response schema, conventions for multi-turn state, the tool-calling protocol, and the caching and rate-limiting behavior your infrastructure has to accommodate. Get those decisions right and swapping model versions later is a config change. Get them wrong and you're rewriting your orchestration layer every time a new model ships. That's why an OpenAI vs Anthropic API comparison for a production team should spend more time on API design

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

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

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. You've probably noticed this if you've tried to fetch a public webpage in the last two years. You write four lines of Python. You get a 403. You add a User-Agent header. You get a 403 with better manners. You spin up headless Chrome and get a challenge page that spins forever. Eventually you go looking at pricing pages for data APIs, where a cheerful landing page offers to sell you back the exact same public HTML for $100 a month. Meanwhile the big labs vacuumed up that same web at a scale none of us will ever match, and now the standard way to read a page programmatically is to pay somebody. The web went from "open by default" to "open, but only if you look like a person holding a mouse." So let's talk about eight open source projects quietly clawing that access back. I've used most of these in anger. Some are brilliant. Quick note on star counts: I mention a few, because they are a decent signal of "somebody else has hit the bugs before you." They are not a signal of maintenance. A repo can have 70k stars and a last commit from 2023. Always check the commit graph before you check the star count. 1. Firecrawl: the one that turned a URL into a prompt What it does: you hand it a URL, it hands you clean markdown. Not HTML with the nav bar and the cookie banner and four newsletter modals. Markdown. Headings, paragraphs, links, done. It also does more than single pages. The crawl endpoint walks a whole site, map gives you a URL inventory without fetching everything, and structured extraction pulls typed JSON out of a page if you describe the shape you want. from firecrawl import Firecrawl app = Firecrawl ( api_key = " fc-... " ) doc = app . scrape ( " https://example.com/docs/getting-started " , formats = [ " markdown " ]) print ( doc . markdown

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

A deep dive on Go 1.24’s map redesign, where the runtime moved from the classic bucket + overflow-chain model to a Swiss Table-inspired implementation: how the old map layout worked and where pointer-chasing hurt cache locality how control-byte metadata + h2 filtering changes lookup behavior why this can improve practical load factor and memory efficiency Go-specific constraints (iteration semantics, GC/runtime integration, incremental growth behavior) benchmark context: large microbench wins vs smaller full-application geomean gains trade-offs still being worked on (cold-cache and certain delete/clear-heavy paths) submitted by /u/OtherwisePush6424 [link] [留言]

xAI has a bold pitch for Grok 4.5: it codes about as well as Claude Opus 4.8, but does it with roughly a quarter of the tokens. That's not a "we're smarter" claim. It's a "we're just as good for far less money" claim, which in 2026 might matter more. Someone actually put it to the test, so let me walk through what the numbers say and why you should care. The claim and the pricing Grok 4.5 landed on July 8, 2026. xAI says it matches Opus 4.8 on coding while using about 4.2 times fewer output tokens to get there. The sticker price already favors Grok. It runs $2 per million input tokens and $6 per million output. Opus sits at $5 and $25. That's less than half the price on both sides before you even factor in the token efficiency. Stack the two together and the cost gap gets dramatic. What the benchmarks say The benchmarks mostly support the marketing, with a catch. On Terminal-Bench 2.1, which measures real command-line work, Grok 4.5 scored 83.3 percent to Opus 4.8's 78.9. But on SWE-Bench Pro, the harder test of fixing real open-source bugs, Opus still comes out ahead. So the honest read is not "Grok is better." It's "Grok is about as good, for a lot less." Different claim, and a more interesting one. The hands-on test Benchmarks are one thing, real work is another. The New Stack ran a head-to-head, giving both models the same three jobs in one real Rust project (the fd file-finder) inside Cursor, and tracked every token. I'm summarizing their results here, credit to them for actually measuring it. The three tasks were a bug fix, a multi-file refactor, and a feature build. The code both models produced was nearly interchangeable, so the story came down to tokens, time, and cost. On the small bug fix, Opus actually won. Both wrote an identical fix with all tests passing, but Opus did it faster and on fewer tokens. Grok's efficiency edge showed up on the bigger jobs. On the refactor, Grok used about 197K tokens versus Opus's 954K for the same result, roughly a fifth.

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

I wrote a blog post about the myth of getting rid of developers submitted by /u/andychiare [link] [留言]

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

Back-of-the-envelope estimation for system design interviews Most people don't fail capacity math because the arithmetic is hard. They fail because they do it silently, produce a number they can't defend, and then never use it again for the rest of the interview. The math itself is trivial. The method is what's worth learning. Why interviewers ask Capacity estimation isn't a numeracy test. It's checking two things: Can you tell whether a design is physically possible before you commit to it? Do you know which constraint actually binds — storage, read throughput, write throughput, or bandwidth? A candidate who estimates 30,000 reads/sec and 200 writes/sec has learned something that changes the design. A candidate who computes petabytes of storage and then never mentions it again has just performed arithmetic. Round aggressively Precision is a trap. You're not producing a capacity plan; you're finding the order of magnitude. The single most useful substitution: 1 day = 86,400 seconds ≈ 10^5 seconds That's a 16% error and it makes every subsequent division doable in your head. Nobody will challenge it. Everyone will notice if you spend forty seconds long-dividing by 86,400. A few more worth having ready: 1 million requests/day ≈ 12/sec — round to 10 1 KB × 1 million = 1 GB 1 KB × 1 billion = 1 TB Peak traffic ≈ 2–3× average Replicated storage ≈ 3× raw ## Work in one direction Users → requests → QPS → storage → bandwidth. Don't jump around. Say each assumption out loud and label it as an assumption, so the interviewer can correct you early rather than watch you build on sand. A worked example Say we're designing a social feed. Given: 100M daily active users. Assumptions (stated, not smuggled in): Each user posts 0.2 times/day Each user reads their feed 10 times/day A post averages 1 KB including metadata A feed page shows 20 posts Writes 100M × 0.2 = 20M posts/day 20M / 10^5 = 200 writes/sec Peak (3×) = 600 writes/sec Reads 100M × 10 = 1B feed loads/day 1B / 10^5 = 10,0

"When you multiply 0588235294117647 by 2, 3, 4, 5, …, 16, the same sequence of digits appears in a cyclic order. That is, the digits remain the same but start from a different position, and when they reach the end, they continue again from the beginning." Would be useful for hash tables? or something else that needs rotations/permutations? looks like a reversible data transformation what if instead of 16 values (4 bits), we get a bigger number for 65536 values (16 bits) ChatGPT says it's related to a particular property of 17 (a prime number), but I want to know the opinion of actual programmers, mathematicians and engineers. Thanks submitted by /u/digital_n01se_ [link] [留言]

Eae gente bonita, beleza? Depois de um longo período, resolvi voltar aqui e continuar compartilhando...

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

We've been testing a new project this week. The project's origin story is a mess. Upper management...

TL;DR Croc GUI is a free desktop app for schollz/croc — encrypted peer-to-peer file transfer with drag-and-drop, QR codes (via getcroc.com ), and LAN mode. macOS, Windows, Linux. MIT licensed. Download: GitHub Releases Why I built this I send files with croc constantly. End-to-end encrypted, cross-platform, no vendor cloud. The CLI is perfect — until you're helping someone who doesn't have a terminal open. Croc GUI is the Send/Receive desktop app I wanted: same croc binary, clearer UX. What it does Send — drag files/folders, get a code phrase + QR link Receive — paste a code, pick a download folder Share — copy phrase, getcroc.com URL, or full croc … command Local-only — croc --local for LAN peers Zip — pack on send, unpack helper on receive Options — relay, port, proxy, overwrite, auto-confirm What it doesn't do Reimplement croc's crypto or protocol Upload anything to a GUI-specific cloud Claim to be an official schollz project Transfer engine: schollz/croc . Please sponsor schollz . Stack UI: React + TypeScript Shell: Tauri 2 (Rust) Engine: bundled croc binary per platform Dev quick start git clone https://github.com/interfluve-wav/croc-gui.git cd croc-gui/gui npm install npm run bundle:croc:download npm run tauri:dev Try it Platform Installer macOS (Apple Silicon) Croc_* (Apple Silicon).dmg macOS (Intel) Croc_*_x64.dmg Windows Croc_*_x64-setup.exe Linux .deb or .AppImage ⭐ Star on GitHub · 🐛 Issues