4 ms·

> no, it is still not an easy choice Yeah it is, choose 3. Python 2 is reaching EOL. > Mypy coverage, even in the stdlib, is awful. When it comes to thirdpart

> no, it is still not an easy choice Yeah it is, choose 3. Python 2 is reaching EOL. > Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely helpful, etc. Yeah, the typing stuff is a pretty big disappointment. The ergonomics are pretty terrible (probably because they wanted to push as far as they could without introducing more syntax support for typing). Mypy isn't just young, but it's buggy and its codebase was a sloppy mess last I checked. There's no support for recursive types (you can't define a JSON type, for example). And it absolutely falls over in the face of common libraries, like SQLAlchemy, which are too dynamic for it. > Absolutely AOT unoptimizable. Pypy's cool, never got it working for my use case. In theory a JIT could help. Yeah, Pypy is the best hope for Python's performance. They're making great progress, but I also couldn't get it working in our Python 3 codebase (Numpy and Pandas installation issues). > No parallelism. Multiprocessing? Good luck with that - pay the cost of pickling, pay the cost of an additional interpreter, pay the cost of debugging hell. Yeah, this is a real pain point. Some die-hard Python folks say otherwise, but there's really no good parallelism option for lots of workloads. Pickling is just too expensive. > An ecosystem split in two, and don't let anyone tell you otherwise - a few hundred top packages moving over after many, many years, is a sad state for a language that was known for having an absurdly large ecosystem. This hasn't been a problem for me for years. Most things that have seen active development in the last 5 years have good Python 3 support. The only time I've run into a Python-2 only utility, it was 7 years stale. Well, except for Centos's `yum`. These are all reasons I like Go, by the way. Super fast, great tooling, and fairly stable (except for the package management story). I do wish there was a lightweight scripting language with a great VM and real parallelism--something like JS without the inheritance, OO baggage, etc; just objects and arrays and functions running on a JIT VM like V8 but with parallelism as a first-class citizen a la BEAM. And preferably optionally typed from the start, in a way that the runtime could leverage for optimization purposes.

staticassertion 8y ago
> Yeah it is, choose 3. Python 2 is reaching EOL. Easy to say. Tell that to Google and Dropbox - Guido has worked for both and they're on 2. Tell that to the companies that can't afford the creator of the language. 3 is not the easy choice. Anyways, maybe try nim? I've heard good things.
- scrollaway 8y ago
  "2 or 3" wasn't a choice for Dropbox/Google, and even if it had been, it's not a choice that concerns you. All the stuff they produce publicly is Python 3-compatible.
  - staticassertion 8y ago
    My point is that tons and tons of companies, with many billions of lines of code, do not have an easy option. Plenty of the environment still has not moved over even outside of companies.
- weberc2 8y ago
  If you're building something new as the original phrasing implies, choosing 3 is easy. If you need to integrate with 2, then you're in a tougher spot.
scrollaway 8y ago
Re your last paragraph, you're describing Lua. I don't know the state of its coroutines though as I've never used them.
- weberc2 8y ago
  I should have mentioned that "async coroutines" (i.e., goroutines) are also a requirement. Also, I understand that Lua doesn't have much of a standard library and isn't really used as a general purpose programming language (compared to Python, for example)?
  - scrollaway 8y ago
    Your understanding is correct, it's an embedded-first language. It also makes it very hackable which means that I fully believe golang-like goroutines would be achievable in Lua. People hack the `continue` statement into it all the time, it wouldn't be terribly surprising.

staticassertion 8y ago

> Yeah it is, choose 3. Python 2 is reaching EOL. Easy to say. Tell that to Google and Dropbox - Guido has worked for both and they're on 2. Tell that to the companies that can't afford the creator of the language. 3 is not the easy choice. Anyways, maybe try nim? I've heard good things.

scrollaway 8y ago
"2 or 3" wasn't a choice for Dropbox/Google, and even if it had been, it's not a choice that concerns you. All the stuff they produce publicly is Python 3-compatible.
- staticassertion 8y ago
  My point is that tons and tons of companies, with many billions of lines of code, do not have an easy option. Plenty of the environment still has not moved over even outside of companies.
weberc2 8y ago
If you're building something new as the original phrasing implies, choosing 3 is easy. If you need to integrate with 2, then you're in a tougher spot.

scrollaway 8y ago

Re your last paragraph, you're describing Lua. I don't know the state of its coroutines though as I've never used them.

weberc2 8y ago
I should have mentioned that "async coroutines" (i.e., goroutines) are also a requirement. Also, I understand that Lua doesn't have much of a standard library and isn't really used as a general purpose programming language (compared to Python, for example)?
- scrollaway 8y ago
  Your understanding is correct, it's an embedded-first language. It also makes it very hackable which means that I fully believe golang-like goroutines would be achievable in Lua. People hack the `continue` statement into it all the time, it wouldn't be terribly surprising.