Hey guys!
I'm Ethan, I'm one of 10 Peregrine developers. This post is gonna be about some updates we've added into Peregrine lately.
About
If you know Python, you know how easy it is. However, it also comes with a big downgrade. Python is slow, and I'm pretty sure every python developer knows this by now. This is kind of annoying. That's where Peregrine comes in. Me and 8 other friends have been working on Peregrine for the past few months. Peregines syntax is very similar to Python's, and it gets trans-compiled to C, thus making it as fast as C. Below I've written 2 programs, one in Peregrine and one in Python.
Peregrine
def fib(int n) -> int :
if n <= 0:
return 1
return fib(n-1) + fib(n-2)
def main():
count = 0 # Peregrine has type inference!
int res = 0
while count < 40:
res = fib(count)
count++
function return types can be omitted.
Python
def fib(n):
if n <= 0:
return 1
return fib(n-1) + fib(n-2)
res = 0
for c in range(0, 40):
res = fib(c)
These two programs are almost the same, which makes it so easy for Python users to switch to. Now, you might be asking: "How much faster is Peregrine?" Well, to answer your question, here are the results:
Peregrine:
Executed in: 1.06 secs
Python:
Executed in: 32.30 secs
As you can see, Peregrine is significantly faster than Python. It is around 30x faster than python, without optimization when running this program.
What's new?
Here are some of Peregrine's newest features:
Type Inference
Type Inference is one of Pergrine's newest features. This allows Peregrine code to be written with simplicity.
if/else/match
Although this may seem like a standard feature in any programming language, it does take time to add these features which is why I'm acknowledging it. Not much to say about it since it's in every programming language.
New-ish Features
Let's talk more about the features that are currently available in Peregrine.
Ccode
Ccode allows C code to be ran in Peregrine. Here is an example:
def main():
x = 1
Ccode x++; Ccode
print("{x}\n") # prints 2
As you can see, any variables declared outside the Ccode block can be used within Ccode and vice versa. This also means you can import any C library through Ccode and use it in Peregrine.
Inline Assembly
You can also have inline assembly in Peregrine. Here is an example:
def main():
int arg1 = 45
int arg2 = 50
int add = 0
print("It should add 45 and 50 using asm and print it\n")
asm("addl %%ebx, %%eax;" : "=a" (add) : "a" (arg1) , "b" (arg2))
printf("%lld", add)
This prints 90, as expected.
More
You can find some more examples in the Peregrine test folder
Planned Features
- Structs
- More decorators for different purposes
- Python ecosystem in Peregrine
- You will be able to use any python module in Peregrine
Conclusion
Peregrine is planned to release version 0.0.1 sometime in March, so make sure to show some support by starring the repo and make sure to press on the "Watch" button so you don't miss any updates.
We would greatly appreciate any contributions, so if you find something that you can improve, open a pull-request! You can also check out our open issues
Thanks so much for reading!
Latest comments (97)
If you going to create a package maneger name it as (Hatcher) it will suitable for peregrine
Yes
Can peregrine able to use java,python,C++ native library?
How is trans compiling to see C, going to be different from what Python is doing? Unless I'm mistaken this is what CPython is doing, it's just doing it in real time, aka interpreting. And we can force Python, to compile instead of interpret already. Am I missing something here?
You're not missing anything, just a lot of hype over something new and shiny (with nice branding and graphics on the GitHub page)
This could be a python 4.x.x!
The language is wrote in V, perhaps you can make a transpiler for V along with C, then you have fast compile time as well.
I think this will be the biggest sticking point for many devs. The statement from your readme:
It will have no garbage collector because it is a system programming language but it will be very easy to use so there will be less chance of a memory leak
That seems to be a pretty bold assertion; there's a reason why the most popular programming languages today all use a garbage collector. Even using a garbage collector, I've come across many leaky applications in my career. Proving that your compiler can understand when a free call is "necessary" will be a big lift for you.
That said, I'm rooting for the cause here, and curious to see how it pans out...
I was wondering more about cross-compile issues with the same language, not using Python lib in Swallow. As text clearly points out is that you may now be able to avoid Python libraries written in other languages for speed and then having interface to Python and instead simply have libraries fully written in same language as the code you're writing yourself. Point being you can write Python application and move it's code anyplace without thinking about platform unless you depend on such libraries. If swallow will have to be compiled each time for platform then it looses that perspective. Note that not all Python apps are written to use AI stuff or something depending on heavy calculations so they don't care about this and enjoy "write once move anywhere" to some extent. Again not saying it's preventable in all cases but if you completely loose that part of the Python then you loose specific group of devs.
Cool, and let's say I'd want to use it for developing games, can I "link"/integrate a c lib like glfw and compile to webassembly?
This site is so amazing, This sites gives good knowledge of python , This is very helpful for me.Here all content so useful and helpful for beginner.