3 ms·

Preface: I don't just want to crap on Python here and sell Nim. I like Python, and still use it. But it still shocks me just how much money and manpower is thr

Preface: I don't just want to crap on Python here and sell Nim. I like Python, and still use it. But it still shocks me just how much money and manpower is thrown at trying to bikeshed and optimize and compile Python and its libraries, while the Nim compiler is essentially a community hobby project that has made the concept of a "compiled Python" a reality already. The orders of magnitude in scale difference, and the qualities of the output products, are staggering. I'm kind of starting to see what Guido is talking about when he says Python is a legacy language that's probably on its way out. Even in the interpreted world, languages like Janet and other newcomers are performing fascinating experiments, often doing more with less.

RayVR 4y ago
A lot of effort is dedicated to trying to improve the speed because python is so widely used that improving performance could have a massive beneficial impact. Migrating to a new language is not easy when you have millions of lines of code.
- netbioserror 4y ago
  I didn't say that anyone should switch (see my preface), and I perfectly well understand this point. Having to retread this point over and over just serves to make our comments long and redundant and full of qualifiers, but I guess here we are again.
  - RayVR 4y ago
    You said you don’t want to “crap on python” which I never said you were. I’m simply pointing out that what you’re “shocked by” makes complete sense if you look at what can be gained by people “bikeshed and optimize and compile python”
- dgb23 4y ago
  But is this still really python? This compiler and others are not a drop in replacement. They typically cover a narrow subset and/or need additional code/hints etc. You can adopt it incrementally, but then you could just as well switch to a language with higher default performance, more language features that just work, unified tooling etc. and adopt that incrementally?
prirun 4y ago
> while the Nim compiler is essentially a community hobby project that has made the concept of a "compiled Python" a reality already. I checked out Nim a few years ago because I have a large Python project that I'd like to move to a compiled language. In my experience, if you get on the forums and do any kind of comparison between Python and Nim, you will quickly get responses of "Nim isn't Python, so quit trying to make it like Python". I think Nim would have been much more successful if it was more like Python, and if Python compatibility was one of its goals. Just as an example, a subrange a..b in Nim is closed on the right, unlike Python, and a..<b is the open Python version. They could just as easily have made a..b open and used a..=b for the closed interval, for Python compatibility. I'm not saying Nim had to be the perfect Python compiler and compile all Python code unmodified. Based on what I've read, Python is too dynamic for this. But in cases where there was the choice to either be compatible with Python or "do something unique", Nim often takes the unique path, and not always for any good reason IMO.
ActorNightly 4y ago
>I'm kind of starting to see what Guido is talking about when he says Python is a legacy language that's probably on its way out. Even in the interpreted world, languages like Janet and other newcomers are performing fascinating experiments, often doing more with less. Wow, what a way to mischaracterize what Guido said. His point was about languages evolving to be more abstract than Python or any of the ones you mentioned. Programming is going to become more and more abstract to the point where you will be able to program in natural language through speech. In the mean time, we still have to write code manually. And look, there are plenty of valid criticisms of Python, but you are kidding yourself if you don't think its going to be one of the primary languages of the future. There is a reason why it has the 2nd most gihub repos (behind JS, because of hard dependency on it for web stuff). And the simple reason is this: the vast, vast majority of applications don't need the fastest possible speed, its much more important to be able to develop fast, and have it be right. Its easier and cheaper to throw another EC2 instance in your stack rather than pay a developer to write stuff from scratch whereas in Python you can just import the relevant library for your needs and be up and running much faster, not only the short concise syntax used, but also the introspection into the running language because of its interpreted nature. And this allowed the snowball effect to happen, where developers could quickly write relevant libraries, which in turn allowed other developers to quickly import those libraries and write their libraries, slingshotting Python into a language that is used not only for bleeding edge ML stuff but to run backend web stacks with no issues. And in the cases where you do need speed, this is where these compilers come in, and its a 100% valid use of manpower and money. Think of it as another library. Every other language that focuses on things like static typing, whatever type of inheritance the designers think is best, memory safety, and all the other theoretical CS stuff completely misses the above point, and for that reason alone, it will never become mainstream. Rust is not going to happen, Nim is not going to happen, Julia is not going to happen, Scala is not going to happen, Elixir is not going to happen. Sure, there will be a significant amount of code written in those, but the popularity will never come close to Pythons. You may not like it, but you know this is true. We have already seen this cycle happen with Haskell where functional programming was the next best thing. you would constantly see posts about it at the same frequency you now see posts about Rust, and look where Haskell is now.
- 4y ago

RayVR 4y ago

A lot of effort is dedicated to trying to improve the speed because python is so widely used that improving performance could have a massive beneficial impact. Migrating to a new language is not easy when you have millions of lines of code.

netbioserror 4y ago
I didn't say that anyone should switch (see my preface), and I perfectly well understand this point. Having to retread this point over and over just serves to make our comments long and redundant and full of qualifiers, but I guess here we are again.
- RayVR 4y ago
  You said you don’t want to “crap on python” which I never said you were. I’m simply pointing out that what you’re “shocked by” makes complete sense if you look at what can be gained by people “bikeshed and optimize and compile python”
dgb23 4y ago
But is this still really python? This compiler and others are not a drop in replacement. They typically cover a narrow subset and/or need additional code/hints etc. You can adopt it incrementally, but then you could just as well switch to a language with higher default performance, more language features that just work, unified tooling etc. and adopt that incrementally?

prirun 4y ago

> while the Nim compiler is essentially a community hobby project that has made the concept of a "compiled Python" a reality already. I checked out Nim a few years ago because I have a large Python project that I'd like to move to a compiled language. In my experience, if you get on the forums and do any kind of comparison between Python and Nim, you will quickly get responses of "Nim isn't Python, so quit trying to make it like Python". I think Nim would have been much more successful if it was more like Python, and if Python compatibility was one of its goals. Just as an example, a subrange a..b in Nim is closed on the right, unlike Python, and a..<b is the open Python version. They could just as easily have made a..b open and used a..=b for the closed interval, for Python compatibility. I'm not saying Nim had to be the perfect Python compiler and compile all Python code unmodified. Based on what I've read, Python is too dynamic for this. But in cases where there was the choice to either be compatible with Python or "do something unique", Nim often takes the unique path, and not always for any good reason IMO.

ActorNightly 4y ago

>I'm kind of starting to see what Guido is talking about when he says Python is a legacy language that's probably on its way out. Even in the interpreted world, languages like Janet and other newcomers are performing fascinating experiments, often doing more with less. Wow, what a way to mischaracterize what Guido said. His point was about languages evolving to be more abstract than Python or any of the ones you mentioned. Programming is going to become more and more abstract to the point where you will be able to program in natural language through speech. In the mean time, we still have to write code manually. And look, there are plenty of valid criticisms of Python, but you are kidding yourself if you don't think its going to be one of the primary languages of the future. There is a reason why it has the 2nd most gihub repos (behind JS, because of hard dependency on it for web stuff). And the simple reason is this: the vast, vast majority of applications don't need the fastest possible speed, its much more important to be able to develop fast, and have it be right. Its easier and cheaper to throw another EC2 instance in your stack rather than pay a developer to write stuff from scratch whereas in Python you can just import the relevant library for your needs and be up and running much faster, not only the short concise syntax used, but also the introspection into the running language because of its interpreted nature. And this allowed the snowball effect to happen, where developers could quickly write relevant libraries, which in turn allowed other developers to quickly import those libraries and write their libraries, slingshotting Python into a language that is used not only for bleeding edge ML stuff but to run backend web stacks with no issues. And in the cases where you do need speed, this is where these compilers come in, and its a 100% valid use of manpower and money. Think of it as another library. Every other language that focuses on things like static typing, whatever type of inheritance the designers think is best, memory safety, and all the other theoretical CS stuff completely misses the above point, and for that reason alone, it will never become mainstream. Rust is not going to happen, Nim is not going to happen, Julia is not going to happen, Scala is not going to happen, Elixir is not going to happen. Sure, there will be a significant amount of code written in those, but the popularity will never come close to Pythons. You may not like it, but you know this is true. We have already seen this cycle happen with Haskell where functional programming was the next best thing. you would constantly see posts about it at the same frequency you now see posts about Rust, and look where Haskell is now.

4y ago