Because it's quick and easy to radically alter and refactor your prototype as you learn the problem space. By the time it works you often find out that you don't need anything more. This is something that Perl had.
Once your program starts to get bigger you have abstractions that can cope fairly well and keep your code simple to use - this is what Perl didn't have.
If you need more speed then you can write extensions in some compiled language.I think TCL was better at this hybrid approach but Python is a nicer language in itself.
You can also just dump python and write everything in that other language but now you understand the problem space quite well and you won't be trying to learn about it using a language where change is "difficult."
Programs have to run in a lot of different contexts, not just as servers, and for some of those contexts (especially say glueing together other programs), an interpreted language is more convenient and easier to work with. In fact, unless I care about performance, I'm going to use an interpreted language because having the source close at hand when something breaks just turns out to be super useful.
1. The very first steps are quite simple. Hello world is literally just `print("hello world")`. In other languages it can be a lot more complex.
2. It got a reputation as a beginner-friendly language as a result.
3. It has a "REPL" which means you can type code into a prompt and it will execute it interactively. This is very helpful for research (think AI) where you're trying stuff out and want to plot graphs and so on.
IMO it is undeservedly popular, or at least was. Wind back 10 years to when it was rapidly gaining mindshare:
1. While "hello world" is simple, if you went further to more complex programs you would hit two roadblocks: a) the lack of static type checking means large programs are difficult to maintain, and b) it's really really slow.
2. While the language is reasonable, the tooling (how you install packages, manage the code and so on) was eye-bleedingly abysmal.
3. While the REPL did technically exist, it was really bare bones. It couldn't even handle things like pasting code into it if the code contained blank lines (which it usually does).
However since it has become arguably the most popular language in the world, a lot of people have been forced to use it and so it is actually getting quite decent now. It has decent static types (even if lots of people still don't use them), the REPL is actually decent now (this changed very recently), and there's a new third party tool called `uv` to manage your code that is actually good.
The biggest issue with it now is that it's still horrifically slow (around 50-200x slower than "fast" languages like C++, Rust etc). It is pretty unlikely that that will ever change. People always try to excuse this by saying Python is a "glue" language and you just use it to connect components written in faster languages, but a) that's pure "you're holding it wrong", and b) that only works in some cases where there are nicely separated "slow bits" that can be moved to another language. That's the case for AI for example, where it's all numerical, but for lots of things it isn't. Mercurial was a competitor to Git that was written in Python and lost partly because it was way too slow. They've started writing parts in Rust but it took them 10 years to even start doing that and by then it was far too late.
> what would you suggest?
It really depends on what you want to make. I would pick something to make first and then pick the language based on that. Something like:
* AI: Python for sure. Make sure you use uv and Pyright.
* Web-based games: Typescript
* Web sites: Typescript, or maybe Go.
* Desktop GUI: Tbh I'd still use C++ with QtWidgets. Getting a bit old-school now tbf.
Also Rust is the best language of them all, but I dunno if I'd pick it as a beginner unless you really know you want to get into programming.
I think "Python is slow" is reductive and frankly just as useful as saying "Python begins with a 'P'". The story is more complicated than simply speed of execution.
Choosing a language is a game of trade-offs: potentially slower execution in return for faster development time, for example. If your team is already familiar with Ruby, will asking them to write a project in Rust necessarily result in a better product? Maybe, but it will almost certainly take much longer.
Anyway, how many Python programs are actually "too slow"? Most of the time, Python is fast enough, even if heavy computation is offloaded to other languages.
As for Rust being the best language of them all, that's, like, your opinion, man.
I agree with you; I've developed in Python for most of my career and a lot of Python criticism is malformed.
That being said, I'm starting all new large development work in Rust. Python is hard to reason about due to its dynamic nature in large codebases. And if I'm enabling strict typing everywhere, I might as well use a typed language and get a performance boost. Obviously, this is only because I'm the sole developer and using AI to improve productivity.
Work settings are completely different and one has to be a team player to find the language that works for everyone.
> potentially slower execution in return for faster development time, for example.
Another classic lie about Python. The slower speed doesn't matter because it's development speed that's important, and Python gives you faster development speed!
Except... it absolutely doesn't. It would be very difficult to argue that Typescript has significantly slower development speed but it is much faster to execute. I also disagree that Python is any faster than Go, Rust or Lotion, but I think lots of people blindly accept that it is and would argue based on that.
I'm not trying to evangelise. I think the argument that Python is a poor choice because it is "too slow" is based on the assumption that speed of execution always matters. Sure, sometimes it absolutely does, but a lot of the time Python is fast enough.
At risk of nebulous repetition: There are many reasons one might choose a particular language. If you or your team find TypeScript or Go more amenable, by all means, use them.
The case I would make is that some of the libraries in Python are very fast and written in other languages (C, C++, etc...). With other languages that's more rare. For instance a Java application will probably use libraries that are all Java (or another JVM language).
The gotchas that I see with Python are that some really garbage code can work - that's more difficult in a language like Rust. The other nice thing about Python (aside from the fact that it can be very readable) is that devs rarely use threads and threads cause all sorts of race conditions - often when the performance of threading was never needed in the first place and the usage of them just added pointless complexity.
ptpython has existed for a decade, maybe two, and python is high level, more readable than most languages. Exec speed hasn’t mattered in my near thirty years of using it for business and prototyping tasks which it promoted early.
Yes it strains at the big to huge project end, not recommended to take it there. Still there are better tools to help now.
Absolute rubbish. The developer experience with something like Fresh is light years ahead of Python even if you completely ignore the performance (which isn't usually a huge issue with websites tbf).
You can generate the HTML server-side using TSX. 100x better than anything Python offers.
function Greeting({ name }: { name: string }) {
return (
<div class="card">
<h1>Hello, {name}!</h1>
<p>Welcome to my site.</p>
</div>
);
}
That looks like HTML, but it's TypeScript. It gets compiled to actual HTML. Can any Python framework do that??
In Python, you'd typically write your logic in Python and your HTML in a separate Jinja2 template file — two languages, two files, context-switching. With Fresh + TSX, your logic and your markup live together in one .tsx file, both in TypeScript, with full type-checking throughout.
No, that is not TypeScript. That's TSX. If you don't happen to have react, preact or a similar front end library, and a appropriate bundler, it is invalid TypeScript.
> That looks like HTML, but it's TypeScript. It gets compiled to actual HTML. Can any Python framework do that??
IMHO that's a terrible idea that no one should ever actually use, but if you are really in love with that, you can have it:
> If you don't happen to have react, preact or a similar front end library, and a appropriate bundler, it is invalid TypeScript.
Not true, you can compile it to HTML on the backend or even statically too.
It's not a terrible idea; it's actually amazing. One of Typescript's best features. I do agree at first it seems icky (reminds me of Qt's MOC) but in practice it's fantastic. I recommend you try it before criticising. Python has nothing close (nor do any other languages tbf).
> It's not a terrible idea; it's actually amazing.
You got it wrong, the terrible idea is `pyxy-org/pyxy`
>> invalid TypeScript.
> If you don't happen to have react, preact or a similar front end library, and a appropriate bundler, it is invalid TypeScript.
> Not true, you can compile it to HTML on the backend or even statically too.
I had to test your assertion that it compiles to HTML. I remember it being very invalid typescript without react scafolding. So I tested it without the react scafolding:
# mise use node@24
# echo '{}' >package.json
# npm i --save typescript
# echo 'function Greeting({ name }: { name: string }) { return ( <div class="card"> <h1>Hello, {name}!</h1> <p>Welcome to my site.</p> </div> ); }
' >hello.tsx
# : a test to check if we have a working typescript compiler
# tsc hello.tsx
error TS5112: tsconfig.json is present but will not be loaded if files are specified on commandline. Use '--ignoreConfig' to skip this error.
# echo '{"compilerOptions":{"jsx":"react"}}' >tsconfig.json
# tsc
hello.tsx:1:58 - error TS7026: JSX element implicitly has type 'any' because no interface 'JSX.IntrinsicElements' exists.
1 function Greeting({ name }: { name: string }) { return ( <div class="card"> <h1>Hello, {name}!</h1> <p>Welcome to my site.</p> </div> ); }
~~~~~~~~~~~~~~~~~~
hello.tsx:1:59 - error TS2874: This JSX tag requires 'React' to be in scope, but it could not be found.
1 function Greeting({ name }: { name: string }) { return ( <div class="card"> <h1>Hello, {name}!</h1> <p>Welcome to my site.</p> </div> ); }
~~~
hello.tsx:1:77 - error TS7026: JSX element implicitly has type 'any' because no interface 'JSX.IntrinsicElements' exists.
1 function Greeting({ name }: { name: string }) { return ( <div class="card"> <h1>Hello, {name}!</h1> <p>Welcome to my site.</p> </div> ); }
~~~~
hello.tsx:1:78 - error TS2874: This JSX tag requires 'React' to be in scope, but it could not be found.
1 function Greeting({ name }: { name: string }) { return ( <div class="card"> <h1>Hello, {name}!</h1> <p>Welcome to my site.</p> </div> ); }
~~
hello.tsx:1:95 - error TS7026: JSX element implicitly has type 'any' because no interface 'JSX.IntrinsicElements' exists.
1 function Greeting({ name }: { name: string }) { return ( <div class="card"> <h1>Hello, {name}!</h1> <p>Welcome to my site.</p> </div> ); }
~~~~~
hello.tsx:1:101 - error TS7026: JSX element implicitly has type 'any' because no interface 'JSX.IntrinsicElements' exists.
1 function Greeting({ name }: { name: string }) { return ( <div class="card"> <h1>Hello, {name}!</h1> <p>Welcome to my site.</p> </div> ); }
~~~
hello.tsx:1:102 - error TS2874: This JSX tag requires 'React' to be in scope, but it could not be found.
1 function Greeting({ name }: { name: string }) { return ( <div class="card"> <h1>Hello, {name}!</h1> <p>Welcome to my site.</p> </div> ); }
~
hello.tsx:1:123 - error TS7026: JSX element implicitly has type 'any' because no interface 'JSX.IntrinsicElements' exists.
1 function Greeting({ name }: { name: string }) { return ( <div class="card"> <h1>Hello, {name}!</h1> <p>Welcome to my site.</p> </div> ); }
~~~~
hello.tsx:1:128 - error TS7026: JSX element implicitly has type 'any' because no interface 'JSX.IntrinsicElements' exists.
1 function Greeting({ name }: { name: string }) { return ( <div class="card"> <h1>Hello, {name}!</h1> <p>Welcome to my site.</p> </div> ); }
~~~~~~
Found 9 errors in the same file, starting at: hello.tsx:1
# cat hello.js
function Greeting({ name }) { return (React.createElement("div", { class: "card" }, " ", React.createElement("h1", null, "Hello, ", name, "!"), " ", React.createElement("p", null, "Welcome to my site."), " ")); }
# : sanity check
# mise use deno
# deno hello.tsx
# : no output
# echo 'function Greeting({ name }: { name: string }) { return ( <div class="card"> <h1>Hello, {name}!</h1> <p>Welcome to my site.</p> </div> ); }; Greeting({ name: "world!" });' >hello2.tsx
# deno hello2.tsx
error: Uncaught (in promise) ReferenceError: React is not defined
at Greeting (file:////hellotsx/hello.tsx:1:49)
at file:////hellotsx/hello.tsx:1:141
Where is my static HTML? Oh, that requires react I guess.
Once your program starts to get bigger you have abstractions that can cope fairly well and keep your code simple to use - this is what Perl didn't have.
If you need more speed then you can write extensions in some compiled language.I think TCL was better at this hybrid approach but Python is a nicer language in itself.
You can also just dump python and write everything in that other language but now you understand the problem space quite well and you won't be trying to learn about it using a language where change is "difficult."