The language is still early. Pre-1.0. Not production-ready. Not trying to replace Rust, Go, Python, shell, or anything else.
It is my focused experiment (but I want you to be involved, if you don't think it's dumb) in:
- small native tools
- explicit failure semantics
- tiny-ish binaries
- no VM / no JIT
- no LLVM dependency
- no libc/CRT by default in current generated paths
- a compiler you can literally read because it is ordinary JavaScript
- runtime checks that fail near the bug
- explicit fork/wait/job semantics
- parallelism that favors isolation and instrumentation over raw speed
- behavior tests as executable claims
Parallel work in Freelang:
The parallelism piece matters to me, too. I don’t want async/parallel work to be this intractable tangle where the program looks simple until it isn’t. Inscrutable races no more! I’m more interested in job boundaries you can see, wait points you can see, inbox/outbox state you can inspect, and OS/process isolation where that makes the system easier to understand.
Maybe that is slower than the clever thing. Good. Speed is not the only axis. A lot of bugs are born from chasing elegance that deletes the evidence. I also think this matters more now because AI is about to write an absurd amount of code as I said. Definitely 100x more code than all humans have written so far. That code is going to need languages, runtimes, tests, and failure models that make hidden assumptions easier to catch.
I don’t think FreedomLang "solves" that. But it is shaped by that pressure.
So, the manifesto version is:
No more magic.
Reality is magic enough.
Or more straight up:
Free yourself from magic bullshit.
Which by that I mean: no more gratuitous magic that hides the thing you will eventually have to debug anyway.
If the program touches reality, reality should show up in the source. If a job forks, the fork should be visible. If a job waits, the wait should be visible.
If data crosses a boundary, the boundary should be visible. If the program enters an impossible state, it should die there.
That’s kinda the philosophy. The implementation is not all the way there yet - but a lot of it is. But manifesto type thing - is the direction.
The compiler today is JavaScript. It lowers `.flx` source through a small IR and emits native x86-64 artifacts for Linux, macOS, and Windows. There are custom operators, object-shaped calls, runtime bounds/shape checks, fatal invariant failures, experimental chaos/world-state modeling, and explicit fork/wait/job semantics.
It is weird on purpose, but not weird for decoration. Weird for real!
I know language design is a tarpit - boulevard of broken dreams to quote a classic from my youth - but surprised let you know she cares and freelang was that little surprise - I know the muse cares.
I know some of this may be dumb. I know there are a thousand wasy to fuck this up.
But if you don’t think it’s dumb, I’d love help. Becuase I think it's important, and fun. So come to the repo and do stuff.
Especially from people who care about compilers, small native tools, language ergonomics, runtime design, failure semantics, security tooling, behavior tests, or just tearing apart the assumptions. I'm not qualified to be writing a language. But I am. But I want people who are, who care.
For this thread specific feedback/unhinged-rants I’d love:
- Is the world-state vs fatal-bug distinction clear?
- Is the syntax merely unusual, or actively hostile?
- Are explicit jobs / waits / inboxes / outboxes useful, or too heavy?
- What would make this easier to evaluate from code?
- Where am I overclaiming?
- What would make you want to try writing one real small tool in it?
I’m making a weird little language to free myself from magic bullshit.
Not because abstraction bad. It ain't bad. Because I got tired of abstractions concealing the stuff I had to debug anyway.
But I don't think that explicitness has to cost you C++ level verbosity, so syntax design was also a driver.
But the first reason I made this was even practical: I wanted a small AOT-compiled language, like JS, that could produce native binaries and protect source code IP better than shipping obfuscated JavaScript around. And worked across multiple OS.
Then I started vibe engineering the compiler end of last year (writing the compiler with agents), and realized: oh, if I’m making a language, I can actually choose whatever I want. I don't have to copy JS. So I started getting serious about the creative aspect, and seriously excited because "I was creating a new language" - not just a AOT compiled JS. I got to choose the kind of pain it should remove, and I reflected on my experiences with languages over the decades.
That got more interesting. I’ve spent a lot of time in JavaScript, Go, shell, framework land, deployment land, “why is this async thing racing only in prod” land, “why did this ORM silently do the stupid expensive thing” land, “why is the nice abstraction now an impossible-to-debug haunted house” land. I spend a lot of time with Java, 3D graphics, Perl, C before that. And even some QBASIC and assembly.
I grew up before the internet, but also lived to see the rise of software development as a career people could bootcamp into. A lot of modern software feels like it optimizes for the demo path. So shiny. So fake. So easy, but too easy. Not because of masochism or "true Scotts" stuff, but because it is tech debt. It costs you later. And it doesn't make it easy to reason abotu as you're doing it. I suppose I have an aesthetic sense against bad system design and feel so opposed to it I simply won't use it - regardless of the popularity or missed revenue for not being trendy enough.
Magic render trees. Magic object queries. Magic deployment layers. Magic retries. Magic async behavior. Magic defaults. Magic recovery paths. I refuse to get stuck in mush. I value my devx/ergonomics (and my wrists, my valuable wrists and fingers and eyeballs!) above all the other shiny stuff software could send at you.
I digress - I am not saying Freelang fixes this. At all. But maybe it addresses some of that in a precise way. But mainly, I'm just trying to paint the picture from my p.o.v where this came from. I found that, on here, people often appreciate the human story of origins as a way to relate to motivations. That helps a lot it seems to de-confusify the great crowd.
Some of the "magic mush" I seek to escape is genuinely useful. Some of it solves narrow popular cases beautifully. But the cost is often that the real system becomes harder to reason about. The magic absorbs the simple case and exports the weird case to you as a heisenbug.
So I craved the opposite direction. Like physically craved it. I must have it. No tolerance for alternatives. No more magic bullshit.
I don't want:
max cleverness.
I don't care: max ecosystem.
I never: "trust the framework."
I dislike "yeah, just catch the exception somewhere."
I despise, "the runtime knows what you meant." - why? Sounds great but you might want to mean something different tomorrow.
SO I thought alot about what I would do to improve langauges. And also thought about how to improve them for AI, because I reasoned that: "AI is going to write 90x all the code that was ever written in history before this point. If we keep using the same languages, we will end up with 90x the bugs - because many bugs are not just "programmer bad", it's like "language baggage" that is almost inevitable. The famouse example is the endless cases of pointer fails in C. Bounds checks. Etc. etc. etc.
OMG - I WANTED OUT! How can we live in a world where we are writing 21st century tools using 20C languages, moving 100x faster and generating 100x the bugs (or more, perhaps, as bugs may increase combinatorially to code size...idk).
Anyway, this is too long. It's too long. But I don't care. I must say my piece about this. NO MORE MAGIC BULLSHIT. We can't allow it. The world is too precious to create endless seas of unnecessary bug classes and instances. We can do better. I am NOT saying freelang fixes it. No way - but I am saying I'm trying to make a step in the direction of better.
And doing something I kind of enjoy. Creating stuff.
So let me tell you more about it:
Model the world as data.
Treat bugs as fatal.
The world is chaos - so we have chaos tags for its states. A missing file is not an exception from reality. It is reality.
A network timeout is not surprising. It is the network; Permission denied is a world state; those things should be visible in the program.
Aside from that - what are the failure states? All in the program. THe program itself can be bad. In that case we should be ruthless. Intolerant. Merciless. A wrong program can not be permitted to exist. It must be terminated immediately. There is no other choice. Limp along in an incorrect state? Yes how about we permit patient zero to mingle with all the guests at the dinner part (cruis ship?). No. Isolate. The program must abort (fall) on any exception. It's your fault, anyway. You created a bad program - or didn't patch the compiler ;)
So stuff like a bad tag, bad field access, impossible state, or broken invariant is death. Pure 100% swift death. That is not "business logic." That is the program lying to itself. It should stop there, loudly, before the lie spreads.
So FreedomLang is trying to draw a hard line:
missing file -> world state (chaos tags)
network timeout -> world state
permission denied -> world state
bad tag
bad field access
impossible state -> fatal bug (fall)
You may have strong arugments or distaste against some of this. Mostly, I will not be convinced. This is my project and I have drawn my taste upon it. However if you believe something is really bad - convince me. Tho I may not get back to you on this thread. Don't assume I have nothing to say just because I don't reply here. I'm just busy.
But mostly, I'm not looking for energy sapping "contrarians" - unless they truly see the value of the gestalt here. Really tho I want the people to whom this is like "quenching oasis in the desert". These people, if they exist (ok if not, I shall go on with this most likely), will know this is something cool. I don't want you if you have to be convinced. Maybe you like the idea but you'd rather work on a different project - that's cool. Like one of the other languages spirning up now. Go there! But if you want to get involved here, please do.
It's a chance to shape maybe a new language at the very start. And to implement, and use, and write in it. I was going to keep this proprietary (i make that determination project by project), secret sauce only my company could use, but I think the space is oepning up. People are creating new languages for the new age we are in. And I reassessed, my intuition now says I should release this. So I am.
keepamovin•1h ago
It is my focused experiment (but I want you to be involved, if you don't think it's dumb) in:
- small native tools
- explicit failure semantics
- tiny-ish binaries
- no VM / no JIT
- no LLVM dependency
- no libc/CRT by default in current generated paths
- a compiler you can literally read because it is ordinary JavaScript
- runtime checks that fail near the bug
- explicit fork/wait/job semantics
- parallelism that favors isolation and instrumentation over raw speed
- behavior tests as executable claims
Parallel work in Freelang:
The parallelism piece matters to me, too. I don’t want async/parallel work to be this intractable tangle where the program looks simple until it isn’t. Inscrutable races no more! I’m more interested in job boundaries you can see, wait points you can see, inbox/outbox state you can inspect, and OS/process isolation where that makes the system easier to understand.
Maybe that is slower than the clever thing. Good. Speed is not the only axis. A lot of bugs are born from chasing elegance that deletes the evidence. I also think this matters more now because AI is about to write an absurd amount of code as I said. Definitely 100x more code than all humans have written so far. That code is going to need languages, runtimes, tests, and failure models that make hidden assumptions easier to catch.
I don’t think FreedomLang "solves" that. But it is shaped by that pressure.
So, the manifesto version is:
Or more straight up: Which by that I mean: no more gratuitous magic that hides the thing you will eventually have to debug anyway.If the program touches reality, reality should show up in the source. If a job forks, the fork should be visible. If a job waits, the wait should be visible.
If data crosses a boundary, the boundary should be visible. If the program enters an impossible state, it should die there.
That’s kinda the philosophy. The implementation is not all the way there yet - but a lot of it is. But manifesto type thing - is the direction.
The compiler today is JavaScript. It lowers `.flx` source through a small IR and emits native x86-64 artifacts for Linux, macOS, and Windows. There are custom operators, object-shaped calls, runtime bounds/shape checks, fatal invariant failures, experimental chaos/world-state modeling, and explicit fork/wait/job semantics.
It is weird on purpose, but not weird for decoration. Weird for real!
I know language design is a tarpit - boulevard of broken dreams to quote a classic from my youth - but surprised let you know she cares and freelang was that little surprise - I know the muse cares.
I know some of this may be dumb. I know there are a thousand wasy to fuck this up.
But if you don’t think it’s dumb, I’d love help. Becuase I think it's important, and fun. So come to the repo and do stuff.
Especially from people who care about compilers, small native tools, language ergonomics, runtime design, failure semantics, security tooling, behavior tests, or just tearing apart the assumptions. I'm not qualified to be writing a language. But I am. But I want people who are, who care.
For this thread specific feedback/unhinged-rants I’d love:
- Is the world-state vs fatal-bug distinction clear?
- Is the syntax merely unusual, or actively hostile?
- Are explicit jobs / waits / inboxes / outboxes useful, or too heavy?
- What would make this easier to evaluate from code?
- Where am I overclaiming?
- What would make you want to try writing one real small tool in it?
Repo:
https://github.com/DO-SAY-GO/freelang
Website:
https://freelang.dev
keepamovin•1h ago
I’m making a weird little language to free myself from magic bullshit.
Not because abstraction bad. It ain't bad. Because I got tired of abstractions concealing the stuff I had to debug anyway.
But I don't think that explicitness has to cost you C++ level verbosity, so syntax design was also a driver.
But the first reason I made this was even practical: I wanted a small AOT-compiled language, like JS, that could produce native binaries and protect source code IP better than shipping obfuscated JavaScript around. And worked across multiple OS.
Then I started vibe engineering the compiler end of last year (writing the compiler with agents), and realized: oh, if I’m making a language, I can actually choose whatever I want. I don't have to copy JS. So I started getting serious about the creative aspect, and seriously excited because "I was creating a new language" - not just a AOT compiled JS. I got to choose the kind of pain it should remove, and I reflected on my experiences with languages over the decades.
That got more interesting. I’ve spent a lot of time in JavaScript, Go, shell, framework land, deployment land, “why is this async thing racing only in prod” land, “why did this ORM silently do the stupid expensive thing” land, “why is the nice abstraction now an impossible-to-debug haunted house” land. I spend a lot of time with Java, 3D graphics, Perl, C before that. And even some QBASIC and assembly.
I grew up before the internet, but also lived to see the rise of software development as a career people could bootcamp into. A lot of modern software feels like it optimizes for the demo path. So shiny. So fake. So easy, but too easy. Not because of masochism or "true Scotts" stuff, but because it is tech debt. It costs you later. And it doesn't make it easy to reason abotu as you're doing it. I suppose I have an aesthetic sense against bad system design and feel so opposed to it I simply won't use it - regardless of the popularity or missed revenue for not being trendy enough.
Magic render trees. Magic object queries. Magic deployment layers. Magic retries. Magic async behavior. Magic defaults. Magic recovery paths. I refuse to get stuck in mush. I value my devx/ergonomics (and my wrists, my valuable wrists and fingers and eyeballs!) above all the other shiny stuff software could send at you.
I digress - I am not saying Freelang fixes this. At all. But maybe it addresses some of that in a precise way. But mainly, I'm just trying to paint the picture from my p.o.v where this came from. I found that, on here, people often appreciate the human story of origins as a way to relate to motivations. That helps a lot it seems to de-confusify the great crowd.
Some of the "magic mush" I seek to escape is genuinely useful. Some of it solves narrow popular cases beautifully. But the cost is often that the real system becomes harder to reason about. The magic absorbs the simple case and exports the weird case to you as a heisenbug.
So I craved the opposite direction. Like physically craved it. I must have it. No tolerance for alternatives. No more magic bullshit.
I don't want: max cleverness. I don't care: max ecosystem. I never: "trust the framework." I dislike "yeah, just catch the exception somewhere." I despise, "the runtime knows what you meant." - why? Sounds great but you might want to mean something different tomorrow.
SO I thought alot about what I would do to improve langauges. And also thought about how to improve them for AI, because I reasoned that: "AI is going to write 90x all the code that was ever written in history before this point. If we keep using the same languages, we will end up with 90x the bugs - because many bugs are not just "programmer bad", it's like "language baggage" that is almost inevitable. The famouse example is the endless cases of pointer fails in C. Bounds checks. Etc. etc. etc.
OMG - I WANTED OUT! How can we live in a world where we are writing 21st century tools using 20C languages, moving 100x faster and generating 100x the bugs (or more, perhaps, as bugs may increase combinatorially to code size...idk).
Anyway, this is too long. It's too long. But I don't care. I must say my piece about this. NO MORE MAGIC BULLSHIT. We can't allow it. The world is too precious to create endless seas of unnecessary bug classes and instances. We can do better. I am NOT saying freelang fixes it. No way - but I am saying I'm trying to make a step in the direction of better.
And doing something I kind of enjoy. Creating stuff.
So let me tell you more about it:
The world is chaos - so we have chaos tags for its states. A missing file is not an exception from reality. It is reality.A network timeout is not surprising. It is the network; Permission denied is a world state; those things should be visible in the program.
Aside from that - what are the failure states? All in the program. THe program itself can be bad. In that case we should be ruthless. Intolerant. Merciless. A wrong program can not be permitted to exist. It must be terminated immediately. There is no other choice. Limp along in an incorrect state? Yes how about we permit patient zero to mingle with all the guests at the dinner part (cruis ship?). No. Isolate. The program must abort (fall) on any exception. It's your fault, anyway. You created a bad program - or didn't patch the compiler ;)
So stuff like a bad tag, bad field access, impossible state, or broken invariant is death. Pure 100% swift death. That is not "business logic." That is the program lying to itself. It should stop there, loudly, before the lie spreads.
So FreedomLang is trying to draw a hard line:
You may have strong arugments or distaste against some of this. Mostly, I will not be convinced. This is my project and I have drawn my taste upon it. However if you believe something is really bad - convince me. Tho I may not get back to you on this thread. Don't assume I have nothing to say just because I don't reply here. I'm just busy.But mostly, I'm not looking for energy sapping "contrarians" - unless they truly see the value of the gestalt here. Really tho I want the people to whom this is like "quenching oasis in the desert". These people, if they exist (ok if not, I shall go on with this most likely), will know this is something cool. I don't want you if you have to be convinced. Maybe you like the idea but you'd rather work on a different project - that's cool. Like one of the other languages spirning up now. Go there! But if you want to get involved here, please do.
It's a chance to shape maybe a new language at the very start. And to implement, and use, and write in it. I was going to keep this proprietary (i make that determination project by project), secret sauce only my company could use, but I think the space is oepning up. People are creating new languages for the new age we are in. And I reassessed, my intuition now says I should release this. So I am.