That said, there are respected programmers who have good criticisms of Python 3[1] that are more level-headed than this sensationalized article; however, that has not stopped the community at large from moving to Python 3 where possible.
Also, as myself and others continue picking up LXC technology (Docker) the issue of host/ops dependencies interfering with project dependencies will gradually vanish—which is the only legitimate point made by the posted article. The title should have been: "My first day with Python 3"
[1]: http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/
Python 3 just doesn't have traction, and it may never get there. It's sort of a shame how Python 2 is now in maintenance-only mode, but on the other hand it's great for professionals: we don't need to worry about the language or the reference implementation changing ever again.
[1] Kenneth Reitz, as part of his excellent talk "Python 2.7 & Python 3: A Sacred Love Story."
I don't really mind moving my own code to python 3, but I'm loath to move working library code.
This has very little to do with Python 3.
All in all it's quite okay, and definitely on the right path.
Ubuntu is a snapshot of Debian unstable, and it's not surprising that shipping cutting edge packages results in a few that are broken.
Which is the point of the article and P3's biggest problem: All the things surrounding it.
The people behind Python seems desperate to push everybody to Python 3, mostly by telling people how much better Python 3 is than Python 2. But the thing is, that doesn't matter when the environment surrounding Python 3 is considerably worse than for Python 2.
Author stumbles upon problems with ubuntu and some other third-party software => concludes that Python 3 is not being used anymore.
Well done, sir.
Ruby was the obvious successor to Perl, rather than Perl 6, but I wonder if Rust ends up being Perl's natural successor. It's fast, there are awesome functional features, and Perl developers tend to be pretty comfortable with the general concept of references... Not going to appeal to the "hack it to get it done quickly" crowd, but as a replacement for bigger Perl 5 projects...
We should be comparing Rust to modern C++, Nim, etc.
I do feel comfortable with your Go / Python comparison, though. Not insofar as intent, but rather in the people that are adopting it and in the places it is being deployed. Golang seems to be carving out an interesting little niche between managed and dynamic languages.
Rust, on the other hand, looks like it can (will?) steal C++1x's thunder. Games, browsers, applications, operating systems... I really want to write new stuff in Rust.
> In the way of purpose and design, Rust has next to
> nothing in common with Perl, Ruby, Python, etc
People choose Python instead of Perl because - and the reason they give may be different, but it comes down to the same thing - there's one RIGHT way to do everything. There's a _pythonic_ way to do everything. PEP 8 not only exists, but people take it _seriously_. Python code is predictable, and while people will bring different engineering approaches to bear on certain problems, good Python looks the same at every company.
Go is the Next Level Up of that. "go fmt" and "go vet" are baked right in. The language is small, and explicitly leaves out certain constructs in order that there is one, clear, obvious way of doing things. In short, Go code is meant to be predictable, and good Go code should look the same everywhere.
If you want to spend your time thinking about the problems, solving the problems, and zero time decorating your art, Python and Go are for you. They are the International Style or architecture, they are Brutalist languages, and that's not only OK, but it's a fundamental part of their success.
Me? I like Baroque.
I like my sigils, I like combining functional and imperative constructs in ways that I think look beautiful as I write them. I like cute tricks, and coworkers can see code I wrote because I come back to my favourite beautiful and intuitive idiomatic patterns over and over again, just as I can identify their code for what they do. I don't think `map` is a dirty word, and I love starting with a list and whittling away at it, sorting it, reshaping it, exercising the differences between lists, arrays, hashes, and the coercions between those.
You go to the back of the Camel book, and it gives you four different code styles, depending on what you're optimizing for. Perl Best Practices is the most controversial book ever written.
I'm still a Rust baby, but I'm telling you, it TASTES like Perl. The language "features" thing is reminiscent of someone suggesting you shouldn't buy an iPhone based on processor speed.
Uhh, what? I'm not even sure why you're comparing Golang to Python. One is a compiled language that specializes in concurrency and the other is a interpreted scripting language. They're for completely different purposes. Python3 was never intended to be a "one way to do everything language".
Python's motto is "There should be one-- and preferably only one --obvious way to do it." - its not meant that Python should be the only tool, but that written python code should only have one have common implementation. (https://wiki.python.org/moin/TOOWTDI)
Golang also seems to share the same ideal when it comes to written code.
If Go had generics, I'd be inclined to agree with this.
The Python 2 standard library is now showing its age. Limitations with the multiprocessing module on Python 2 drove me to look into the possibility of switching to Python 3 and I was pleasantly surprised to discover all ~45 packages my project depended on had been ported (through caniusepython3.com.)
Porting to 2/3 compatible code with python-future.org turned out to be fairly painless so I expect to make the change soon.
The transition has been a painful one, but I'm sure that these sort of problems will feel a thing of the past in a year or two.
Good to see your post on the front page, and it was a nice writeup. Personally for me the issue with Python 3 has been the lack of support by many good 3rd party Django apps. Until that happens I can't see myself moving anytime soon.
Digressive: "Always wanting to be cutting-edge, I decided I would would start with ubuntu 14.04", shouldn't that be 15.04 then? (latest I could see in the mirrors at least)
Although I'm someone who doesn't develop in python, I have toyed around with the packages and versions for dependencies for other projects and tools I use. At first I assumed that "latest is greatest" but recently came to understand that it's not the case as far as practicality is concerned. Perhaps it is involved with the rather irritating versioning (python3, pip3, etc. - I've found the same thing to be true on archlinux), but I think a lot of it is definitely as somebody else said above, the lack of updated libraries.