Hi HN! I’m Abhirama, and I started Jaithon in 2023 when I was in 8th grade to teach myself how to code in C. Jaithon 1 was really bad, it was all in one file and it was completely an interpreter and it was extremely slow with bugs everywhere. Recently, I have came back to this project with the goal of making the perfect programming language that is not only fast, but it has the optimal syntax & features out of every programming language.
Jaithon has Python features such as comprehensions, f-strings and first-class functions with declared fields, explicit visibility, traits and checked type annotations, along with syntax choices from lua, Java, bash, c++, go, and rust.
The compiler separates lexing, parsing, type checking and bytecode generation. The VM has 107 opcodes along with a JIT compiler to speed stuff up, polymorphic inline caches and a garbage collector.
Jaithon is nearly completely bootstrapped, with the lexer, parser, and bytecode generation built completely within Jaithon itself. The syntax of jaithon code is also easily customizable.
It would mean a lot if you star the project on my GH as I am trying to reach 15 stars soon :) anyways, lmk if you have any feedback. Currently Jaithon is between Java and C++ for speed (a more detailed benchmark exists within the project by running make benchmark) and I am in the process of optimizing the VM.
This language keeps the best parts of Python while discarding the bad. I clicked the link apprehensively, but I have to agree that this syntax is spot-on (for me, at least). So many new languages miss the mark.
Nice! This is what I keep telling everyone: LLMs let you build stuff you may not have the time/energy to before. You still need to do the last 10% yourself though. Tying up all the loose ends.
Syntax is a personal choice. Can always be changed. Architectural choices are difficult to manage later on.
The VM seems to be a stack VM. I have my own python replacement project (https://news.ycombinator.com/item?id=48090665) that I am developing privately for now. LLM-assisted ofc. Started with a bytecode VM and then switched over to a register one. The biggest break from regular language systems was the decision to move to an Erlang-style preemptive scheduler.
I completely agree! I started Jaithon before mainstream LLMs existed and for a while Jaithon was free of AI generated code and my personal stance on AI generated code was rather negative. Recently though, my stance has grown far more positive towards AI. While LLMs are undeniably the future it remains crucial that you completely understand the code being generated, and are also in control of the architecture in place. I have tried to adhere to both of these principals while coding :) and it is an unequivocal fact that AI made me atleast 10x more productive. Granted this is a bad measure but still a measure of such: in the last 2 days I have made the same number of commits as I have to Jaithon in the last 3 years.
Also, I was curious why you swapped over to a register based VM, could you give more clarity on that and the benifits/negatives? currently im using some sort of bytecode vm, though its not like im married to the idea of a bytecode vm.
Also (dont mean this as any sort of advertisement or anything like that) would you mind starring the repo? trying to hit 15 stars :D dont feel forced or anything like that.
There are pros and cons to both approaches. I moved from stack to register because I was writing the code gen backend from scratch in any case and preferred to have a register representation instead of converting from stack to register (which has to happen one way or another). Also mildly helpful with control flow analysis during bytecode generation and verification phases.
Note: Unrelated to the Jai programming language (but they both use .jai file extension).
Hi HN! I’m Abhirama, and I started Jaithon in 2023 when I was in 8th grade to teach myself how to code in C. Jaithon 1 was really bad, it was all in one file and it was completely an interpreter and it was extremely slow with bugs everywhere. Recently, I have came back to this project with the goal of making the perfect programming language that is not only fast, but it has the optimal syntax & features out of every programming language.
Jaithon has Python features such as comprehensions, f-strings and first-class functions with declared fields, explicit visibility, traits and checked type annotations, along with syntax choices from lua, Java, bash, c++, go, and rust.
The compiler separates lexing, parsing, type checking and bytecode generation. The VM has 107 opcodes along with a JIT compiler to speed stuff up, polymorphic inline caches and a garbage collector.
Jaithon is nearly completely bootstrapped, with the lexer, parser, and bytecode generation built completely within Jaithon itself. The syntax of jaithon code is also easily customizable.
You can build and run it with:
git clone https://github.com/abhiramasonny/jaithon cd jaithon make ./jaithon examples/hello.jai
It would mean a lot if you star the project on my GH as I am trying to reach 15 stars soon :) anyways, lmk if you have any feedback. Currently Jaithon is between Java and C++ for speed (a more detailed benchmark exists within the project by running make benchmark) and I am in the process of optimizing the VM.
Would love to hear yalls thoughts!
- Abhi (abhiramasonny.com)
This is extremely impressive for such a young entrepreneur.
I have no reason whatsoever to use this, but it's a cool project!
Congratulations! What target environments does it support?
I’m impressed that you got GitHub to accept the language/syntax! Gleam still hasn’t managed to convince them.
That would have been cool, but he simply used the python highlighting: https://github.com/abhiramasonny/jaithon/blob/8f47ee5a52ffca...
First impression: looks more like JavaScript than Python?
This language keeps the best parts of Python while discarding the bad. I clicked the link apprehensively, but I have to agree that this syntax is spot-on (for me, at least). So many new languages miss the mark.
Nice! This is what I keep telling everyone: LLMs let you build stuff you may not have the time/energy to before. You still need to do the last 10% yourself though. Tying up all the loose ends.
Syntax is a personal choice. Can always be changed. Architectural choices are difficult to manage later on.
The VM seems to be a stack VM. I have my own python replacement project (https://news.ycombinator.com/item?id=48090665) that I am developing privately for now. LLM-assisted ofc. Started with a bytecode VM and then switched over to a register one. The biggest break from regular language systems was the decision to move to an Erlang-style preemptive scheduler.
I completely agree! I started Jaithon before mainstream LLMs existed and for a while Jaithon was free of AI generated code and my personal stance on AI generated code was rather negative. Recently though, my stance has grown far more positive towards AI. While LLMs are undeniably the future it remains crucial that you completely understand the code being generated, and are also in control of the architecture in place. I have tried to adhere to both of these principals while coding :) and it is an unequivocal fact that AI made me atleast 10x more productive. Granted this is a bad measure but still a measure of such: in the last 2 days I have made the same number of commits as I have to Jaithon in the last 3 years.
Also, I was curious why you swapped over to a register based VM, could you give more clarity on that and the benifits/negatives? currently im using some sort of bytecode vm, though its not like im married to the idea of a bytecode vm.
Also (dont mean this as any sort of advertisement or anything like that) would you mind starring the repo? trying to hit 15 stars :D dont feel forced or anything like that.
There are pros and cons to both approaches. I moved from stack to register because I was writing the code gen backend from scratch in any case and preferred to have a register representation instead of converting from stack to register (which has to happen one way or another). Also mildly helpful with control flow analysis during bytecode generation and verification phases.
ah gotu, yeah that makes sense. I will def further investigate this ltr :)