Modern NewsTopAskShowBestNew

Show

    Show HN: Building a web server in assembly to give my life (a lack of) meaning

    by imtomt · about 8 hours ago

    This is ymawky, a static file web server for MacOS written entirely in ARM64 assembly. It supports GET, PUT, DELETE, HEAD, and OPTIONS requests, and supports Range: bytes=X-Y headers (which allows scrubbing for video streaming). It decodes percent-encoded URLs, strictly enforces docroot, serves custom error pages for any HTTP error response, supports directory listing, and has (some) mitigations against slowloris-like attacks.

    I’ve also written a more detailed writeup here: https://imtomt.github.io/ymawky/

    297|github.com|139 comments

    Show HN: I made a Clojure-like language in Go, boots in 7ms

    by marcingas · about 17 hours ago

    Let-go is a Clojure-like language (~90% compatible with JVM Clojure) written in pure Go. It ships as a ~10MB static binary and cold boots in ~7ms - that's about 50x faster than JVM and 3x faster than Babashka. It has decent throughput on algorithmic workloads - within ballpark of the GraalVM-backed sci.

    I started this project in 2021 as an elaborate practical joke: I wanted to have an excuse for writing Clojure while pretending to write Go.

    Jokes aside, it turned out to be pretty decent: it feels like real Clojure, it has an nREPL server (supported in Calva, CIDER, etc.), it's easily embeddable in your Go programs (funcs, structs and channels cross the boundary without fuss). It's good for writing CLIs, web servers, data processing scripts and even doing some systems programming - I used it to write a deamonless container runtime. Oh, and it runs on Plan9.

    Under the hood there is a fairly simple compiler and a stack VM, both handcrafted specifically for running Clojure-like code. The compiler can work in AOT mode producing portable bytecode blobs and standalone binaries (runtime+bytecode).

    This is not a drop-in replacement for Clojure in general - it does not load JARs, it does not have all Java APIs and it most probably won't run your exiting Clojure projects without modifications. At least not at the moment.

    Take it for a spin, tell me what you think. Issues and PRs are welcome!

    182|github.com|50 comments

    Show HN: Akmon, a Rust AI coding agent for regulated engineering

    by radotsvetkov · about 1 hour ago

    3|github.com|0 comments

    Show HN: Rust but Lisp

    by thatxliner · about 14 hours ago

    137|github.com|68 comments

    Show HN: ASCII pixel art editor for the terminal

    by doctor_schultz · about 1 hour ago

    feast your eyes

    5|github.com|2 comments

    Show HN: Countries where you can leave your MacBook at a random coffee shop

    by canergl · about 12 hours ago

    Hi HN,

    I wanted to know which countries you can simply leave your laptop at a Starbucks, and where you can't.

    Feel free to click and vote.

    30|vouchatlas.com|28 comments

    Show HN: Free Google Places API alternative using OpenStreetMap (no API key)

    by johnleslie_pm · about 4 hours ago

    6|bizdata-web.vercel.app|1 comments

    Show HN: Modafinil - Let agents continue running while MacBook lid is closed

    by hamza_q_ · about 8 hours ago

    8|github.com|11 comments

    Show HN: Mochi.js: bun-native high-fidelity browser automation library

    by ccheshirecat · about 21 hours ago

    Hi HN,

    I’m sharing mochi.js (https://github.com/0xchasercat/mochi), a Bun-native, raw-CDP browser automation framework. It's designed to make programmatic browser use more effective by focusing on consistency and measured parity with regular traffic, purely from the JS layer, against stock Chromium.

    The most common forms of browser automation focus heavily on client-side line by line probes, which are mostly cosmetic. This makes people feel better but it doesn't have much relevance to actual WAF or anti-automation defences.

    Mochi.js focuses on what actually matters, allowing you to get past captchas, WAF's and most defence mechanisms. In fact, in some cases it actually outperforms chromium forks simply by virtue of not having to lie.

    The foundation is built on a probe manifest based on analyzing several WAF's and trying to cover most of the ground that matters, and from there building upwards while ensuring every decision is backed by data. Solves turnstile/interstitial automatically, single digit fpjs suspect score, very good client-side results, though browserscan and a few others are known limitations that are fundamentally conflicting with what WAF's probe for.

    I'll be here if anyone wants to discuss the details, check out the docs and github. It's completely free and open source, MIT, strictly no relationship to any proprietary products whatsoever. No affiliation to patched chromium forks, or SaaS.

    But I also want to talk about why I built this, because the current paradigm of "bot detection" is fundamentally broken.

    Traditionally they would probably try to label my repository a malicious tool, or at best, a grey hat one.

    Let's take Turnstile for example, If you attach a debugger to see what data they are extracting from your hardware, their script intentionally self-destructs. When they try to extract your data—acting as a guest on your silicon, using your electricity, without asking, the industry calls it "Security."

    But if you write a script to control exactly what data your own hardware emits, refusing to provide the data they have no right to ask for, you are suddenly labeled a "Malicious Actor" engaged in "Bot Evasion."

    I find it absurd we let ourselves put up with this, and the stance of the bot-evasion community only makes them feel more able to take a higher moral ground.

    I have built a library that respects my hardware's reality. If that breaks your security model, that's because your security model relies on trespassing and secrecy. I stopped apologizing. Who's next?

    Mochi is the exact opposite of WAF opacity. It is a glass box. It is MIT-licensed. The entire DAG, fingerprint manifest schema, harvesting process, is documented. We even commit our live benchmarks to the public record (mochi on a Linux datacenter IP scored a suspect_score: 8 and bot: not_detected against FingerprintJS Pro v4).

    We don't even lie unnecessarily. We default to host-OS matching. If you run mochi on a Linux server, it uses privacy-sensible fingerprints for Linux, not Windows, because Linux is a real-user signal. It proves that WAFs aren't actually blocking what most people think they are, which begs the question of what they are really doing in that obfuscated payload.

    The legitimacy argument is exactly how they captured the narrative. And nobody challenged it because the people on the other side were too busy acting like they were doing something wrong.

    Is this a conspiracy theory? For sure, but only because they allow it to be. Try make a conspiracy theory about the sticky riceball.

    41|mochijs.com|19 comments

    Show HN: Create flashcards with Space CLI

    by friebetill · about 21 hours ago

    Hey, I created seven years ago a flashcard app with a main focus on UX. In the last months I added offline-first mode and a CLI that allows Claude Code or Codex to create high quality flashcards for you. I use that to learn about pharma rules, technology, dancing, taxes and smart home. Never really did marketing, this not my specialty. Would love to know what you think

    20|getspace.app|7 comments