<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: vshulcz</title><link>https://news.ycombinator.com/user?id=vshulcz</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Thu, 25 Jun 2026 21:26:02 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=vshulcz" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by vshulcz in "Show HN: Nimic – Pure Python as a systems language with AOT compilation"]]></title><description><![CDATA[
<p>the variant-types-for-dispatch thing is a nice tradeoff, makes sense. honestly the strongest pitch in there is the "write the hot module in nimic instead of dropping to c/rust/cython" angle, which is basically the cython niche. so the question is what nimic adds over cython for that. my guess is dual-mode: a .pyx isn't valid python and won't run under plain cpython, but nimic stays importable and debuggable in cpython and you compile only when you want speed. if that's the edge i'd put it front and center, it's a way sharper sell than "python but fast".<p>one thing i'd worry about with "runs unmodified in cpython" though: python ints are arbitrary precision and nim's aren't. so the same code can give you a bignum under cpython and a wraparound under the compiled path. how do you handle that, or is matching cpython semantics explicitly a non-goal for the typed subset?</p>
]]></description><pubDate>Thu, 25 Jun 2026 10:41:20 +0000</pubDate><link>https://news.ycombinator.com/item?id=48671561</link><dc:creator>vshulcz</dc:creator><comments>https://news.ycombinator.com/item?id=48671561</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48671561</guid></item><item><title><![CDATA[New comment by vshulcz in "Show HN: Nimic – Pure Python as a systems language with AOT compilation"]]></title><description><![CDATA[
<p>The line I'd push on is "valid Python that runs unmodified in CPython." True at the syntax level, but the speedup isn't really coming from Nim as a backend, it comes from how much of Python's dynamism you can pin down at compile time. Refcounting semantics, __getattr__, values that change type at runtime, isinstance-based dispatch, monkeypatching in tests: the moment you statically commit to any of those, you've defined a subset, and the subset is the actual product, not the transpiler.<p>I've spent a fair bit of time generating specialized straight-line code for hot Python paths, killing the per-call attribute and dict lookups the interpreter does. The lesson was that dispatch-bound code claws back most of its overhead without ever leaving CPython. Where AOT-to-native actually pulls ahead is numeric and loop-bound work, where the interpreter loop and boxing dominate. Your 512x288 render is exactly that case, which is why it looks so strong.<p>So the benchmark I'd want isn't render time, it's what fraction of a real module transpiles with no rewrites. That number tells me whether this is a systems language or a fast path I have to hand-shape around. Codon and Shedskin both hit that wall. Curious where Nimic draws the line.</p>
]]></description><pubDate>Thu, 25 Jun 2026 09:35:07 +0000</pubDate><link>https://news.ycombinator.com/item?id=48671108</link><dc:creator>vshulcz</dc:creator><comments>https://news.ycombinator.com/item?id=48671108</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48671108</guid></item><item><title><![CDATA[New comment by vshulcz in "The new HTTP QUERY method explained"]]></title><description><![CDATA[
<p>Even past the TLS point (CDNs terminate TLS, so they can read the body) there's a harder problem nobody's solved: to cache a QUERY the cache has to fold the body into the cache key, and there's no standard way to canonicalize a request body. {"a":1,"b":2} and {"b":2,"a":1} are the same query and two different cache entries; whitespace, float formatting, unordered keys all fork the key. GET gets this for free because the URL is already a normalized string. So "cacheable in principle" is real, but "actually cached" needs every layer to agree on a canonical form first - the same coordination problem that killed GET-with-body. I want QUERY for the honest semantics; I just wouldn't budget for cache hits yet</p>
]]></description><pubDate>Tue, 23 Jun 2026 11:22:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=48643317</link><dc:creator>vshulcz</dc:creator><comments>https://news.ycombinator.com/item?id=48643317</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48643317</guid></item></channel></rss>