Hacker News: ameliaquining

New comment by ameliaquining in "Clojure Hosted on Go"

ameliaquining — Thu, 18 Jun 2026 02:46:51 +0000

Judging by the changelogs in the releases section, there haven't been radical changes, just incremental improvements.

New comment by ameliaquining in "Pentagon boasts of using AI to write reports mandated by Congress (1.5mil users)"

ameliaquining — Wed, 17 Jun 2026 19:21:35 +0000

I read that prediction as being about using AI for mission-critical stuff, which this isn't really.

New comment by ameliaquining in "Why stdx is not on crates.io"

ameliaquining — Wed, 17 Jun 2026 17:03:36 +0000

This is mostly only true if you're writing a network service or maybe a CLI tool. Which is fair enough, since that's what Go is primarily for, but Rust aims to be, not just usable, but the best option, in a broader variety of domains. It wouldn't be feasible to have a batteries-included stdlib for all of them. (Python historically tried, and the results have been rather famously unsatisfactory.)

Also, even network services benefit from things like OpenAPI for type safety, and you don't get that from the Go stdlib.

New comment by ameliaquining in "There Is(Ǝ) – Such That (∋)"

ameliaquining — Mon, 15 Jun 2026 14:16:07 +0000

Pangram says human-written. It does have some stylistic quirks often associated with LLMs, but those aren't a reliable indicator.

New comment by ameliaquining in "Your ePub Is Fine. Kobo Disagrees. Blame Adobe"

ameliaquining — Mon, 15 Jun 2026 02:55:39 +0000

A compatibility linter is a poor substitute for a vendor-supplied test platform, but if the vendor is uncooperative it may be the best that can be done.

New comment by ameliaquining in "Your ePub Is fine"

ameliaquining — Mon, 15 Jun 2026 02:51:57 +0000

If a large fraction of your users are on IE6 and you can't realistically get them off it, you need to make sure your site works in IE6, and good tooling should help you do this. Of course you also want to make sure it works in other browsers your users use, and a standard may be helpful in doing that.

New comment by ameliaquining in "Lisp's Influence on Ruby"

ameliaquining — Mon, 15 Jun 2026 01:21:45 +0000

Yes, a Rust procedural macro is a function that takes a Rust syntax tree as an argument and returns a Rust syntax tree. When you use it, the compiler compiles it (for the host architecture), dynamically loads it into the compiler process, calls it, and inserts the output into the code to be compiled. https://doc.rust-lang.org/book/ch20-05-macros.html#procedura...

I don't see why this would inhibit optimization, unless you mean it slows down compilation, in which case, yep, that's a real and rather notorious downside.

New comment by ameliaquining in "Your ePub Is fine"

ameliaquining — Mon, 15 Jun 2026 00:52:51 +0000

The latter seems like what the tool's users actually want. That it's a harder problem doesn't change that.

New comment by ameliaquining in "Lisp's Influence on Ruby"

ameliaquining — Mon, 15 Jun 2026 00:47:21 +0000

C macros are definitely much weaker; they're not by themselves Turing-complete (except maybe with vendor-specific extensions? I'm not an expert here). Rust has both macros by example (precisely analogous to Scheme macros, and equal in power) and procedural macros (conceptually analogous to Common Lisp macros, allowing arbitrary code at macro evaluation time, but I don't know enough about Common Lisp to say whether there are differences in power).

New comment by ameliaquining in "Your ePub Is fine"

ameliaquining — Mon, 15 Jun 2026 00:41:19 +0000

The problem is that, while there's no theoretical barrier to an authoring tool with a Director-like user experience that exports to Wasm, no one has actually written one, and it's not a small amount of work.

(I agree that we're better off without Flash, but this particular problem is real and unsolved.)

New comment by ameliaquining in "Lisp's Influence on Ruby"

ameliaquining — Sun, 14 Jun 2026 22:32:01 +0000

Homoiconicity makes macros slightly more syntactically elegant, but is not at all necessary. Rust has macros and isn't homoiconic at all.

New comment by ameliaquining in "Python 3.14 garbage collection rigamarole"

ameliaquining — Sun, 14 Jun 2026 21:03:30 +0000

In Pyodide's new versioning scheme, the major version is the concatenated major and minor versions of the corresponding Python release. Pyodide 314 is based on Python 3.14 (which is just the fifteenth minor version of Python 3, counting from zero, and just happens to match the common approximation of pi).

New comment by ameliaquining in "Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI"

ameliaquining — Sun, 14 Jun 2026 20:43:49 +0000

I'm familiar with that post. However, it doesn't include a convincing argument that a CFG interchange format wouldn't have performance costs for Wasm runtimes; it just handwavingly asserts this. It blames Google because Google is a popular villain, but the other three browser vendors (this was before Edge adopted Chromium), all of which initially used different Wasm runtime architectures from Google and from one another, were also in favor of structured control flow, and I assume they knew what they were talking about. Once you get past the conspiracy theory, it's clear that the real issue is just that the author disagrees with the Wasm committee's decision to trade off convenience for compiler writers in order to make things work better for runtimes.

More to the point, none of this has anything to do with ABI.

New comment by ameliaquining in "Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI"

ameliaquining — Sun, 14 Jun 2026 03:34:27 +0000

I don't think the controversy about Wasm's structured control flow has anything to do with any of this? It's not actually difficult to target Wasm in codegen; I've never heard of any real-world compiler project complaining that this was a major burden. ABI concerns are at a different level.

Most low-level IRs don't do structured control flow because most low-level IRs don't need to be translatable to verified-safe machine code in a single fast pass, whereas for WebAssembly that's a core design requirement.

New comment by ameliaquining in "Python 3.14 garbage collection rigamarole"

ameliaquining — Sun, 14 Jun 2026 03:16:59 +0000

It's better in some ways (order-of-magnitude reductions in pause times were cited) but worse in other ways (higher peak memory usage). That the higher peak memory usage was catastrophic for some users only became apparent through post-release feedback.

New comment by ameliaquining in "There Is Life Before Main in Rust"

ameliaquining — Sat, 13 Jun 2026 02:15:33 +0000

Yeah, I think of avoiding the call from main as a devex consideration rather than a performance one, since either way the initialization code runs once at process startup.

New comment by ameliaquining in "There Is Life Before Main in Rust"

ameliaquining — Sat, 13 Jun 2026 02:09:22 +0000

I think these things are used more for developer experience than for performance, since you can always just do the initialization in main if you really have to.

New comment by ameliaquining in "There Is Life Before Main in Rust"

ameliaquining — Fri, 12 Jun 2026 22:43:11 +0000

The relevance to Rust is precisely that it doesn't have life before main at the language level; therefore, if you need it*, you need to use these kinds of linker hacks (which fortunately are amenable to encapsulation through macros). By contrast, if the article were about C++, the focus would be on "what happens under the hood when you use static initialization, in case you were curious" rather than "how to use these low-level mechanisms to do something not otherwise possible".

* Which you should think very carefully before concluding is the case, as it's responsible for rather a lot of bugs in C++. I think in Rust it is mostly used for registry-pattern type stuff since the const system can't currently(?) handle that.

New comment by ameliaquining in "Port React Compiler to Rust"

ameliaquining — Wed, 10 Jun 2026 12:47:11 +0000

Next.js supports React Compiler: https://nextjs.org/docs/app/api-reference/config/next-config...

New comment by ameliaquining in "Do we fear the serializable isolation level more than we fear subtle bugs (2024)"

ameliaquining — Mon, 08 Jun 2026 01:42:40 +0000

I think the argument is that thinking through the exact implications of your particular database's concurrency model for each query you write is too much to ask of generalist software engineers; if it's not kept down to a small auditable surface, mistakes will occur pervasively. Therefore, serializable (i.e., do it the obvious way without allowing tricky edge-case states) should be the default, and should be departed from only when performance demands it in a specific case, with careful analysis in those few cases to ensure correctness. (This is pretty closely analogous to the argument for memory-safe programming languages.)

The one complication is that this does mean applications need to be prepared for queries to need to be retried, and while this is reasonably straightforward in most cases (and can in principle be enforced with static analysis), it's not always done today, which makes it hard to change the defaults.