WRT performance ceiling, I'm mostly talking about things like Pandas which eagerly evaluate and which aren't amenable to a parallel execution model (multiple threads operating on the same data frame with minimal contention). WRT poor APIs, I'm talking about things like matplotlib or pandas or etc that take a whole slew of arguments and try to guess the caller's intent by inspecting the types of the arguments. The ref…
"Based on prototypes I [spent a limited amount of time on and didn't research better methods], I'm confident..."
In the context of pandas, 3 GB of (raw, uncompressed) data could easily require 30 GB of RAM, and that kind of overhead adds up quickly.
> I'd love to find a viable competitor to Python that's strictly better than it. I strongly recommend Go as a better Python. Personally, I think it's easier to write than Python (although people who care very little about correctness will be bothered a bit by the type checker), and the tooling is many times better (single-binary deployments, great dependency management, etc are awesome). Also, the performance is abou…
What's Go like for REPL-driven / exploratory development? That's mostly how I use Python.
Go has nothing on Python in this regard. I write Go every day, and come from a Python background. I often describe Go as the strongly-typed, more performant version of Python. I say this mostly because my Go code isn't too dissimilar from my Python code (structure, naming, packages). But I still drop into Python if I want to do something quickly. I don't really know why. Maybe it's the Go tooling, e.g. unused variables cause compilation errors, so things like this slow me down. Or maybe it's because Python just offers _so_ much out of the box, e.g. all the data structures you'll ever need (list, set, dict, tuples), and all small things you take for granted (like writing "is a in list", which would require a function in Go). The REPL is Python's killer feature.
>I don't get why people object to performance work on languages not intended for performance. It's simple, really. They're concerned about the trade-offs.
If it's in a fork that you can pretend doesn't exist if you don't want it... what is the trade-off?
A fragmented ecosystem, incompatibilities, etc.
And more importantly, your original question isn't asking about forks, specifically. It was asking why someone might oppose performance work.
> I don't use Python for speed, but for ease-of-use. Right - but if you can get that with better performance that's good isn't it? I don't get why people object to performance work on languages not intended for performance.
> I don't get why people object to performance work on languages not intended for performance My gut feeling is that Python is just not safe or static enough to ever be worth trying to compete with (say) C++ with. Python sure is easy but I think the asymptotic cost of using it for a big project (in my hands at least) is just not worth it. I like Python's syntax quite a bit but I feel bad watching people learn to prog…
As someone who learned on python (many years ago), I think the balance of being allowed to shoot myself in the foot, while only having to learn complexity when complex concepts came up, was a good combination rather than a bad one. Trying to learn C++ and Java before, having to type everything was an impedement. On python, you find out that types still matter when you try to add a string to an integer, for example. The moment the type matters to you is when you need to dig into those details. I'm not sure I would have the career I do if it hadn't been around to be the one language that fit my 16-year old brain.
If it's in a fork that you can pretend doesn't exist if you don't want it... what is the trade-off?
A fragmented ecosystem, incompatibilities, etc. And more importantly, your original question isn't asking about forks, specifically. It was asking why someone might oppose performance work.
Wanted to see redistribution rules, and was surprised to see there is no license anywhere for the binaries...
The closest thing I found is "copyright" file inside .deb:
Copyright: 2020 The Pyston Team
License: Closed source, all rights reserved.
I guess it means no one should be touching the file, as they haven't even granted access to run it.
20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching. The Python language is already 30 years old, and it wasn’t even the cutting-edge in imperative language design ( Smalltalk, Lisp ) back then. It’s positively antiquated now. I’ve never understood this tunnel-vision obsession with endlessly chasing ever-diminishing returns. It’s Zawinski's Law of Software by way of G…
Interesting that you are down voted. I agree with you that 20% faster is really nothing in comparison to the many new languages. I was saddened by the path Python3 chose. If compatibility was already broken at the time, they should have designed something with performance in mind from the beginning. The V8 javascript engine was there. We knew things could get >10X faster with JIT. Python is too big to die, but it is…
“Interesting that you are down voted.”
Doesn’t bother me; I’ve got points to spare.
What downvoters haven’t got, it seems, is any arguments.
Depends on your scale. If each of your web servers has a hand picked name, definitely not. But if you stopped naming servers a long time ago, and if the pricing structure is favorable, it could mean a huge cost saving without an expensive rewrite.
What does it have to do with naming servers, can you explain? Or do you mean if you have very few servers such that you can name each and every one of them, this wouldn't be worth it?
Pretty much. If you’re spending $1000/month on servers, you’d only save Rewriting in a more efficient language might seem even cheaper, but you have to factor in risk and opportunity cost. At some point it does become smarter to rewrite, but your app needs to be pretty simple or your server bill pretty huge before it’s actually the best option.