Ok after reading the article this is bullshit. It’s only because they are counting JavaScript and Typescript separately.
Typescript being that popular is great news onto itself.
We have different concept about what great news is.
Compiling to an interpreted high level language is crazy. I just refuse to believe we haven’t got a better solution to yet.
As someone who works with typescript daily, you’re not wrong. It’s an extremely overcomplicated glorified linter that tries and mostly succeeds in catching basic type errors. But it also provides false confidence when you concoct something that shows no errors but doesn’t behave how you expect.
deleted by creator
Thank god, Javascript is a mess.
I’ll still plug Scala for having the beauty of Python, the ecosystem of Java, the correctness of Rust, the concurrency of Go, and the power of Lisp.
I code both typescript and python professionally, and python is almost as much of a mess, just a different kind of mess. The package manager ecosystem is all over the place, nobody is agreeing on a build system, and the type system is still unable to represent fairly simple concepts when it comes to function typing. Also tons of libraries just ignore types altogether. I love it, but as a competitor to JavaScript in the messiness department it’s not a good horse.
I’m going to code in Python for my job soon, do you have links on how TF I should manage dependencies? I can’t stand the bloat of virtual environments or Anaconda sorry.
I need to make myself a stack python but I don’t want to look at this madness. At least Typescript benefits from a high quality ecosystem of frontend tooling with Vite/React/ESLint/ESBuild and it’s getting even better with the new runtimes features :)
I need to learn about:
- built-in tools provided by the language (practice on the job and the power of Google & LLMs will help)
- ecosystem
- good practices
Why is their a build system for an interpreted language ? Do you have bundling concerns like in JS or you somehow compile Python code now?
You need to get over the bloat of virtual environments. It’s the same as node_modules and it’s completely necessary if you want more than a single python project to live on your machine.
I personally use poetry as my dependency manager and build tool. It’s not perfect but it’s a lot better than pipenv or just rawdogging pip like a maniac. uv is the new hotness, but I haven’t tried it so can’t vouch. People seem to like it though.
JavaScript is also an interpreted language with tons of build tools. The reason to have one for python is mainly about packaging and code distribution, so same as JavaScript. If you want to distribute a program you probably don’t want to just point people to a GitHub repo, and if you want to publish a package on pypi it needs to be bundled correctly.
For ecosystem there isn’t much I can do for you, it completely depends on what you’ll be working on. Baseline you want
pydanticfor parsing objects, assuming some APIs will be involved. You wantblackfor code formatting,flake8for linting,pytestfor testing. If you’re gonna write your own APIs you can’t go wrong withfastapi, which works great with pydantic. For nice console stuff there’sclickfor building cli apps andrichandtextualfor console output and live console apps respectively.People are actively trying to replace flake8 and black with feature compatible stuff written in rust but again I haven’t tried those so can’t vouch.
Coming from react you’re gonna need to pretty quickly switch gears to thinking more object oriented. You’re gonna be annoyed at how you can’t just quickly declare a deeply nested interface, that’s just how it is. The biggest change other than object oriented thinking will probably be decorators. Typescript had them experimentally and only for classes, python has them for classes and functions natively. They’re a bit tricky to wrap your mind around when you want to write your own, but not too bad. A lot of Google hits will be outdated on this front. Google specifically “decorators ParamSpec” to see how to make them properly.
Good luck in your new job, you’ll be grand!
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.
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. - 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.
