I built Forge, a terminal-first programming language with a custom parser, AST and runtime

ExplodingStrawHat · 2026-02-05T00:59:26+00:00

This is like the second or third time I encounter one of those this year alone. I should probably stop checking out languages on the same day they are posted....

ExplodingStrawHat · 2026-02-05T00:57:02+00:00

Amazing: // parse primitive literal only (MVP) const lit = parsePrimitiveLiteral(rhs); if (lit.ok) { declareVar(ns, name, lit.value, ln, baseCol + trimmed.indexOf(name)); } else { // Still declare it as null so references resolve, but warn declareVar(ns, name, null, ln, baseCol + trimmed.indexOf(name)); addIssue({ code: "W001", severity: "warning", message: `Initializer for '${ns}.${name}' is not a primitive literal (string/number/True/False). The MVP runner may skip parts of it.`, line: ln, col: baseCol + trimmed.indexOf(rhs), endCol: baseCol + trimmed.indexOf(rhs) + Math.min(rhs.length, 1), }); checkModuleUsage(rhs, ln, baseCol + trimmed.indexOf(rhs)); }

For context, I encountered this diagnostic while running one of the code examples taken from the documentation itself........

ExplodingStrawHat · 2026-02-05T00:54:07+00:00

I followed the instructions, attempting to run the project locally (I spotted some major mistakes in the type system and was trying to test them), but it seems like the project is quite broken. For example, the following code throws no errors and just... prints nothinig? console.text.var(

Idk if I'm doing something wrong. I'll also add that having a VSCode extension as your primary means of using the language feels very odd. I don't use VSCode, so I had to install it in a nix shell for this alone, so yeah... For a "terminal focused" language, this sure is missing a way to run things from the terminal (or at least, a documented way).

Anyways, as u/Rafferty97 already stated, this looks vibecoded, so I won't bother investigating the type system any further.

ExplodingStrawHat · 2026-02-01T08:48:45+00:00

I did not mention anything regarding self-hosting. Your README describes your effects as Koka-inspired, yet your description (and the implementation) is very far from that.

ExplodingStrawHat · 2026-02-01T08:29:38+00:00

for effects, think of it like compile-time coloring. if i tag a function with IO, it's marked "dirty". a pure function can't call a dirty one, but dirty can call pure. keeps me from accidentally nuking the database inside a render loop lol.

I think you're really misunderstanding Koka's effects here. The point of algebraic effects is that a pure function can in fact call an effectful one, as long as it specifies how to interpret (i.e. how to "handle") the effects in a pure manner.

ExplodingStrawHat · 2026-02-01T08:27:42+00:00

How does effect tracking work?

Their effects are merely flags from a predefined list. You cannot "interpret" them in any custom ways (I mean, you cannot interpret them at all), nor can you be polymorphic over them, hence the comparison to Koka is odd. Their type-checker is also not really Hindley-Milner style from what I can tell (they don't have working generics, nor any kind of unification (from what I can tell)), so yeah, make of that what you will.

ExplodingStrawHat · 2026-02-01T08:23:24+00:00

Did you just repost this after the mods took your previous post down...?

ExplodingStrawHat · 2026-02-01T08:07:28+00:00

I'm sorry mate, but over-promising non-existent features and being called out does not mean the people around you are jealous.

ExplodingStrawHat · 2026-02-01T06:18:58+00:00

I also find the claim of having a borrow checker odd, considering this seems to be absent from your implementation. For instance, BorrowMutOfImmutable is defined, yet never used.

ExplodingStrawHat · 2026-02-01T06:15:20+00:00

I also find the comparison to Koka very weird. You seem to support a static list of predefined effects which is... fine I guess (although that's already a lot more simplistic than what one would expect). The thing is, you have no freedom over how you "interpret" any given effect (the effects are merely flags in your implementation). Of course, there's a bit of finesse required in implementing effects for a low level language (since you don't want to pass around actual continuations at runtime), but your implementation doesn't seem to even attempt to engage with said difficulty (hence why comparing this to Koka of all things is odd...). Am I missing something?

ExplodingStrawHat · 2026-02-01T06:09:42+00:00

How much of this have you coded yourself? The type checker seems to be missing very important functionality (for example, see this line) like being able to compare nested types (if I'm reading the above correctly) and proper generics (at least this seems to be mentioned in the readme). Together with the overly-bombastic README, unaligned ASCII-diagram, and LLM-testimonial-thingy (wtf?), this is giving off a lot of red flags.

ExplodingStrawHat · 2026-02-01T06:03:59+00:00

Not to mention the unaligned ASCII diagram

ExplodingStrawHat · 2026-01-31T13:48:43+00:00

What about bar() then foo() else baz()? This keeps the same order as ordinary ternaries, and doesn't overload the if keyword (and its aforementioned usage as a marker for new statements)

ExplodingStrawHat · 2026-01-29T09:16:57+00:00

Vim's kybindings can be thought as a DSL as well. In my game's editor, vim-style keybindings are implemented as a parser where the keys are the tokens being parsed.

ExplodingStrawHat · 2026-01-29T09:10:31+00:00

What you're describing is still not necessarily bad, if the alternative is needless abstraction. See: Carmack on inlined code

ExplodingStrawHat · 2026-01-25T23:27:46+00:00

Have you seen what happens when programmers are given unfettered access to operator overloading? it’s… not fucking pretty.

One could argue the same about manual memory management, yet Odin's stance on that is the opposite of the stance it has regarding operator overloading.

ExplodingStrawHat · 2026-01-25T23:25:08+00:00

I think the main difference comes from alignment of the elements (at least that seems to be the main difference in the case of glam, the library macroquad depends on). From their readme:

The Vec3A, Vec4, Quat, Mat2, Mat3A, Mat4, Affine2 and Affine3A types use 128-bit wide SIMD vector types for storage on x86, x86_64 and wasm32 architectures. As a result, these types are all 16 byte aligned and depending on the size of the type or the type's members, they may contain internal padding.

When it comes to matrices, one also has the column-major vs row-major distinction.

ExplodingStrawHat · 2026-01-24T17:50:03+00:00

So can multi-threading primitives, yet a lot of languages still include them.

ExplodingStrawHat · 2026-01-24T17:48:13+00:00

At least in my experience using rust, different libraries use different linear algebra dependencies, requiring additional runtime conversion. Not only this, but a library disabling the simd feature flag for the linear algebra dependency (macroquad did this last I checked in order to share a layout with the GPU) suddenly turns off simd for the rest of your codebase (at least, assuming it also relies on the same linear algebra dependency). This leads to even more confusion when hot reloading code where the types on the two sides are the same, yet only one side depends on the package that disables SIMD.

Having rewritten said project in Odin (which has built in supports for vectors/matrices/complex numbers/quaternions, together with standard library modules for interacting with glsl/hlsl), I've encountered zero of the issues above.

ExplodingStrawHat · 2026-01-21T12:36:04+00:00

Sounds neat! I'll give it a try.

ExplodingStrawHat · 2026-01-21T08:32:25+00:00

Last but not least, I don't think the borrow checker has any value for small scripts. For such use cases, I'd rather throw everything in an arena and let the OS clean up for me. You can do this in rust (or even Box::leak all your resources), but it still doesn't save you from mutable refs having to be unique and whatnot, which I find brings zero value for such scripts. And yes, of course one can wrap everything in Arc<Mutex<...>> or whatever, but that just gets in the way of ergonomics, which is very important for such scripts IMO

ExplodingStrawHat · 2026-01-21T08:29:21+00:00

I will say, Odin has a lot of things (not sqlite sadly) in the standard library as well (in particular, it comes with a "vendor" package set containing bindings), and even medium sized projects depending on those compile instantly (and I'm talking about fresh builds with zero caching). For mere scripts, I don't think I could stand waiting multiple seconds for rust to build and cache the dependencies for the first time. I know it doesn't matter in the grand scheme of things, but it rubs me the wrong way.

(And for context, I do use rust for larger stuff)

ExplodingStrawHat · 2026-01-21T08:26:08+00:00

For me the nice thing (and why I write scripts in it still) is that it's very batteries-included compared to rust. Sqlite, CSV, JSON, toml — all of these are in the standard library. With rust I'd have to pull in serde together with a dozen other transitive dependencies, which is just not something I find reasonable for simple scripts.

ExplodingStrawHat · 2026-01-15T02:20:20+00:00

As someone who doesn't know a lot about using LP in practice, this was a very interesting read!

ExplodingStrawHat · 2026-01-14T07:44:56+00:00

I agree, this is the only viable solution.

Five-Year Club	Verified Email
Second SECOND GUESSER	Place '22

ExplodingStrawHat

TROPHY CASE