Hacker News: keithasaurus

New comment by keithasaurus in "Zig ELF Linker Improvements Devlog"

keithasaurus — Sun, 31 May 2026 14:36:39 +0000

Yeah, no shared mutable memory; coordination is done via channels.

New comment by keithasaurus in "Zig ELF Linker Improvements Devlog"

keithasaurus — Sun, 31 May 2026 07:08:45 +0000

How is compiling to zig? I considered doing it but chose C instead because of how much zig is still changing. I've considered using it's C compiler for targeting multiple platforms locally.

New comment by keithasaurus in "Zig ELF Linker Improvements Devlog"

keithasaurus — Sun, 31 May 2026 06:51:17 +0000

No, blorp doesn't use affine types (one or zero uses). In blorp, ownership is not explicitly controlled by users at all, so it's opaque. Under the hood, it's perceus for compile-time ownership and borrowing and automatic reference counting with copy-on-write optimizations for the runtime. This is made reasonably easy for the compiler to reason about in blorp because semantically it doesn't _really_ have in-place mutation -- `var` really means "re-bindable" to a new value; and then under the hood we'll mutate in place where we can.

New comment by keithasaurus in "Zig ELF Linker Improvements Devlog"

keithasaurus — Sat, 30 May 2026 23:54:07 +0000

I have some similar goals. Have you considered leaning more into inference than gradual typing? One pattern I like is allowing the compiler to develop a more complex mental model, but keeping it straightforward for users -- you can do that with inference, ownership, purity, effect types, etc. What I actually think is really tantalizing is using tooling to fill in some of those gaps -- for instance, the editor could know types, required capabilities etc, without the user ever needing to type anything, but when the user needs it, they can find it, query it, test against it.

New comment by keithasaurus in "Zig ELF Linker Improvements Devlog"

keithasaurus — Sat, 30 May 2026 23:32:57 +0000

Yeah, concurrency in blorp doesn't allow shared mutable references, so deadlocks aren't really a concern. Otherwise it's meant to be simple-ish -- virtual threads, channels, no async/await. Pure functions allow safe parallelism naturally, so that's fairly straightforward, though the API is still incomplete, for example the "Parallel" section here: https://blorp-lang.org/docs/lists/. It's still under heavy development (working on it right now).

What are the over-arching goals of your language?

New comment by keithasaurus in "Zig ELF Linker Improvements Devlog"

keithasaurus — Sat, 30 May 2026 22:03:48 +0000

Working on something kinda similar. No GC, Python feel, managed memory, performance approaching C. It's here: https://blorp-lang.org if you want to compare approaches.

New comment by keithasaurus in "Ask HN: What are you working on? (September 2025)"

keithasaurus — Tue, 30 Sep 2025 03:44:06 +0000

It's not the core of koda-validate, and yeah lots of libraries have a similar capacity. Feedback I'd be interested in is if there are gaps.

In general the value prop of koda-validate is that it turns validation into typesafe building blocks, which makes validators very re-usable -- and flexible. Some other notable differences from pydantic are that it doesn't `raise` on validation errors, you don't need a typing plugin, and it's fully asyncio-compatible.

New comment by keithasaurus in "Ask HN: What are you working on? (September 2025)"

keithasaurus — Tue, 30 Sep 2025 02:24:58 +0000

Updating my validation library for python, koda-validate (https://github.com/keithasaurus/koda-validate).

Focusing on ergonomics improvements. Just released an improvement to the __repr__ for Invalid types.

Potentially working on expanding the ability to generate validators from arbitrary typehints, ie `get_typehint_validator(list[str | int])`. It has good coverage, but I suspect I'm blind to some obvious holes. Would love feedback!

New comment by keithasaurus in "Public static void main(String[] args) is dead"

keithasaurus — Tue, 16 Sep 2025 05:46:12 +0000

could java please also learn that stand-alone functions are cleaner than static methods? even if it's just syntax sugar...

Ask HN: What makes a programming language great for code generation?

keithasaurus — Thu, 22 May 2025 16:54:13 +0000

At the moment, it seems programming language popularity might be the best indicator of whether an LLM will be proficient at generating working code (e.g. Python, JavaScript, Java, C). However, it seems plausible to me that languages which require the least amount of extra reasoning (and/or tokens?) could allow LLMs to produce working code more often. For instance, I would imagine immutability to be easier for an LLM to "reason" about than local mutability. The same could be said for strict formatting, explicit types, concise syntax, etc. By that reasoning I might expect functional languages to be particularly good targets.

Is there any evidence supporting these ideas? Should there be (or are there already) languages developed with LLMs in mind? Will we see developers pushed more toward languages that LLMs are more proficient at?

Comments URL: https://news.ycombinator.com/item?id=44063967

Points: 3

# Comments: 3

New comment by keithasaurus in "Static Types Are for Perfectionists"

keithasaurus — Mon, 19 May 2025 17:17:59 +0000

For me the variation is one of the places where dynamic typing gets really dangerous, because as variations increase, the requirement for code archaeology does as well. At some point there is enough variation that nobody could reasonably be expected to do enough code exploration to understand the full breadth of that variation.

With types, the scope of the variation is clearly stated, and if you want to expand the variation, it should be clear how to do so, depending on the flavor (e.g. union types, sum types, generics, sub types).

New comment by keithasaurus in "Static Types Are for Perfectionists"

keithasaurus — Mon, 19 May 2025 16:46:28 +0000

static types: here's what this piece of data is

dynamic types: go look through code, tests, comments and project history to try figure out what this data is supposed to be

dynamic types are exhausting

New comment by keithasaurus in "Htmy – Async, pure-Python rendering engine"

keithasaurus — Wed, 27 Nov 2024 05:15:49 +0000

There's a bunch of these kinds of html renderers. Here's mine: https://pypi.org/project/simple-html/

But there are many others. Not sure I understand the point of async rendering, unless you want to mix IO with rendering? Which feels a bit too close to old PHP+html for my blood.

New comment by keithasaurus in "Leonard Cohen: The Man Who Saw the Angels Fall"

keithasaurus — Thu, 19 Sep 2024 19:18:12 +0000

I learned about Leonard Cohen by watching the movie McCabe and Mrs Miller. Recommended.

New comment by keithasaurus in "Descent: A classic 3-D first-person shooter (2012)"

keithasaurus — Fri, 12 Apr 2024 15:58:25 +0000

Don't remember that -- not even sure at the time I would have realized it was a business? I can imagine some version of that taking off in the mid 90s. Would've beat Descent on my Pentium.

New comment by keithasaurus in "Descent: A classic 3-D first-person shooter (2012)"

keithasaurus — Fri, 12 Apr 2024 05:06:56 +0000

Wild to see a Jackson Crossing reference on Hacker News. Haven't been there since around the time you would've had your business, but I don't think I remember an arcade like that. What was it called?

New comment by keithasaurus in "Mypy 1.6"

keithasaurus — Tue, 17 Oct 2023 15:33:40 +0000

mypy is essentially the reference implementation. pyright probably is better as a type checker, but, for the referential aspect alone, I suspect many libraries will continue targeting mypy.

One potential benefit of mypy is that it comes with mypyc, a compiler that leverages mypy's evaluation of types. Since pyright and mypyc are not exactly equal, it makes sense to use mypy if you want to use mypyc.

New comment by keithasaurus in "Show HN: Non.io, a Reddit-like platform Ive been working on for the last 4 years"

keithasaurus — Mon, 12 Jun 2023 17:52:40 +0000

A few quick suggestions about the landing page: - less text - more spacing in your text - try not to let your text span the entire width of the window

New comment by keithasaurus in "Agile soccer skills for a bipedal robot with deep reinforcement learning"

keithasaurus — Thu, 04 May 2023 03:36:58 +0000

Isn't this what we have sports for? I think what your describing would basically be a robot team sport.

New comment by keithasaurus in "Pydantic V2 leverages Rust's Superpowers [video]"

keithasaurus — Sun, 23 Apr 2023 18:32:20 +0000

Definitely true. I've just soured on the POV that native code is the first thing one should reach for. I was surprised that it only took a few days of optimizations to convert my validation library to being significantly faster than pydantic, when pydantic as already largely compiled via cython.

If you're interested in both efficiency and maintainability, I think you need to start by optimizing the language of origin. It seems to me that with pydantic, the choice has consistently been to jump to compilation (cython, now rust) without much attempt at optimizing within Python.

I'm not super-familiar with how things are being done on an issue-to-issue / line-to-line basis, but I see this rust effort taking something like a year+, when my intuition is some simpler speedups in python could have been in a matter of days or weeks (which is not to say they would be of the same magnitude of performance gains).