Sometimes I really wonder what Google has against Ruby.
Grumpy: Go running Python
361–370 of 463 posts
Re: Grumpy: Go running Python
#362Earlier quoted context omitted.
That means nothing. Python 3 was also expected to be mainstream by 2015, but it's nowhere near even 30% yet.
It's mainstream for new projects. Which is what was expected and aimed for.
Citation needed. Most companies I know that have 2.7 older projects also do new projects in 2.7. They don't want to introduce 2 different versions of the language, set of dependencies etc to their production.
Re: Grumpy: Go running Python
#363"So we asked ourselves a crazy question: What if we were to implement an alternative ?" As always with Google... What if you humbly contribute to open source projects rather than creating new stuffs, labelled with your own brand, controlled by your own engineers, and with your own design choices, however good they may be ?
They tried that with CPython, it didn't work: https://www.python.org/dev/peps/pep-3146/
But it was no fault of Python: https://qinsb.blogspot.nl/2011/03/unladen-swallow-retrospect...
Re: Grumpy: Go running Python
#364Earlier quoted context omitted.
> Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. Basically, we needed to support a large existing Python 2.7 codebase. See discussion here: https://github.com/google/grumpy/issues/1 > It's a hard-code compiler, not an interpreter written in Go. That implies some restrictions, but the documentation doesn't say much about what they are. PyPy jumps through hoops to make a…
Is there not a single namedtuple in the entire Google codebase? That's strange :o
There are some defined in built-in modules. Even in Python 2.7, where sys.version_info is a namedtuple.
Re: Grumpy: Go running Python
#365Earlier quoted context omitted.
> Given that there are only 7.5 billion humans on the planet, and that rather significantly fewer than 1 in 20 people are PyPy-using developers, perhaps those numbers should be taken with a grain of salt? Those are not downloads of PyPi, but of packages. It's not like "number of downloads == number of individual developers". Those are packages, including package updates. A single developer can download 50 deps across…
> A single developer can download 50 deps across his codebase, and update them to later versions 2-3 times a year. As if individual developers are the reason behind the bulk of the downloads. I wonder how many downloads Travis alone counts for? Your hate of Python 3 in every discussion about it is frankly baffling.
>As if individual developers are the reason behind the bulk of the downloads. I wonder how many downloads Travis alone counts for?
Travis runs/tests user projects, so there's nothing about it that's especially partial to Python 2 over Python 3.
>Your hate of Python 3 in every discussion about it is frankly baffling.
Or, you know, my pragmatic assessment of its popularity.
That you'd even use the word "hate" (when in fact, I like Python 3 over 2.7, even if its mostly tame updates over what 2.7 offers) shows that you're probably too partisan. I was enthused with Python 3 even when it was only a vision called Python3K back in 2000-ish. My personal preference has nothing to do with whether I see more people using it or not.
The situation is not unlike the perennial "next year is when Linux dominates the desktop", which has been every year since 1999.
Re: Grumpy: Go running Python
#366Earlier quoted context omitted.
While python2 may be the past, I think that for many python3 is not the future.
Highly depends on the use case. Python 3.5 with uvloop+sanic can be faster than node.js without any JIT: https://github.com/channelcat/sanic#benchmarks
Still slower than OCaml, Haskell, Java or .NET.
Re: Grumpy: Go running Python
#367Earlier quoted context omitted.
GVR, the PSF and the core dev team overestimated their influence. They still truly believe the majority will come around to Python3. I agree with your sentiments and balkanization is the right word. Guido won't even read these comments. He thinks it's all some unjust slander and nonsense that will be forgotten in 3 years. :) It is a good time to jump off the Python train in general, and I say that as someone invested…
Both my workplace and the one big open source project I use homeassistant all use python 3. Do you have any data to backup python 3 adoption being a failure? I know it was certainly painful for many years. As a python 3 user everything seems fine on my end. Though 3 has its own new warts. They are smaller and more forgivable warts for now but its probably not a good sign. I do agree the direction python is heading is…
We try to use Python 3 at work but have to run Python 2 as well because there are still packages that weren't upgraded and it's too much working re-writing them all for no direct benefit.
We also have third party vendors that only support Python 3 in experimental versions, and there not even recent versions (Bloomberg is a great example).
I really like Python3 features, but the pain of using them drives me towards using other languages. I hope Julia will be stable and mature enough soon so that I can dump Python all together. I really like Julia, but currently the changes in the languages are too fast and there are constantly incompatibilities with packages that don't update fast enough. But I'm reasonably certain that this will be fixed once they reach 1.0.
I'm sure Python is far from dead, but can imagine that Julia has the potential to kill it in many domains.
Re: Grumpy: Go running Python
#368Earlier quoted context omitted.
It seems likely to me that Rust is your better C++. I'm also quite positive that there is (more than) enough oxygen for Rust to succeed. As for D, I think it has numerous other issues, that don't apply to Rust.
The stuff I've done in C++ would have worked as well or better in a language with garbage collection. On the other hand if you want to write the next OS kernel, then you need a "better C++" that is designed to work without GC. In the latter case, I think there is no question that Rust is your best bet today. I'd like a programming language that is statically compiled, with good performance, garbage collection, and de…
> I'd like a programming language that is statically compiled, with good performance, garbage collection, and decent support for abstraction.
It feels like you're mixing actual requirements (like "good performance" and "decent support for abstraction") here with things that are more like implementation details ("garbage collection", "statically compiled"). I don't really understand why you want "garbage collection", as such, though I could understand wanting some kind of increased productivity from not having to think about memory management. However, if your real requirement is as I describe it here, then I would still contend that Rust fits the bill.
Re: Grumpy: Go running Python
#369Question: better threading performance seems to be the main motivation for this project. Could they not just use multiprocessing instead of threading for the cpu-heavy parts of the YouTube codebase, and threading or asyncio for the io-bound parts of it?
Edit: for example, the fib benchmark they cite is cpu-bound. If the python code used multiprocessing, the performance would scale almost linearly with the number of processes.
Re: Grumpy: Go running Python
#370+1 to cooperative multitasking