I'm a Python guy, but there are lots of things about JS that make me jealous. For example, the main implementations are quite fast, and the tooling is good. In Python, there is Pypy which doesn't get enough investment, or CPython where your only optimization lever is "rewrite it in C!". TypeScript also seems quite a lot nicer/less-broken than Python's mypy. Lastly, I like that JS has actual, multi-expression lambdas and a pleasant syntax.
Some things are more pleasant in Python--everything is sync by default, there's less churn, the standard library gets me a lot farther, it's less permissive (no 'undefined is not a function' nor '!= vs !=='), etc. Both languages serve similar niches well, but the feeling I get is that JS is quite a bit faster and nicer for IO-heavy workloads (JS just has a more mature async story than Python) while Python is generally more intuitive and perhaps better for general application development. But for most things, one isn't dramatically better than the other, and they're both a good deal more disappointing than Go. :p
2 or 3? Or all of the problems that come with choosing between the two (no, it is still not an easy choice).
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 unhelpful, etc.
Exceptions everywhere, for control flow even - iterators are implemented with exceptions.
Absolutely AOT unoptimizable. Pypy's cool, never got it working for my use case. In theory a JIT could help.
Speaking of calling out to C... you think you're writing in a memory safe language, but actually, you're writing in a memory safe language that's probably been hollowed out and replaced with a fast C implementation. But it's actually worse
Exploiting C code loaded by Python is like exploiting C code from the 1990s.
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.
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.
I could really just go on and on and on, but at some point it just feels mean.
Huge respect for the project and the team but Python has made mistakes (as all languages do). They were understandable mistakes, but they were mistakes. It's fine for some things, but there's plenty wrong with it, just like there's a ton wrong with javascript. But javascript gets probably 1000x the flack.
> 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.
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.
"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.
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)?
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.
> Buts it's especially terrible because it was designed by a guy without much language expertise in a handful of weeks.
The core isn't too bad; I'd argue that the main reason why it's hard to work with is because you don't have tight control over your execution environment, mostly since the language wasn't really standardized until pretty late. It also solves a much different problem than most languages since it has to optimize for better UX (not crashing the whole program on exceptions, for example).
Aww, no clever name or the JS services?