-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hi, I wanted to know how does this language differ to other low level languages? #5
Comments
Hi Joe! I mean that Jet's code generation will allow it create applications natively and portably through C code generation and will allow it to be portable on the web via JavaScript code generation. The language will work closely with FFIs in order to give the same experience using other important libraries. The goal is to make a language capable of accomplishing the same task in shorter, simpler, and more powerful manner. In the end, the language should in theory be able to generate entire web applications or equivalent native applications if necessary. Another goal is to be able to embed JavaScript library interfaces in your native applications and C library interfaces in JavaScript / Web Applications. This can be made possible through interpreters, VMs, or WASM compilation. What mainly differs it from a language like Rust, is that Rust's whole design and implementation is given with quite a lot of features. As a C++ programmer who has learned Rust, it takes some getting used to, but the language was closer to C++ than it was to C. I want to keep the simplicity of C, while providing modern features in a programming languages and still have the programmer have control of their code. Rust gives performance control, but not as much manipulation as I'd like to have. Differentiating with C and C++ is that the language will have generics, more notably, fixing issues with compile time functions and compile time parameters which has not seen the light of day since in C++. The best part is we don't have to go too far from C in order to accomplish this, since the compiler can generate C code that will be able to the same tasks that Jet wants it too. |
Hi @aboss123 thank you for your response :) This language does sound interesting.
Sorry mate but what do you mean by manipulation? One question though, is Jet as safe as using Rust? |
What I mean is control. Pointer arithmetic trickery, and other valid memory manipulation that cannot be detected by the borrow checker as valid.
It depends on what you consider as "safe", safe may mean prevents me from memory leaks, it may also mean that I don't have to worry about my application having segmentation faults when I made a mistake that leads to undefined behavior. In a language where control is higher priority than safety, allowing undefined behavior is inevitable, but that does not mean it cannot help you control undefined behavior. A good debug runtime allows for all sorts of memory errors to be caught and handled, and with the way Jet handles its compile-time errors, it's runtime error system would be equally great at catching memory problems. As with good compilers now-a-days, we can catch a lot of potential memory errors at compile-time and tell the programmer about them too without resorting to run-time error reporting. Thank you for taking interest in the language :) and let me know if you have anymore questions. |
I see mate, but then I thought that you can use
Can it also catch data races?
Yes true, other than data races, at least with C.
Thank you for answering them to me, and yes I do have more questions lol :) So my more questions are:
|
For your information, there is a rough language specification here.
While unsafe Rust can give equivalent performance to C and more low level control, it doesn't disable the borrow checker. If you need to mess at far lower levels, you should be able to.
There is a plan to add smart pointers in the language, although this may be trickier than it sounds since we are generating C code initially.
Since the language is closer to low-level interaction, it should be able to implement equivalent efficient C code. In fact, optimized C is written by a programmer who has analyzed major parts of the program and identified where they can optimize their code. I hope to make the language simple enough that inferior code is not generated in situations where it might generate in other languages.
Yes they are.
Yes, this is the goal. FFI with C should work very smoothly and we have plans for FFI with JavaScript.
I can see that Odin has similar goals to Jet, but Jet focuses on the Web too, as it will also generate JavaScript applications. Although the syntax is very similar to ours, we have a few different features such as static compilation as well as inline JS planned in the future.
In debug runtimes of compiled programs, memory-leaks and other undefined behavior can be caught and handled. The language does not intend of having GC but also does not plan on having a full blown borrow checker, rather it has a bit of static analysis to catch basic borrowing errors and reports all others during run-time. Most of the time the location and explanation during program failure is enough for a good programmer to figure out their problem and be productive.
I would say any GUI libraries that C has can be integrated with this language in the future.
I would like there to be support for Android applications. At the moment, a majority of native Android development occurs using the JVM, and native Android interactions are usually harder to come by. That being said, if we generate C, it should be able to interact with Android internals, but I'm not exactly sure who GUIs could be made at the current moment. |
When you say closer to low-level interaction which language are you comparing Jet to?
Hopefully mate, sounds pretty interesting how Jet works :)
Oh nice mate :)
I thought Odin has static compilation?
Right I see but what about specifically data races, how are they handled?
But according to your own statement on the main page of your repo "Fast Language for Developing Consistent Native, Mobile App, and Web Applications." which is found here So I thought it would already support Android? |
Specifically Nim. Sometimes certain functions and data structures made in a certain way can trip up the code generation to write inefficient C code.
The language is a work in progress, so mobile support is in progress. But you should know that C code can run on android thus Jet code can run on Android.
I mis-typed. What I mean is that Jet will have compile-time code execution. You can view more in the language documentation about it.
I will have to add a pass in the static analyzer to account for this. Currently this is a work in progress. |
I never knew that Nim is a transpiled language.
Do you plan to integrate a C library (which is for Android support) into Jet so it can easily be compiled for Android? If so which library would you go for?
Oh so like you can run code during evaluation. For example: x := 10 + 3; // this will run during compile time
This will run during runtime in debug mode? With all of these safety features, would Jet become as safe as Rust (while giving the users the ability to do whatever they want)? |
I might do something like that but even when using C and C++ in your Android app, you would also need to use Java. My plan is to be able to generate entire android projects from my language if possible in the future.
my_function => () {
my_var := static {
print("Hello, World!");
return 23;
}
} Now the variable
That is the goal :). If you're interested contributing you can let me know. |
Are there any third party frameworks for C which generates your code to Android compatible? If so we could use that with your language? my_function => () {
my_var := static {
print("Hello, World!");
return 23;
}
}
Interesting mate, I wonder if this is even possible in Rust?
Cool mate :) But then if you are trying to catch potential memory leaks during runtime, isn't it possible to miss some of these bugs? Whereas since Rusts does this during compile time, it catches it 100%? Just curious mate
I am more than 100% interested in helping out, but I am not as smart as you mate lol, cause you have a lot more experience with low level stuff then I do, I can only do declarations of fuctions, printing stuff, declaring variables, and doing basic stuff, nothing low-level related, however I have taken a course so hopefully I might get better. However if there is something easy I could do as a beginner then I am more than interested in helping? I got some questions in regards to the syntax of the language. For example when declaring functions. my_function => () how come unlike most other languages you use How are Is it like Do you have for i := 0; i < 10; i++
{
// does something
} |
I concur. This is one hell of a jank way to declare functions/methods/whatever-you-want-to-call-them. |
I'm not sure of any, but if you find some feel free to let me know.
I'm not confident that Rust can prevent 100% of memory leaks. I don't think any compiler is smart enough to do that. But if it really does, then it is really restricting what the user can do to account for all the cases. Some errors can be caught at compile-time in Jet and some at run-time, this is what happens when control is prioritized over "safety".
You could suggest ideas for syntax in language or potential easier syntax for certain actions. Is there something in Rust that you wish would be easier to write, or would want to take less code. Suggest it and I'll see if it's possible.
It prioritizes the function name first. When scrolling through a file, you will see all the function names instantly rather than having scan across the file to find a name. A lot of the questions about syntax or how stuff looks like is shown in the language documentation here. |
Umm ever heard of Ctrl+F (or ⌘+F for mac)? I feel that convention over innovation is better in this case. I also know our dear friend Hitech also feels similar about this. |
Sure mate I might actually research this for you mate :)
It has the borrower rule, so even if you are not doing anything that will have memory leaks, if you violate the borrower rule or any of its other rules, then it will fail to compile. So it does prevent memory leaks 100% unless you use
I asked an experienced Rust programmer something similar to what you have told me and he told me this:
That is great mate :)
As a matter of fact I do have a suggestion but I will open up a new issue for this :) Its something that your language, Rust and Zig seem to be missing and I really don't get why people don't seem to have the traditional c-style
As @Chinay-Domitrix has menitoned isn't it possible to use fn some_function()
{
} Its not hard at all to find it, if anything it might make it a little easier to identify as it won't confuse you between a global variable and a function (as it has |
Yeah, I was about to say that; there is no apparent reason to avoid C-style function/method declarations, as they provide more clarity and distinction between functions/methods and global variables/fields. Cases in point: JavaScript and Kotlin (at least the JVM version); both have type inference for variables, and yet, they still implement the function and fun keywords, respectively. A JS function declaration: function foo() {
console.log("bar");
} Or a Kotlin function declaration: fun foo() {
println("bar")
} As opposed to Jet: foo => () {
print("bar");
} For that matter, even Python, one of your syntax inspirations, omits the lambda: def foo():
print("bar") |
I would say they are more Rust style functions than C style since you state the return time right at the beginning but yeah you are right :)
Yeah all of your examples makes perfect sense. It does look a little strange in Jet. |
Even Zig, which you use for almost all of your MD code fences, omits the lambda (sample from Zig documentation since IDK Zig): const std = @import("std");
pub fn main() !void {
const stdout = std.io.getStdOut().writer();
try stdout.print("Hello, {s}!\n", .{"world"});
} |
It makes the language a bit different. But are you suggesting that I use |
IMO whether or not you add an explicit function declaration keyword is up to you; however, please do drop the lambda. As I have said before, convention over innovation. |
@Chinay-Domitrix foo :: (param1: i32, param2: i64) {
// code is here ...
} This still sticks with my design goals with dropping the lambda operator, but I'm not sure which looks better, the |
@aboss123 Sure the |
Or in the worst case, you could keep the lambda, but move it to after the parenthesis |
Hi, I wanted to know how does this language differ to other low level languages such as Rust?
The text was updated successfully, but these errors were encountered: