<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: Nezk</title><link>https://news.ycombinator.com/user?id=Nezk</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Fri, 18 Sep 2026 11:20:22 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=Nezk" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by Nezk in "Bend – A language that blocks AI mistakes via proof, on CPU and GPU"]]></title><description><![CDATA[
<p>And benchmarking this language against Isabelle/Agda/Lean/Rocq is strange. The time taken for those systems to perform their checks is mostly spent on elaboration, which includes unification against metavariables, typeclass resolution and tactics. Bend has none of that (there are no type classes or traits, and according to the README, everything must be fully annotated and <i>nothing</i> inferred). This means that the benchmark is comparing Bend's checker to the other systems' elaborators + kernels rather than their kernels (Agda doesn't have this separation though). The latter would be a fairer comparison, and in this area the other systems are already fast. Framing it as "outperforming every proof assistant" without that caveat is misleading.<p>There is also a problem with LAWS.bend. The typechecker only guarantees that your code satisfies what's written in LAWS.bend — not that LAWS.bend says what you actually meant. There is nothing to stop an LLM from "satisfying" a law with a vacuous or narrower-than-intended formalisation — the trust problem simply shifts from the code to the specification (which could be also generated by LLM, and therefore incorrect). The repository even admits that the compiler itself is 99% LLM generated and not yet fully audited, which seems a questionable basis on which to build a "mathematical guarantees" marketing.</p>
]]></description><pubDate>Fri, 18 Sep 2026 08:50:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=49751733</link><dc:creator>Nezk</dc:creator><comments>https://news.ycombinator.com/item?id=49751733</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49751733</guid></item><item><title><![CDATA[New comment by Nezk in "Bend – A language that blocks AI mistakes via proof, on CPU and GPU"]]></title><description><![CDATA[
<p>As I understand it, there are no implicit arguments (and, consequently, no unification) here, right? This doesn't seem very serious given the ambitions of a project like this. Of course, one could argue that it isn't necessary if everything is generated by a LLMs, but… why bother with "human-readable" Python-like syntax in that case? It's not Python, after all, and I don't think it would help with LLM code generation in any way.</p>
]]></description><pubDate>Fri, 18 Sep 2026 06:22:10 +0000</pubDate><link>https://news.ycombinator.com/item?id=49750750</link><dc:creator>Nezk</dc:creator><comments>https://news.ycombinator.com/item?id=49750750</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49750750</guid></item><item><title><![CDATA[New comment by Nezk in "I turned a $80 RK3562 Android tablet into a Debian Linux workstation"]]></title><description><![CDATA[
<p>Until a couple of months ago, I was using a Late 2013 MacBook Pro Retina with 4 GB of RAM as my main work computer (and I still use it as a secondary machine). It's amusing to read that some people can't imagine getting by with 4 GB of RAM on a device not meant for heavy work.</p>
]]></description><pubDate>Mon, 18 May 2026 03:36:16 +0000</pubDate><link>https://news.ycombinator.com/item?id=48175293</link><dc:creator>Nezk</dc:creator><comments>https://news.ycombinator.com/item?id=48175293</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48175293</guid></item></channel></rss>