Always go back to python (and c) when in doubt. Problem is graphic user interface. TK, ... or even pythonista scene. So diverse and so non-standard.
Pyston v2: Faster Python
161–170 of 211 posts
Re: Pyston v2: Faster Python
#162Earlier quoted context omitted.
Go and Python have pretty minimal overlap IMO. If you are using Python for anything other than a server or CLI, Golang is not a very good replacement for Python. Some of Python's strengths that I work with regularly are dynamism, easy data exploration, visualizations, succinct & customizable syntax, extremely strong data science libraries, REPL/Jupyter, C bindings, easy to use packaging solution via PyPi (bet some pe…
Julia covers your use cases and overwhelmingly fast.
Possibly - I'm keeping my eye on it. But I can't stand the matlab-esque syntax.
Re: Pyston v2: Faster Python
#163Earlier quoted context omitted.
> 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…
I'll be honest, as someone whose non-Python programming (paltry as it is) is mostly done in statically-typed functional languages, I have a bit of a bias against Go for the whole generics thing. I'll give it a closer look at some point.
I understand; lots of people have this sentiment. It’s an inconvenience in many cases, but we’re comparing it against Python, which has no type safety at all much less generics (apart from Mypy, which has many, many other issues).
Re: Pyston v2: Faster Python
#164Earlier quoted context omitted.
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…
So who does it right? If all these APIs suck compared to an imaginary perfect library, then that isn’t a useful comparison. Also, if an endpoint is spending minutes to respond, then I would think actually profiling the application would be a good start. Maybe researching prior art in the problem domain would be good too. If nobody can be bothered to explore the several solutions to distributing pandas computations ov…
That’s quite a rant with a lot of assumptions. Just about every library has a better API than matplotlib or pandas. Requests has a pretty good API IMO. The team who was responsible for the slow endpoint did investigate dask and alternatives, and they probably will end up on something like spark because they didn’t feel like they have better options. Maybe our team is just stupid and Python isn’t for mere mortals, I don’t know, but I do know that these problems don’t exist in other languages.
Re: Pyston v2: Faster Python
#165I thought this project was dead. Nice to see it’s alive.
Re: Pyston v2: Faster Python
#166I feel like anybody really searching for speed is using something other than Python. I don't use Python for speed, but for ease-of-use. It took me some clicks to see it's supposed to be a drop-in replacement, so that's good.
It is not about searching for speed. It is about lowering the cost of large Python code base running in production.
Re: Pyston v2: Faster Python
#167Oh really?
Re: Pyston v2: Faster Python
#168I feel like anybody really searching for speed is using something other than Python. I don't use Python for speed, but for ease-of-use. It took me some clicks to see it's supposed to be a drop-in replacement, so that's good.
Why not make the languages that are easy to use speedy? That way I don't have to search for one or the other.
Re: Pyston v2: Faster Python
#169Earlier quoted context omitted.
Python is a welcoming community, but they are decidedly not welcoming of contributions that significantly increase the complexity of the CPython reference implementation. This has been discussed extensively: https://news.ycombinator.com/item?id=11125769
This is why I see little hope for Python, which is to say that while I'm sure it will continue to have a large following for many years a la C, C++, etc, I don't have hope for it being an exciting language or one that is particularly productive. Python already has performance and packaging problems which don't seem to be easily divorced from CPython, since virtually the whole reference implementation is depended upon…
I'd be curious which languages you feel are closing the gap, and which gaps are getting closer by them.
For example, I do a bit of Swift in addition to Python, and sometimes I've heard people try to compare the two. But I vastly prefer Python to Swift when I can afford to.
Re: Pyston v2: Faster Python
#170Earlier quoted context omitted.
it's _still_ essentially the same switch(opcode) based interpreter it was 20 years ago. no threading, no super instructions, no jitting, nothing. https://github.com/python/cpython/blob/master/Python/ceval.c...
> no threading, CPython does use threads (on Linux, it spawns one pthread per Python thread). However it also has a lock (the infamous GIL) that prevents those threads from interpreting Python code simultaneously.
Not that. https://en.wikipedia.org/wiki/Threaded_code
It's an interpreter implementation technique.