Hacker News: taylorallred

New comment by taylorallred in "CJIT: C, Just in Time"

taylorallred — Tue, 28 Apr 2026 21:20:32 +0000

Pair this with Fil-C(https://fil-c.org/) and now you have C but as a truly bonafide scripting language.

New comment by taylorallred in "Two kinds of error"

taylorallred — Tue, 03 Mar 2026 21:34:54 +0000

Another interesting article on error handling: https://www.dgtlgrove.com/p/the-easiest-way-to-handle-errors

New comment by taylorallred in "Two kinds of error"

taylorallred — Tue, 03 Mar 2026 21:33:07 +0000

It makes me think that it's worth sitting down and considering what all the valid outcomes for a piece of functionality are. A user typing in a string in the wrong format is not necessarily "exceptional", whereas running out of memory while getting the input would be. I feel like programmers too often treat perfectly valid outcomes to be errors. For example, in Rust I'll see Option> and I ask myself if we could just use the empty vector as a valid return value.

New comment by taylorallred in "Farewell, Rust for web"

taylorallred — Thu, 19 Feb 2026 20:59:46 +0000

Rust shines in user-space systems-level applications (databases, cloud infrastructure, etc.) but definitely feels a bit out of place in more business-logic heavy applications.

New comment by taylorallred in "I Wrote a Scheme in 2025"

taylorallred — Thu, 12 Feb 2026 21:36:49 +0000

I was really interested in lisps for a couple of years, but eventually I came to the conclusions: it's just hard to read. I know they say "the parens disappear" but even if that is the case, it simply requires you to jump around the expression holding lots of context in your head. I'm a fan of code that mostly reads top-to-bottom, left-to-right.

New comment by taylorallred in "Parse, Don't Validate (2019)"

taylorallred — Tue, 10 Feb 2026 17:00:10 +0000

Not speaking for all Go programmers, but I think there is a lot of merit in the idea of "making zero a meaningful value". Zero Is Initialization (ZII) is a whole philosophy that uses this idea. Also, "nil-punning" in Clojure is worth looking at. Basically, if you make "zero" a valid state for all types (the number 0, an empty array, a null pointer) then you can avoid wrapping values in Option types and design your code for the case where a block of memory is initialized to zero or zeroed out.

New comment by taylorallred in "Tomo: A statically typed, imperative language that cross-compiles to C [video]"

taylorallred — Mon, 02 Feb 2026 21:02:08 +0000

I like the goals of this language a lot and I've wished something with these goals already existed. But, I'm not sure if this syntax/approach is quite what I want. Really cool project, though!

New comment by taylorallred in "Velox: A Port of Tauri to Swift by Miguel de Icaza"

taylorallred — Tue, 27 Jan 2026 17:51:20 +0000

I have always felt like Swift is the king of application development. The syntax and ergonomics really lend itself to UIs and the like. It's a shame that the Swift compiler is on the slow side.

New comment by taylorallred in "Improving the performance of WAT parser"

taylorallred — Tue, 20 Jan 2026 20:58:17 +0000

It seems to me like parser combinators are always more trouble than they're worth. People often have the impression that parsing is difficult and should be outsourced to another library, but often it's pretty simple to hand-roll and usually it makes faster code.

New comment by taylorallred in "“Stop Designing Languages. Write Libraries Instead” (2016)"

taylorallred — Wed, 07 Jan 2026 16:00:44 +0000

I agree with the sentiment of this article but the question that fascinates me is "when do you need a language feature instead of a library in order to accomplish X, Y, or Z?"

New comment by taylorallred in "4 billion if statements (2023)"

taylorallred — Fri, 12 Dec 2025 18:26:08 +0000

Meanwhile:

    not     eax
    and     eax, 1

New comment by taylorallred in "Response to "Ruby Is Not a Serious Programming Language""

taylorallred — Mon, 01 Dec 2025 19:37:39 +0000

I see people waxing poetic over Ruby a lot saying that it's a language "built for the human". The thing is, every language is built for humans (or at least should be) but we tend to have different definitions for what "built for humans" means. Ruby certainly has some clean and expressive syntax, but I personally find it difficult to use because of its dynamic typing (which makes it hard to know what the types are while I'm writing it) and the heavy use of macros and other magic (which does unknown operations without my knowledge and introduces symbols into the scope mysteriously). That said, it clearly works great for some humans, just not for this human (me).

New comment by taylorallred in "Zig and the design choices within"

taylorallred — Mon, 10 Nov 2025 17:44:12 +0000

I have admired many parts of Zig and its philosophy but I've never seen it as a language that I want to use. What I've noticed is that Zig users care most about explicitness, simplicity, and minimal indirection. This leads to a lot of syntax that is cumbersome to read (albeit unambiguous) like casting and a lack of "convenience" features. I can't help but think that maybe they're right and that this philosophy probably leads to better software because nothing is "hidden". But, I also think that there's a level of abstraction/indirection that makes code clearer and less error-prone. It's a tricky balance to achieve, and past languages have succeeded and failed at it to different degrees. Either way, I echo the OP's sentiment: if Zig is your jam, great, go make some awesome stuff with it. It's just not my go-to today.

New comment by taylorallred in "Garbage collection for Rust: The finalizer frontier"

taylorallred — Fri, 17 Oct 2025 17:57:13 +0000

Thanks for those links. Have you tried using arenas that give out handles (sometimes indexes) instead of mutable references? It's less convenient and you're not leveraging borrow checking but I would imagine it supports Send well.

New comment by taylorallred in "Garbage collection for Rust: The finalizer frontier"

taylorallred — Wed, 15 Oct 2025 15:52:31 +0000

For those who are interested, I think that arena allocation is an underrated approach to managing lifetimes of interconnected objects that works well with borrow checking.

New comment by taylorallred in "Working pipe operator today in pure JavaScript"

taylorallred — Wed, 08 Oct 2025 22:01:42 +0000

Piping syntax is nice for reading, but it's hard to debug. There's no clear way to "step through" each stage of the pipe to see the intermediate results.

New comment by taylorallred in "Imagining a language without booleans"

taylorallred — Tue, 23 Sep 2025 19:36:14 +0000

I love seeing these kinds of explorations in the realm of language design. I've wondered about expanding the notion of boolean operators like this. For all its flaws, one thing I've always liked about JS is the overloaded (||) and (&&) operators. It's really slick to write something like `foo.get_that_can_fail(x) || "default value"`.

New comment by taylorallred in "React is winning by default and slowing innovation"

taylorallred — Tue, 16 Sep 2025 17:14:52 +0000

I'm less concerned about people not adopting other frameworks. I'm concerned about people not knowing/learning the fundamentals of how websites work. It's apparent in job interviews that developers from bootcamps are only learning how to make sites/apps with React and don't know the fundamentals that support it.

New comment by taylorallred in "JetBrains working on higher-abstraction programming language"

taylorallred — Thu, 14 Aug 2025 17:52:30 +0000

"So-called "natural language" is wonderful for the purposes it was created for, such as to be rude in, to tell jokes in, to cheat or to make love in (and Theorists of Literary Criticism can even be content-free in it), but it is hopelessly inadequate when we have to deal unambiguously with situations of great intricacy, situations which unavoidably arise in such activities as legislation, arbitration, mathematics or programming." -Dijkstra

New comment by taylorallred in "Design patterns you should unlearn in Python"

taylorallred — Fri, 01 Aug 2025 17:04:20 +0000

I really appreciate how this article explains why certain design patterns became a thing. Usually, it was to address some very practical problem or limitation. And yet, a lot of younger programmers treat these patterns like a religious dogma that they must follow and don't question if they really make sense for the specific situation they are in.