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. 🙏Ok 👍👍
I came here to say this. With python already supporting a syntax for types there isn't much point rolling your own.
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?
Yes I know about nim but there are some diffrences like this project tries to replecate the good things of python and C but nim even if inspired by python does not try to replecate python
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.
We have other languages because of this
We didnt ask you to take risk. We are taking
Obviously the project doesn't affect me in any way.
I simply believe that greater things can be achieved when great minds work on common goal.
Good luck with the project!
Let them do whatever they want with the project. Let's wait and see whether the outcome and improvements of the project benefits us over time. By the way, the fact is, in most cases especially in our technology domain, great minds (even if they have common goals) don't work together. If it happened, we would have not got different programming languages, operating systems and so on. The goals might change over time. It's better we let them do whatever they want as long as the outcome of their work is going to benefit everyone in the niche. And, although Nim and swallow seem to have common goals for now, we don't know what other goals the swallow team has in its list. They might come up with some additions and improvements over time.
Why doing a todo app in react since there's so much todo app... I'm pretty sure the main idea behind Swallow/Peregrine is to do something they want to, they are passionate about and they will be proud.
It's normal to talk about want you're proud of, maybe it is the same thing than Nim, but if you dont make a programming language, you'll never know how to make one... and if it's what they want to learn, this is a great way to do it!
Is this programming language have a futur? Only the futur will tell you
Are the programmers behind that have a futur? Clearly, they are passionate, will learn a lot, want to give to the community, 10/10 they have a future.
And if a beginner want to contribute to this project, it could be easier to him since it's in an early phase and could be easier to understand.
This is not a company looking to take over part of a market, this are individuals looking to learn and share.
So go! Follow your passion and your goal!
The second reply in this thread already expressed the same idea:
looks very interesting
did you develop a GC or how are you handling memory?
For memory management, our plan is to use auto-free where the compiler will insert free calls wherever necessary
I know it is going to be difficult
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...
Just the programming language that python programmers needed for competitive programming. Can you please ensure if swallow is supported by online judge
I dont think that they will disqualify swallow but please note that this language is still not complete
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?😅
Both of them have diffrent goals
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
Well the library that run on a single platform in python will run on a single platform on swallow as well
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.
Ethan please change the name if you only know that naming is important.
Please change it Rubik I love ruby since Ruby is dynamic if you add it the letter K will signify as for statice type language
Like Ruby(dynamic typed) Rubik or Rubyk(static typed).
We are discussing name changing right now
Since the comparison, I would have call it Cobra XD.
But yeah you need a name and file extension that are marketable.
Because swallow is not marketable like , Shawshank redemption the movie, everyone agrees the movie is one of the best movies of all time, but the name killed the movie.
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😎
That's the plan
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)
Awesome project! 🙌
thanks!