Top all-time · #11950
Charlie Marsh
Personal blog · notes.crmarsh.comprogrammingsystems
Charlie Marsh's personal blog at notes.crmarsh.com covers programming and systems. Since 2022, 6 different Hacker News readers have linked it 8 times, most often “Python tooling could be much, much faster”. No feed was found, so read it on the site itself.
Too few sampled comments (2) to say how often HN recommends it.?
Why HN links it
The linked posts cover WebAssembly and whether it will get DOM support, and the Ruff Python linter written in Rust. The comments discuss container process overhead and Ruff's limitations, not the writing itself.
Summarised by Claude from a sample of 2 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Hi, I’m Charlie Marsh. I’m building Ruff, an extremely fast Python linter and code transformation toolchain written in Rust.
Most-linked posts?
- Python tooling could be much, much faster3 people · 3 mentions · first linked 2022-08-31
- Ruff: The First 200 Releases2 people · 2 mentions · first linked 2023-01-19
- Isolates, microVMs, and WebAssembly2 people · 2 mentions · first linked 2022-09-26
What Hacker News says?
> "Ah, but each container will run it's own separate runtime process." Sure, but the most valuable resource that probably wastes is a PID (and however many TIDs). Processes exec'ing the same program will share a .text and .rodata sections and the .data and .bss segments are COW'ed. In terms of memory footprint, I can allow that the OS may be smart enough to share a lot of the exec'ed process if it's run multiple tim…
Comment linking /isolates-microvms-and-webassembly
on “When Is WebAssembly Going to Get DOM Support?”Submitted Isolates, microVMs, and WebAssembly as a story · 123 points
HN discussionThanks, it's a fair comment :) I've tried to be honest about ruff's limitations: it supports only a small set of rules, it's not extensible in any way, it's missing edge-case handling, it's significantly under-tested compared to existing tools, etc. I don't consider it production-ready -- it's a proof-of-concept. (I _did_ try to build conviction that there weren't inherent reasons for ruff to slow down significantly…
Comment linking /python-tooling-could-be-much-much-faster
on “Ruff – a fast Python Linter written in Rust”Submitted Using Mypy in Production as a story · 116 points
HN discussionSubmitted Python tooling could be much, much faster as a story · 4 points
HN discussionSubmitted Ruff: The First 200 Releases as a story · 2 points
HN discussionSubmitted Python tooling could be much, much faster as a story · 2 points
HN discussionSubmitted Ruff: The First 200 Releases as a story · 1 points
HN discussion