Typescript is far nicer than Python though. Well I will give Python one point: arbitrary precision integers was absolutely the right decision. Dealing with u64s in Typescript is a right pain.
But apart from that it’s difficult to see a single point on which Python is clearly better than Typescript:
Static typing. Pyright is great but it’s entirely optional and rarely used. Typescript obviously wins here.
Tooling. Deno is fantastic but even if we regress to Node/NPM it’s still a million miles better than the absolute dog shit pile of vomit that is Pip & venv. Sorry Python but admit your flaws. uv is a shining beacon of light here but I have little hope that the upstream Python devs will recognise that they need to immediately ditch pip in favour of officially endorsing uv. No. They’ll keep it on the sidelines until the uv devs run out of hope and money and give up.
Performance. Well I don’t need to say more.
Language sanity. They’re pretty on par here I think - both so-so. JavaScript has big warts (the whole prototype system was clearly a dumb idea) but you can easily avoid them, especially with ESLint. But Python has equally but warts that Pylint will tell you about, e.g. having to tediously specify the encoding for every file access.
Libraries & ecosystem. Again I would say there’s no much in it. You’d obviously be insane to use Python for anything web related (unless it’s for Django which is admittedly decent). On the other hand Python clearly dominates in AI, at least if you don’t care about actually deploying anything.
I write mostly Python for 5 years and uv is indeed the best thing that happened to the Python landscape during this period.
I disagree that typescript is far nicer; even syntax-wise, type annotated Python seems much easier to read, write, and refactor; but I’ll give that Python needs to ditch pip and “requirements.txt” for good.
the absolute dog shit pile of vomit that is Pip & venv
I’ve worked professionally in python for several years and I don’t think it’s ever caused a serious problem. Everything’s in docker so you don’t even use venv.
Operator '+' cannot be applied to types 'number[]' and 'number[]'.
We’re talking about Typescript here. Also I did say that it has some big warts, but you can mostly avoid them with ESLint (and Typescript of course).
Let’s not pretend Python doesn’t have similar warts:
>>>x = -5>>>y = -5>>>x is y
True
>>>x = -6>>>y = -6>>>x is y
False
>>>x = -6; y = -6; x is y
True
>>>isinstance(False, int)
True
>>>[f() for f in [lambda: i for i inrange(10)]]
[9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
There’s a whole very long list here. Don’t get be wrong, Python does a decent job of not being crazy. But so does Typescript+ESLint.
I’ve worked professionally in python for several years and I don’t think it’s ever caused a serious problem. Everything’s in docker so you don’t even use venv.
“It’s so bad I have resorted to using Docker whenever I use Python.”
No because I am not using Python to make a web app. That’s not the only thing people write you know…
JavaScript is so bad you’ve resorted to using a whole other language: Typescript
Well yeah. Typescript isn’t really a new language. It’s just type annotations for JavaScript (except for enums; long story). But yes JavaScript is pretty bad without Typescript.
But Typescript isn’t a cop-out like Docker is.
But the language it’s built on top of it is extremely warty. Maybe we agree on that.
Yeah definitely. You need to ban the warts but Typescript & ESLint do a pretty good job of that.
I mean I would still much rather write Dart or Rust but if I had to pick between Typescript and Python there’s absolutely no way I’d pick Python (unless it was for AI).
Why would you add two arrays like that?
Because I want to combine two lists.
The is operator is for identity, not equality. Your example is just using it weirdly in a way that most people wouldn’t do.
No because I am not using Python to make a web app. That’s not the only thing people write you know…
Most of what I’ve worked on has been webapps or services that support them :shrug:
Typescript and Python there’s absolutely no way I’d pick Python (unless it was for AI).
Agree to disagree then. We could argue all day but I think it’s mostly opinion about what warts and tradeoffs are worth it, and you don’t seem like you have no idea what you’re talking about. Sometimes I meet junior developers who have only ever used javascript, and it’s like (to borrow another contentious nerd topic) like meeting someone who’s only ever played D&D talking about game design.
The is operator is for identity, not equality. Your example is just using it weirdly in a way that most people wouldn’t do.
The + operator is for numbers or strings, not arrays. Your example is just using it weirdly in a way that most people wouldn’t do.
I’m not defending Javascript’s obviously terrible behaviour there. Just pointing out that Python has obviously terrible behaviours too. In both cases the solution is “don’t do that, and use static analysis to make sure you don’t do it accidentally”.
Sometimes I meet junior developers who have only ever used javascript, and it’s like (to borrow another contentious nerd topic) like meeting someone who’s only ever played D&D talking about game design.
Yeah I think you can generalise that to “have only ever used one language”. I would say Python and Javascript are pretty close on the “noob level”. By which I mean if you meet someone who has only ever written C++, Java, or Rust or whatever they’re going to be a class above someone who has only ever written Python or Javascript.
What is so bad about virtual environments? I found them to be really nice and useful when I developed in Python over about 5-ish years. It was really nice being able to have separate clean environments for installing libraries and executing things.
Granted, I only used Python as a solo developer, so if there are shortcomings that emerge when working with other developers, then I would not be aware of them…
Edit: also, performance is a bit more of a subtle topic. For numerical logic, Python actually is (probably) much better than a lot of its competitors thanks to numpy and numexpr. For conditional logic, I would agree that it’s not the best, but when you consider developer velocity, it’s a clearly worthwhile tradeoff since frameworks like Django are so popular.
They’re a solution to a self-inflicted problem. They’re only “really nice and useful” if you accept that having your projects stomp all over each others’ libraries and environments is normal.
If projects were self-contained from the outset then you wouldn’t need an additional tool to make them so.
thankfully Python seems to be moving away from the “activating your venv” nonsense. If you use poetry or uv, you don’t necessarily need to “activate” it before running your code; though a lot of people still try to do it because of learning inertia I guess.
Typescript is far nicer than Python though. Well I will give Python one point: arbitrary precision integers was absolutely the right decision. Dealing with u64s in Typescript is a right pain.
But apart from that it’s difficult to see a single point on which Python is clearly better than Typescript:
uvis a shining beacon of light here but I have little hope that the upstream Python devs will recognise that they need to immediately ditch pip in favour of officially endorsinguv. No. They’ll keep it on the sidelines until theuvdevs run out of hope and money and give up.I write mostly Python for 5 years and uv is indeed the best thing that happened to the Python landscape during this period.
I disagree that typescript is far nicer; even syntax-wise, type annotated Python seems much easier to read, write, and refactor; but I’ll give that Python needs to ditch pip and “requirements.txt” for good.
[1] + [2] "12"A sane language, you say.
const foo = 'hello' const bar = { foo: 'world'} console.log(bar) // { "foo": "world" }I’ve worked professionally in python for several years and I don’t think it’s ever caused a serious problem. Everything’s in docker so you don’t even use venv.
Yes:
Operator '+' cannot be applied to types 'number[]' and 'number[]'.We’re talking about Typescript here. Also I did say that it has some big warts, but you can mostly avoid them with ESLint (and Typescript of course).
Let’s not pretend Python doesn’t have similar warts:
>>> x = -5 >>> y = -5 >>> x is y True >>> x = -6 >>> y = -6 >>> x is y False >>> x = -6; y = -6; x is y True>>> isinstance(False, int) True>>> [f() for f in [lambda: i for i in range(10)]] [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]There’s a whole very long list here. Don’t get be wrong, Python does a decent job of not being crazy. But so does Typescript+ESLint.
“It’s so bad I have resorted to using Docker whenever I use Python.”
Why would you use the
isoperator like that?The lambda thing is from late binding, which I’ve had come up at work once. https://docs.python-guide.org/writing/gotchas/#late-binding-closures.
Do you not use containers when you deploy ? Everywhere I’ve worked in the past like 10 years has moved to containers.
Also this is the same energy as “JavaScript is so bad you’ve resorted to using a whole other language: Typescript”
To your point, typescript does solve a lot of problems. But the language it’s built on top of it is extremely warty. Maybe we agree on that.
Why would you add two arrays like that?
No because I am not using Python to make a web app. That’s not the only thing people write you know…
Well yeah. Typescript isn’t really a new language. It’s just type annotations for JavaScript (except for enums; long story). But yes JavaScript is pretty bad without Typescript.
But Typescript isn’t a cop-out like Docker is.
Yeah definitely. You need to ban the warts but Typescript & ESLint do a pretty good job of that.
I mean I would still much rather write Dart or Rust but if I had to pick between Typescript and Python there’s absolutely no way I’d pick Python (unless it was for AI).
The
isoperator is for identity, not equality. Your example is just using it weirdly in a way that most people wouldn’t do.Agree to disagree then. We could argue all day but I think it’s mostly opinion about what warts and tradeoffs are worth it, and you don’t seem like you have no idea what you’re talking about. Sometimes I meet junior developers who have only ever used javascript, and it’s like (to borrow another contentious nerd topic) like meeting someone who’s only ever played D&D talking about game design.
The + operator is for numbers or strings, not arrays. Your example is just using it weirdly in a way that most people wouldn’t do.
I’m not defending Javascript’s obviously terrible behaviour there. Just pointing out that Python has obviously terrible behaviours too. In both cases the solution is “don’t do that, and use static analysis to make sure you don’t do it accidentally”.
Yeah I think you can generalise that to “have only ever used one language”. I would say Python and Javascript are pretty close on the “noob level”. By which I mean if you meet someone who has only ever written C++, Java, or Rust or whatever they’re going to be a class above someone who has only ever written Python or Javascript.
What is so bad about virtual environments? I found them to be really nice and useful when I developed in Python over about 5-ish years. It was really nice being able to have separate clean environments for installing libraries and executing things.
Granted, I only used Python as a solo developer, so if there are shortcomings that emerge when working with other developers, then I would not be aware of them…
Edit: also, performance is a bit more of a subtle topic. For numerical logic, Python actually is (probably) much better than a lot of its competitors thanks to numpy and numexpr. For conditional logic, I would agree that it’s not the best, but when you consider developer velocity, it’s a clearly worthwhile tradeoff since frameworks like Django are so popular.
They’re a solution to a self-inflicted problem. They’re only “really nice and useful” if you accept that having your projects stomp all over each others’ libraries and environments is normal.
If projects were self-contained from the outset then you wouldn’t need an additional tool to make them so.
thankfully Python seems to be moving away from the “activating your venv” nonsense. If you use poetry or uv, you don’t necessarily need to “activate” it before running your code; though a lot of people still try to do it because of learning inertia I guess.
If I need to keep my Python environment separate I’d rather spin up a docker container. They make virtual environments pointless
But then you need to connect your IDE to the docker container. Doable, but often a PITA IME
A single extension and 1-2 clicks isn’t that much to me 🤷 I’ve been doing it painfree for a few years now
Maybe it’s gotten better in recent times…it was always disconnecting and needing to be restarted