Codon Looks Very Promising For Super-Fast Python Code

[Barnacle]

I'm guessing you haven't been on this website in the last 4 or so years, Rust is already in Linux

I guarantee you that zero lines of Rust code are executing on the Linux kernel system I am posting this from, and I'll even guarantee that none are running on yours. But good to know that you are all in on participation trophies.

...and several companies have rewritten their Go code in Rust.

It's not reached it's full potential yet, but it's largely replaced Go as an optimized server component, so it's at least already taken over that field, and it's on it's way to becoming the definitive new way to write device drivers. It's certainly showing no sign of slowing down.

Tell me all about what got replaced, because I am willing to bet it's almost nothing of significance. The biggest "win" to date was NPM server components getting re-written in Rust from Node.js, but I expected nothing less from the people who thought using Javascript as a back-end language was a good idea.

Not to mention how dismissive that "14 year" statement is. It was nothing more than an obscure experiment for the first ten. People only really started to take note of it about 4 years ago (which is around when it hit 1.0), so thats actually some pretty explosive growth.

Nope. The history of Rust is getting invented by Mozilla and used in Firefox, which it pretty much tanked Firefox. Firefox got slower and less featureful when Rust was introduced ("Quantum" update), and they called it progress. Then the Ruby community jumped in circa 10 years ago and brought all of their wacky ideas about programming, more proof that reasonable people shouldn't use it. Then the rest of the history is Rust fanboys, mostly former Ruby fanboys who should be banned from programming, running all over the internet demanding that everything be re-written in Rust.

[Ironmask]

What C has going for it is that the core language is extremely low level and properly separates any interaction with the OS kernel from the core language. I would be open to an "improved, modern" replacement for C, but only if it keeps everything that is good about C, and maintains excellent compatibility with C, since the OS is written in C and even POSIX standard states the OS is to be written in C. Thus far, every language attempting to replace C has failed at this, and AFAICT the language designers never even figured out the reasons why, because they didn't properly understand the thing they were attempting to improve upon.

It's largely because of the ABI. C's ABI is painfully simplistic, but also universal. Other languages don't even bother defining an ABI because that pretty much means your language is now completely cemented and can't really be changed anymore, which pretty much flies in the face of the very concept of linguistics, a field that tracks an ever-evolving concept. That's why so many alternatives to C pop up, because people's ideas and values change, and C does not. The only problem with that is then you get runaway amalgamations with no standard ABI like C++.
There are attempts to make new, stronger universal ABIs for languages to adhere to, but it's kind of under the radar. Most people are just focusing on tools that translate C APIs to other languages, and thats primarily where efforts are headed.

I've written it in another post in some other thread, but the reason nobody replaced C yet is because every language sucked. C++ sucks (just read Torvalds' rants on it), and no other language is even meant to be low-level, all requiring some huge runtime or GC or exceptions or other silly things. Rust is, somehow, the first unique low-level language to finally fit a gap that hasn't been filled in the last 50 years. It's why you now see it being included in nearly every major C/C++ codebase where no other language has ever done that.

Rust had even wackier ideas and went full-C++ right from the start, and has yet to really find a niche in anything 14 years later other than "Pacman, but written in Rust!" Github projects.

I'm guessing you haven't been on this website in the last 4 or so years, Rust is already in Linux and several companies have rewritten their Go code in Rust.
It's not reached it's full potential yet, but it's largely replaced Go as an optimized server component, so it's at least already taken over that field, and it's on it's way to becoming the definitive new way to write device drivers. It's certainly showing no sign of slowing down.

Not to mention how dismissive that "14 year" statement is. It was nothing more than an obscure experiment for the first ten. People only really started to take note of it about 4 years ago (which is around when it hit 1.0), so thats actually some pretty explosive growth.

[Barnacle]

But also, C itself can be optimized a lot. What do you think an optimizing C compiler is? It has to use human intuition to find common patterns in code and rewrite them into a more optimized version.

This is far from the whole story. CPUs themselves are optimized for C code, down to the ISA. Your favorite vector instruction is probably designed to accelerate a particular function in the C standard library.

Yeah, if you're a genius or a savant you can do that manually, but most people write inefficient C code and let the compiler try (and sometimes fail and introduce bugs) to optimize it.

The people who are not a "genius or savant" should probably just stick to Javascript. It's not some inherent gift to be able to optimize C code properly, but it requires putting forth the effort to attain a base knowledge of how CPU, memory and OS work. If we stop asking developers to know these things, it's just going to result in worse developers who think optimizing their own code is the compiler developer's job. Those same lazy people won't be able to figure out how to properly use C very robust and mature tools for debugging, optimizing and profiling code anyway, so they should just stay away from C, because they won't have a good time with it.

There are countless computer science theories and experiments for making good programming languages that optimize themselves instead of trying to make a bloated compiler trying to mimic human intuition. Rust for example lets the compiler know a lot of extra things about a program as a fact, instead of trying to "guess" what a C program is trying to do, due to lifetime annotations.

Academics gonna academic... Meanwhile, in the real world...

I don't know if you think like this or not, but just an aside, I find it so disappointing this cult of "C is performance incarnate, no other language can compare" is so prevalent. People need to realize C isn't a magic spell, it compiles to machine code like any other language. All optimizations are how well the tools are made and how smart the tool user is. Tools can always be improved, it's literally cult behavior to imply they can't. C is not the Messiah, it's a tool that can, should, and will be replaced by a better one, because we are human beings and we evolve.

What C has going for it is that the core language is extremely low level and properly separates any interaction with the OS kernel from the core language. I would be open to an "improved, modern" replacement for C, but only if it keeps everything that is good about C, and maintains excellent compatibility with C, since the OS is written in C and even POSIX standard states the OS is to be written in C. Thus far, every language attempting to replace C has failed at this, and AFAICT the language designers never even figured out the reasons why, because they didn't properly understand the thing they were attempting to improve upon.

Golang was pretty close to being a decent language, but they messed up by having horrible interop with C, and the lack of separation between the OS kernel and the core language. Thus Golang became a niche language for web services, and not something that could ever take on C as the language that makes the computing world go round. Rust had even wackier ideas and went full-C++ right from the start, and has yet to really find a niche in anything 14 years later other than "Pacman, but written in Rust!" Github projects.

[Ironmask]

Yeah, that is totally valid. I'm just lamenting the amount of over-engineering that goes into a lot of languages that think they are going to take on C in performance, while simultaneously dumbing down the language and "auto optimizing" performance.

Most languages, specially a Python-derived one, do not have any goals or intentions of targeting C-level performance. C-level performance is something you consider at the very beginning stage of engineering a language and it's runtime. This is just trying to get Python to go as fast as it can possibly go, which will never match C, but it can definitely be improved from the abysmal design of CPython.

But also, C itself can be optimized a lot. What do you think an optimizing C compiler is? It has to use human intuition to find common patterns in code and rewrite them into a more optimized version. Yeah, if you're a genius or a savant you can do that manually, but most people write inefficient C code and let the compiler try (and sometimes fail and introduce bugs) to optimize it. There are countless computer science theories and experiments for making good programming languages that optimize themselves instead of trying to make a bloated compiler trying to mimic human intuition. Rust for example lets the compiler know a lot of extra things about a program as a fact, instead of trying to "guess" what a C program is trying to do, due to lifetime annotations.

I don't know if you think like this or not, but just an aside, I find it so disappointing this cult of "C is performance incarnate, no other language can compare" is so prevalent. People need to realize C isn't a magic spell, it compiles to machine code like any other language. All optimizations are how well the tools are made and how smart the tool user is. Tools can always be improved, it's literally cult behavior to imply they can't. C is not the Messiah, it's a tool that can, should, and will be replaced by a better one, because we are human beings and we evolve.

[Barnacle]

Some are using python for rapid prototyping and rewrite in C/C++ later with great success.

Yeah, that is totally valid. I'm just lamenting the amount of over-engineering that goes into a lot of languages that think they are going to take on C in performance, while simultaneously dumbing down the language and "auto optimizing" performance.

[slalomsk8er]

I'm not a fan of these Python compilers. Python is a great language for developer productivity, but the limitation is when you need ultimate level performance, at which point you can either augment with Python C modules API (which also have limitations), or just use C or C++ to write your entire application. If your developers are not smart enough to be productive with, and write something stable in C or C++, I have to question if you really need "close to metal" performance at all.

Some are using python for rapid prototyping and rewrite in C/C++ later with great success.

[Barnacle]

I'm not a fan of these Python compilers. Python is a great language for developer productivity, but the limitation is when you need ultimate level performance, at which point you can either augment with Python C modules API (which also have limitations), or just use C or C++ to write your entire application. If your developers are not smart enough to be productive with, and write something stable in C or C++, I have to question if you really need "close to metal" performance at all.

[Turbine]

Why do poor syntax programming languages get all the love. Python and Rust has icky syntax, but is all the rage. JavaScript is the cleanest and most logical language I've ever used.

C++ I have a love and hate relationship. Often you can make really nice code. But when a library is introduced or something dynamic - it starts to get messy. Along with a lot of recent additions to the language.

[acobar]

Perhaps you're using the wrong tool for the wrong activity?
I mean, most mundane activities don't need such horsepower and are set up in python in five minutes, something that C/C++ would require hours or days of work.

There are thousands of applications that are wrote in Python and they work perfectly well; of course if you want to implement an mp3/aac/vorbis integer-only audio bitstream encoder, perhaps Python is the wrong tool.

Sorry, but you are totally at miss here. First, it was a comment with a pinch of humor, because some of previous complaints were a bit too harsh on my opinion. Second, even though it was more to make space for a bit of fun, the huge number of reimplementations of simple things we find when needing to import some facilities in Python, is a proof that my comment was not too much off of the reality.

You seem to like and care for Python, that's OK, but because I used to code on Fortran, C and C++, I have a particular perspective and expectations, including performance, about a language that, until now, can't be fulfilled by Python. Right now, every single thing that puts real pressure on computing (and computers) needs to be coded on some other language, usually Fortran or C, and then a wrapper must be construed, and then, a translation layer must be used to send data back and forth, this is really wasteful. But, OK, we have fast computers and plenty of memory.

To be clear, I don't dislike the language, but we need to acknowledge that it has a lot of shortcomings when we think about what a general programming language should offer, even from stability and maintenance POV for the source code of our projects.

Let's see how Codon evolves. Perhaps, it may shuffle and change things a bit.

[blackshard]

I don't know why Python attracts so much negativity, after all, it plays an important role in CS: it is so sluggish when applied to trivial algorithms, that it forces its users to learn better and more complex methods to achieve minimally bearable performance for mundane activities.

Perhaps you're using the wrong tool for the wrong activity?
I mean, most mundane activities don't need such horsepower and are set up in python in five minutes, something that C/C++ would require hours or days of work.

There are thousands of applications that are wrote in Python and they work perfectly well; of course if you want to implement an mp3/aac/vorbis integer-only audio bitstream encoder, perhaps Python is the wrong tool.