3 ms·

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 an

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 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)

fcarraldo 2mo ago
This is extremely impressive for such a young entrepreneur. I have no reason whatsoever to use this, but it's a cool project!
- AbhiramaVS 2mo ago
  Thank you so much!!
tomcam 2mo ago
Congratulations! What target environments does it support?
- AbhiramaVS 2mo ago
  macos is fully supported (gpu for apple silicon is written with obj C and coco, and the JIT is made for macos) and linux also works without GPU or GUI features. windows isnt supported lol though if you knew what you were doing it wouldnt be hard to port to windows (i personally dont have a windows machine to test/develop for)
yyx 2mo ago
I highly recommend you to rethink error handling. No way to know if function throws exceptions, no way to know what kind of exceptions. This is a minefield.
- AbhiramaVS 2mo ago
  I'm pretty sure I have exactly what you are talking about. error handeling was one of the things that I wanted to get right with jaithon, and I made my system similar to like rust. error[E0301]: cannot assign to immutable binding `x` --> examples/demo.jai:7:5 | 5 | let x = 1 | - `x` declared immutable here ... 7 | x = 2 | ^^^^^ assignment to immutable binding | help: change the declaration to `var x = 1` ^^ That was shown from the Readme, more extensive examples are in documentation! Is this what you were refering to or something else, I completely agree that erorr handeling is very important.
  - mplanchard 2mo ago
    I think jyx was talking about the throw/try/catch mechanism[0] used for error handling, in contrast to error handling in e.g. Rust, where the idiomatic way of handling an error is to return a Result enum, containing either a success value or an error type. The latter allows callers to know that a function can error, and what kind of error it can return. Exception-based error handling, on the other hand, means you cannot tell by way of the type system whether or what errors a function can throw. [0]: https://github.com/abhiramasonny/jaithon/blob/main/LANGUAGE.md#errors https://github.com/abhiramasonny/jaithon/blob/main/LANGUAGE....
    - AbhiramaVS 2mo ago
      Ah yeah that makes more sense. Will look into this
- program_whiz 2mo ago
  AbhiramaVS I think your choice to use exceptions is fine, it matches closely with Java / Python your inspirations. The "show me every error" crowd loves to harp on this issue, but the truth is, its a tradeoff like all others. Exceptions provide flexibility in error handling, and most code just forwards and you end up in the same situation anyway. Something like this (go style): if result, err := do_thing(); err != nil { log.errorf("Got an error! %v", err); return err; } Or the rust equivalent isn't super useful, the code is just outputting an inferior form of stack tracing and debugging. Honestly unless the code at the immediate site of the error can handle the issue, or perhaps one level higher, having precise error information (usually obscured by some generic Error class anyway) isn't very helpful, and ends up propagating up to a high level where the whole thing is terminated / cleaned up anyway, which is what exceptions provide automatically. Also, only catching the things that you can deal with and know about is useful in the sense it keeps code flexible (e.g. you don't handle a DiskFull exception because the only thing you can do with it is throw anyway, and if you had a DiskFull error returned, you would just return it up the stack / panic). As new unhandled errors emerge, you just throw them up the stack, the same way error code would, except errors just require you to explicitly manage the machinery everywhere, requiring rigid, over-specified, fragile code in many cases. I do see the argument for explicit errors especially in system programming, realtime / perf-critical, kernels, etc. But this language doesn't appear to be targeted at that, and uses GC. So having exceptions seems like a valid design choice to me. Using them also frees you a bit since you can pass around functions, captured references, threads, etc. in a bytecode + GC lang without worrying to much about the error states and memory ownership.

fcarraldo 2mo ago

This is extremely impressive for such a young entrepreneur. I have no reason whatsoever to use this, but it's a cool project!

AbhiramaVS 2mo ago
Thank you so much!!

tomcam 2mo ago

Congratulations! What target environments does it support?

AbhiramaVS 2mo ago
macos is fully supported (gpu for apple silicon is written with obj C and coco, and the JIT is made for macos) and linux also works without GPU or GUI features. windows isnt supported lol though if you knew what you were doing it wouldnt be hard to port to windows (i personally dont have a windows machine to test/develop for)

yyx 2mo ago

I highly recommend you to rethink error handling. No way to know if function throws exceptions, no way to know what kind of exceptions. This is a minefield.

AbhiramaVS 2mo ago
I'm pretty sure I have exactly what you are talking about. error handeling was one of the things that I wanted to get right with jaithon, and I made my system similar to like rust. error[E0301]: cannot assign to immutable binding `x` --> examples/demo.jai:7:5 | 5 | let x = 1 | - `x` declared immutable here ... 7 | x = 2 | ^^^^^ assignment to immutable binding | help: change the declaration to `var x = 1` ^^ That was shown from the Readme, more extensive examples are in documentation! Is this what you were refering to or something else, I completely agree that erorr handeling is very important.
- mplanchard 2mo ago
  I think jyx was talking about the throw/try/catch mechanism[0] used for error handling, in contrast to error handling in e.g. Rust, where the idiomatic way of handling an error is to return a Result enum, containing either a success value or an error type. The latter allows callers to know that a function can error, and what kind of error it can return. Exception-based error handling, on the other hand, means you cannot tell by way of the type system whether or what errors a function can throw. [0]: https://github.com/abhiramasonny/jaithon/blob/main/LANGUAGE.md#errors https://github.com/abhiramasonny/jaithon/blob/main/LANGUAGE....
  - AbhiramaVS 2mo ago
    Ah yeah that makes more sense. Will look into this
program_whiz 2mo ago
AbhiramaVS I think your choice to use exceptions is fine, it matches closely with Java / Python your inspirations. The "show me every error" crowd loves to harp on this issue, but the truth is, its a tradeoff like all others. Exceptions provide flexibility in error handling, and most code just forwards and you end up in the same situation anyway. Something like this (go style): if result, err := do_thing(); err != nil { log.errorf("Got an error! %v", err); return err; } Or the rust equivalent isn't super useful, the code is just outputting an inferior form of stack tracing and debugging. Honestly unless the code at the immediate site of the error can handle the issue, or perhaps one level higher, having precise error information (usually obscured by some generic Error class anyway) isn't very helpful, and ends up propagating up to a high level where the whole thing is terminated / cleaned up anyway, which is what exceptions provide automatically. Also, only catching the things that you can deal with and know about is useful in the sense it keeps code flexible (e.g. you don't handle a DiskFull exception because the only thing you can do with it is throw anyway, and if you had a DiskFull error returned, you would just return it up the stack / panic). As new unhandled errors emerge, you just throw them up the stack, the same way error code would, except errors just require you to explicitly manage the machinery everywhere, requiring rigid, over-specified, fragile code in many cases. I do see the argument for explicit errors especially in system programming, realtime / perf-critical, kernels, etc. But this language doesn't appear to be targeted at that, and uses GC. So having exceptions seems like a valid design choice to me. Using them also frees you a bit since you can pass around functions, captured references, threads, etc. in a bytecode + GC lang without worrying to much about the error states and memory ownership.