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!
Top comments (97)
can you also support
x:intsince you haveint xthoughxcan be inferred. That way all that I'd need to convert python to swallow is main method. 🙏I came here to say this. With python already supporting a syntax for types there isn't much point rolling your own.
The difference between Nim and Python syntax-wise is approximately same as difference between the given examples of Swallow compared to Python. Yes, variable and procedure declaration is slightly different, but type signature syntax in Nim is more similar to Python's compared to Swallow.
The main question here is why is there a need for new programming language, when a very similar, more mature project exists? It would be more fruitful to improve an already existing project and that would bring greater good to programmers looking for Python like C language.
But of course, if the project's main motivation is learning about language design, parsing, compiling and just for fun, then it makes more sense. Since developing and launching a new language is a very challenging and risky task that will take years of maintenance and improvements, and even then it most likely will not get the traction between programmers to stay alive.
I have heard of Nim but to be honest I have not tried it. Seeing swallow, I think it is much more like C. It is as if I am writing C but sugar coated with python. I am writing C using python syntax (This sounds better). That is how I see it. I don't know much about language design, parsing, compiling or the rest but I have used python and JavaScript more as a back-end developer. So looking at Swallow (python-coated-C), it would stay alive, maybe in a small niche but it will still stay alive if it will revolve around python - for that I can say. I stand to be corrected.
Nim also compiles to C, so it's same as Swallow in that manner. Besides Nim is already released language where as Swallow isn't past v1 yet.
Also Nim can compile to JS too.
Nim language project seems to be very similar to your goals.
Have you looked into that project? Wouldn't Nim's metaprogramming engine be able to reproduce the planned features in your project?
Hi there, nice work I really like what your doing.
Just a question is in my mind, why u guys don't work on julia programming language?
It's easy, fast and with a powerful support.
And oh it's already created so u don't have to work from zero right?😅
Just the programming language that python programmers needed for competitive programming. Can you please ensure if swallow is supported by online judge
looks very interesting
did you develop a GC or how are you handling memory?
Given the idea that Python is cross-platform - in the idea where you use Python libs for your own code, how does this compare? I know Python and other languages as well use libraries written in C or Rust or such, then just make interface for such calls which again makes code unusable on some platforms where those dependencies weren't "ported". So I assume you would still have to compile this for each platform you want to run on? The only difference being that now you could write everything in one language and use source includes then recompile everything together where Python libs written for a specific platform "cannot" do this because they pre-compiled for single platform. It's really niche experience and not many libs are like that but still I'm wondering
If Swallow is similar to VLang, it seems great to me, this one is inspired by Go and does not have a production version yet but for what it is doing so far it seems great to me. In this case, if swallow is inspired by Python, it also seems great to me, a language that is compiled, without GC, with auto-free and has the advantages that Python has, would be magnificent. It seems absurd to me to try to compare them at this time when it is just being born.
Quick question Gui and swallow using python libs like tkinter etc... Will this come around with the planed feature of python ecosystem? If so I can see my self adopting this for a project I am working on at the moment😎
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.