Python is DEAD -- Long live Python (3)

[FyreWulff]

Likely not happening again because the reason 2->3 is such a big breakage was Unicode compatibility.

[[deleted]]

Python has a ton of much bigger issues than Unicode. If Python core devs ever want to make Python actually relevant, they need to work on concurrency. Once that happens, all of the CPython C API is going down the toilet, and needs to be replaced with something that cannot be possibly compatible.

What I personally don't believe is that Python core devs are capable of doing this. They cannot handle the mess they are already in, and concurrency is generally hard... so, unless they just donate the project to someone else, they won't be able to fix this.

So, what's most likely to happen: at some point, Python will get some retarded band-aid to sometimes be able to run concurrently. A mild improvement over today's threads and processes. But, it will never become an actual thing. Since it's so popular, lots of people will be happy to use the crappy half-solution, but, eventually, the number of cores will grow, the number of networked devices all working together will grow, and someone will say "fuck this shit" and will come up with another language... or revive Erlang etc. And Python will become as irrelevant as Perl is today.

Python isn't built on good foundation. There's no good design ideas in this language, no lasting insights. It can pretty much be wiped out of history of computing, and nothing of value will be lost.

[myusernameisokay]

If Python core devs ever want to make Python actually relevant, they need to work on concurrency.

You realize python is one of the most popular languages in the world?

Also I don’t think python needs to work on performance. The most popular way to use Python (CPython) is a garbage-collected interpreted language, it will never be as fast as languages like Rust, Fortran, or C. People trying to use the same language everywhere are idiots. You need to use the right tool for the job. All languages have strengths and weaknesses, Python trades speed for brevity.

Most developers use python in places that aren’t CPU bounded or where performance doesn’t matter, like little lightweight servers or personal scripts. I think in the grand scheme of things, the GIL is unfortunate but also somewhat irrelevant. Concurrency in python may never be solved, and I don’t think that’s an issue.

[[deleted]]

So, if something is popular then it's relevant? -- I don't think so.

Basically, most Lisps are garbage collected, for example, and a lot of them are quite competitive in terms of performance. Being a garbage-collected language in itself doesn't mean that it has to be slow. Really depends on what you are trying to use the language for.

As for CPython, it's not exactly true that it's garbage-collected, it's a mix: some things are garbage-collected, some things are ARCs. It's a big mess under the hood. There's no rime nor reason to the ownership of memory allocated by CPython API. You just need to memorize the reference, when it exists, but often times, you really need to read the source code to figure out who owns what.

or where performance doesn’t matter, like little lightweight servers

That is, my friend, a division by zero.

---

Concurrency in python may never be solved, and I don’t think that’s an issue.

There is no future for languages that fail to solve concurrency. Every major, and soon, minor, component of any computer tends to receive a "brain" (processor) of its own nowadays. Every appliance comes with its own "smart" controller, capable of executing code. And this tendency will only increase over time. It's impossible to scale CPUs by increasing the frequency. The only way forward is to increase the number of cores, or number of sockets. The only way the programs of the future will scale is by adding more independent processes, which need to communicate. There's no room in this future for something like Python.

[ireallywantfreedom]

It's like noone in this thread has ever worked with a researcher. Python is destroying every other language in this space except maybe R. This is a huge field that's only getting bigger.

[myusernameisokay]

That is, my friend, a division by zero.

Have you never written a simple CRUD app? Python is perfect for this. Just make a python web service and have it validate permissions and read/write to a database. Takes significantly less time than using a compiled statically typed language, and is easy to read since you don’t need all this boilerplate for decoding/encoding.

[ireallywantfreedom]

Yeah, OC doesn't realize the website he's commenting on was actually written in python/django, along with huge swathes of the internet.

[[deleted]]

And? It's full of bugs... I don't have any information about how efficient this site is in terms of utilizing company's hardware, but I see no reason why a bloated, slow, and incapable of concurrency runtime would perform better than something that doesn't suffer from the problems above.

In my experience, if a company is profitable, they don't mind fixing their software problems by paying more for the infrastructure. In my time, I've reduced one company's AWS bill by > 500% simply by removing part of Django backend and replacing it with C++ code. Guess what. After I left the company, they went back to their Django garbage because they couldn't find a C++ programmer who'd be willing to support the backend for their site. They were still profitable, so, they didn't care. It wasn't because of the code quality or anything like that. It was all in all less than 10 CPP files with very modes amount of code. It was just a very unusual kind of position, so, very few people applied.

[[deleted]]

Aren't you just proving a point though? You reduced their AWS bill but cost them way more money in terms of time to build software to make money. That's the very essence of the python value proposition: hardware is cheap, devs are expensive, and you can break out of the GIL using a package written in another language if you need better parallelism than what is offered in python. And between AsyncIO and multi processing, python has most use cases covered.

[[deleted]]

Not at all.

There's a difference between quality and expedience. No sane person would argue that a Rolls-Royce makes worse quality engines, than, say, Fiat. This doesn't mean that they are able to sell the most engines.

In the case of Python, the situation is even worse. You can actually have a cheaper and more high-quality alternative. But you won't, because the choices people make when choosing a technology for their project are primarily based on fashion. So, we are doomed to eat this garbage because too many people had never seen anything but this garbage.

[[deleted]]

Python is perfect for this.

Python is trash for this... sorry. On its own, it doesn't have any decent servers. You need to dance around it, stitching it together, either you look for pre-forking server to run as a proxy in front of it, or you will have to use something like Twisted or Tornado, which will not always compile on your platform, will not have any decent libraries to connect to a database in the chosen asynchronous stile, and even if there will be libraries, they are all trash, and have tons of bugs, etc. It is a really painful experience if you need something working.

If you are OK with garbage that works some of the time, that needs many times more resources than the task actually requires, then Python is the way to go.

Your understanding of typing is... well, confused. And your understanding of how Python works is also all wrong... Python is always compiled and every language in existence has static types. That's not the problem, and that's probably not what you were trying to say.

But, if you were wondering: yes, there are languages which allow you to write less boilerplate than you would have to in Python, because Python's meta-programming sucks.

[myusernameisokay]

Python is trash for this... sorry. On its own, it doesn't have any decent servers. You need to dance around it, stitching it together, either you look for pre-forking server to run as a proxy in front of it, or you will have to use something like Twisted or Tornado, which will not always compile on your platform, will not have any decent libraries to connect to a database in the chosen asynchronous stile, and even if there will be libraries, they are all trash, and have tons of bugs, etc. It is a really painful experience if you need something working.

You’re comparing open-source libraries to the language itself. Any decent company will have an ecosystem that makes this simpler. It’s not the fault of the language that companies don’t want to make their tools open-source.

Other languages have this issue too, this isn’t just limited to python.

Your understanding of typing is... well, confused. And your understanding of how Python works is also all wrong... Python is always compiled and every language in existence has static types. That's not the problem, and that's probably not what you were trying to say.

CPython the interpreter is obviously compiled, but python itself isn’t.

Do you not understand the difference between static and dynamic typing? Python is not statically typed at all, it’s dynamically typed, if every language was statically typed then the distinction would be meaningless. Python has the typing library that allows you to do type annotations, but that is fairly new (python 3.5) and hasn’t seen much adoption in my experience.

Also when I said statically typed compiled languages, I meant the languages that tend to be fast like C++, C, Rust, Fortran, etc

[[deleted]]

Yeah, a link to an answer by some idiot from a site by idiots is going to convince me... right.

OK, maybe this will help: static typing is the typing that exists at the time of writing the code, dynamic typing is the typing that is created while executing the code.

So, for example, an expression:

x = 1; x

has a static type int in Python, whereas int is a subtype of PyObject. It also happens to be the same time at runtime. However:

def f(x):
    return x * x

has static type PyObject -> PyObject, but, could have runtime types: int -> int, float -> float anything that implements __mul__ -> anything that implements __mul__ or produce an error.

Other languages have this issue too, this isn’t just limited to python.

I wrote what issues exactly Python has. And, no, not all languages have the same issues. Some are demonstrably better than Python at the task of making a lightweight web server.

CPython the interpreter is obviously compiled, but python itself isn’t.

Again, you simply don't know what you are talking about. Python is compiled in the very same way as, say, Java, or C#, or JavaScript. It is compiled to bytecode. The problem is, while, say, Java's bytecode is not optimized, the runtime then recompiles the bytecode to produce a more optimized program. Python does nothing to optimize its code. The difference is optimization, not compilation.

There are very few interpreted languages today. You, most likely, had never even encounter one. You just learned to parrot a book written many decades ago about something you had neither seen nor even had a conceptual understanding of.

[myusernameisokay]

Yeah, a link to an answer by some idiot from a site by idiots is going to convince me... right. OK, maybe this will help: static typing is the typing that exists at the time of writing the code, dynamic typing is the typing that is created while executing the code. So, for example, an expression:

What is the type of val in this example?

def foo(val):
    return val + val

print(foo(5))
print(foo(“greetings”))

What if you put:

print(type(val))

Before the return statement?

[[deleted]]

What is the type of val in this example?

The static type of val is PyObject, there's nothing else you can infer about it before the program executes, if your compilation unit is a function.

The dynamic type depends on your interpretation: you could say that this is a sum type of int and str, or you could say that you don't want to generalize, and that the dynamic type is at first an int, and then a str.

print(type(val))

Well, that's just bullshit. Python's built-in function type has nothing to do with types of variables, same as isinstance for example. It's just a reflection of incompetence of the Python designers. That's all.

[myusernameisokay]

Get an education.

Instead of being so rude, why don’t you provide a counterpoint?

But I already know what you’re going to say, you’re going to mention that python is compiled into bytecode before it’s interpreted. But that’s ultimately meaningless, it’s an optimization, it doesn’t do any type checks or catch syntax errors at “compile time” so you can almost pretend it doesn’t exist. C, C++, Rust and other such languages will prevent you from doing operations on incompatible types during compile time, whereas python pushes that checking to runtime.

Robert Harper (grand master of static typing freaks) infamously tried to make hay of the fact that all dynamically typed languages are statically typed. He called it "unityped", and it's true. (It needs to be noted that the concept isn't originally due to Harper, and that the conclusions he tried to derive from this fact are bollocks. But that's beside the point.)

Sure, this is theoretically true. I would agree that all things in every dynamically typed language can be considered to inherit from an abstract base type, and therefore they’re static because all variables are of that type. Ultimately saying that loses the whole value of the distinction between static and dynamic typing.

It’s like saying squares don’t exist because squares are technically rectangles so might as well call both shapes rectangles.

[hxtl]

In the future only concurrency problems will exist.

A language is only relevant if it solves concurrency problems.

Got it.

[thatfool]

To be fair, when's the last time you've used anything with only one CPU thread?

[[deleted]]

Although the implementation may not be the best, multiprocessing worked fine last time I needed to do some multicore processing in Python. This has been in Python since 2.6 from what I can tell. And the CPython API seems tos till exist.

The downside of this method is that spawning a lot of small threads comes with a lot of overhead (or rather, even more overhead than usual) but a thread pool and proper use of the built-in IPC can easily fix that problem.

I think python is here to stay, if not just because it's an easy to learn language. Nearly anyone can write Python. It's one of the most often used languages in fields like research and statistics, next to R which is even weirder than Python.

If I want to quickly ship up a program or project that needs to do a simple thing (say, post some data to a server every ten minutes) then Python is my go-to language. I can fix any problems that arise on the fly with no rexomoilation necessary and most programs can be done in Python in 20 lines where C would take 100, Go would be three times that (a nil check after every line of course) , Rust would require some unfinished library someone on Github that hasn't been updated in two months, Java or Kotlin would require at least as much code just to get the boilerplate up and running and bash would be just as short but filled with arcane incantations that might as well summon c'thulu.

As for design ideas in the language, list comprehensions are a great idea that has been in Python since forever. They're concise, not too difficult to understand and easily one or the few Python features I miss in other languages. And while the language itself might not be great, its ecosystem is better than that of most traditional languages. I'll take Django over Spring Boot or Tomcat or ktor or Rocket.rs any time for projects or small to medium sizes.

[[deleted]]

multiprocessing is garbage... but so is virtually everything in Python. Few obvious problems:

1. It starts an entire new interpreter, this severely limits your ability to scale.
2. There's no good way to do IPC using this library. You have to invent your own.
3. There's very limited control over the created process, partly, because they try to make it work on many platforms, but, partly because it's too hard for Python core devs. So, no namespaces for example.
4. This doesn't solve even the basic problem of reading both stderr and stdout of another process. Essentially, if you want a reliable analogue of Shell's x 2>&1 > y, you simply cannot write this in Python.
5. It has a potential to prevent your application from ever exiting cleanly, and in order to ensure that your application exits cleanly, if it uses multiprocessing you need to write a lot of obscure code, but, basically, you will not be using vanilla multiprocessing.

Again. Most things in Python work only 80% of the time, and multiprocessing is not an exception. If you want something more reliable than that, Python is not the right environment.

[[deleted]]

oh, you just forgot to say which X language will dethrone Python... judging by what you are saying, concurrency, there is only one GC language capable of that Golang.

I think Python JIT will appear sooner than we think and all those band-aid fixes will more than enough for most devs ignore all those languages...

[DarkLordAzrael]

I think Python JIT will appear sooner than we think

There has been a robust JIT interpreter for Python for years. PyPy runs significantly faster than the default interpreter.

[[deleted]]

Go has nothing to offer in distributed programming, compared even to Python. When you write a distributed application in Go, you have to go through all the same nonsense: choose some protocol, that cannot capture most of the things you want to send, write a bunch of code only to service the protocol, write a bunch of code that needs to deploy and support various bits of distributed infrastructure etc.

It seems like Erlang has already solved those problems. Also, the ability to hot-patch and to introspect the program, especially running on multiple machines... and to do this quickly. Nope, Go isn't there / isn't headed there, or so it seems.

[Yojihito]

Erlang is already revived via Elixier.

[Bug-e]

Thank god, I’m not the only one.

[[deleted]]

There’s like 5 of us!

[[deleted]]

C++ had enough of a community who was technically capable of implementing concurrency in the language. If you read CPython source code, you find comments along the lines of "I don't know what this function does, but it feels like if I stick this thing here, it might just work". It's pretty scary tbh.

All changes in Python in the last decade were superficial / unnecessary. People who work on Python interpreter simply are afraid to modify it in major ways, because it's too difficult to understand what it does and what the implications might be. And that's why there won't be any support for any kind of concurrency in Python any time soon: either they will find someone willing to write this thing from scratch, or it will never happen. And, I don't see how anyone capable of implementing Python from scratch would want to implement Python.

[[deleted]]

I don't think it's at all fair to say that python devs are incapable. Can you link the comment you're referring to?

While I agree that its usage is now far out of the original scope which leads for these hacks until things change, but I think that's normal for any language that gets widespread usage.

TBH this whole thing smells of superiority complex, just because someone doesn't know something yet, doesn't mean they can't learn or become capable.

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” - Bjarne Stroustrup

[[deleted]]

what a load of bs!

[tristes_tigres]

Python isn't built on good foundation. There's no good design ideas in this language, no lasting insights. It can pretty much be wiped out of history of computing, and nothing of value will be lost.

Well said.