Hacker News: keithasaurus

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

keithasaurus — Sun, 09 Aug 2026 21:57:43 +0000

It takes inspiration from Python, Rust, Go, and functional programming. It's oriented toward readability, safety, and speed.

I'm finishing up the journey of completely self-hosting. Then I'll be tidying it up for an initial release.

New comment by keithasaurus in "Ask HN: What Are You Working On? (July 2026)"

keithasaurus — Mon, 13 Jul 2026 03:42:32 +0000

https://blorp-lang.org

Taking a bit of a detour with self-hosting the language, now that the syntactic surface, standard library, and initial dependency strategy are on a decent footing.

With any luck, by the end of the week, I'll start prepping for a 0.0.1 release.

New comment by keithasaurus in "Blorp Language"

keithasaurus — Wed, 03 Jun 2026 03:41:05 +0000

The memory management model is automatic reference counting, with some optimizations, such as perseus for compile time reference counting where possible, and copy-on-write at runtime.

New comment by keithasaurus in "Blorp Language"

keithasaurus — Wed, 03 Jun 2026 03:36:32 +0000

I'm the creator of Blorp -- this made me chuckle a bit. I hadn't even considered that possibility.

New comment by keithasaurus in "Blorp Language"

keithasaurus — Wed, 03 Jun 2026 02:58:11 +0000

Yes, it's python-inspired. Some notable differences are: - no return keyword - match/if are expressions - it's functional - =? is used for early returns or binding, depending on the variant of an Option or Result that is returned

There's a lot of other differences -- it's a smaller language surface than Python overall.

New comment by keithasaurus in "Blorp Language"

keithasaurus — Wed, 03 Jun 2026 02:42:20 +0000

Yeah, this is the idea. This chaining is exactly the same as the pipeline operator in some some function languages, except that it hopefully reads in a more familiar way to programmers of non-functional languages.

New comment by keithasaurus in "Blorp Language"

keithasaurus — Wed, 03 Jun 2026 02:40:20 +0000

Yes, blorp does that. And it also allows local mutation and loops inside pure functions, so performance doesn't need to be left on the table in most cases.

New comment by keithasaurus in "Blorp Language"

keithasaurus — Wed, 03 Jun 2026 02:39:13 +0000

Hi, maintanier of blorp here. I think you mean that [1,2,3].map(func(x): x *2).filter(func(x): x > 5) would iterate twice, correct? Under the hood blorp optimizes that away for the functions we can. It constructs a loop and combines logic into a single iteration where possible.

Of course, blorp also allows local mutation in loops (even in pure functions, so long as the logic is contained to the function), so if there's a specific algorithm you'd rather express in a loop, you can.

New comment by keithasaurus in "Blorp Language"

keithasaurus — Wed, 03 Jun 2026 00:02:14 +0000

Hey - I'm the creator of Blorp, and like a lot of the ideas you have in Roc! Did you consider having opt-in purity? Or some other means of conveying impurity other than "!"?

New comment by keithasaurus in "Blorp Language"

keithasaurus — Tue, 02 Jun 2026 22:16:38 +0000

It's called blorp because it's the name of a stegosaurus my kids and I made up.

New comment by keithasaurus in "Blorp Language"

keithasaurus — Tue, 02 Jun 2026 22:15:03 +0000

Hey... I'm the maintainer and had no idea this was posted. The reason pure is required is because it's clear and opt-in. There's a CLI subcommand called purify that will help identify pure functions that haven't been deemed so if that's desired.

But there can be many (small) applications where pure doesn't even matter, so I don't really want to force someone to write "impure" for the main function, for example.

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

keithasaurus — Mon, 01 Jun 2026 03:28:03 +0000

Still incomplete there. But yeah performance should be decent. Not aiming for parity either rust or go entirely but in the same ball park is the expectation.

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!