https://github.com/yuechen-li-dev/GenerativeCompressionProto...
There has been so much programming language innovation in the past decade that I'm surprised someone hasn't built a better Python. I'd like to see something like Rhai or Roto take off which has a natural upgrade path to Rust.
Maybe it's because interpreted languages just aren't in vogue anymore and probably won't be for a long time if humans aren't even coding anymore.
I believe Mojo is an attempt at that. Python is probably too entrenched by my estimation.
Perl 6?
I can't imagine how anyone can complain about this. The community revolted. The team listened. What else do we want?
Yes, that's the attitude I was talking about.
See, when you are a maintainer of a popular language with a community at some point the bickering becomes the job. And when you are a creative person managing a horde of egos who all participate to put their stamp on something the only reasonable thing to do is to leave them to their own devices, which he did. I really don't blame him. Guido is one of the nicest people and to see how the Python community did not have a single second's consideration for how their incessant infighting must have made him feel is one of the worst stories of the FOSS movement.
If you don't want bickering create a closed project, make it open but don't accept contributions, etc.
You can't have it both ways "I want a big diverse community, but they should all agree with me"
You don't have to activate a venv to use it; `$VENV_PATH/bin/python3` just works.
(It also softlinks/symlinks the binaries.)
What languages are you thinking of specifically when you mention better thought out ones?
Frankly, I just really prefer statically and strongly typed compiled languages.
I did my last company's first Demo and MVP in Python after running through the Koans at my co-founder's behest and ultimately we decided that the production system would not be done in Python. There are some cool things about it - specifically I do like that annotations are real AOP seams, but the numerous footguns and lack of types and a compiler just make it a very annoying ecosystem to work in for me.
C# is strongly/statically typed, compiled, and quite fast (after the vm has started), whereas python is weakly/dynamically typed, interpreted, and generally slow as fuck. Those are two fundamentally different languages, how could it possibly be a coke/pepsi situation?
I think python is fantastic for certain use cases: gluing other tools together (like LAPACK or other ancient libraries), system automation, prototyping, exploitation (I think pretty much all of us were working on stealmybitcoin in python), and exploratory data analysis.
The problems arise when people try to write, say, gigantic GUI applications in python, or really anything with CPU-bound workloads. Part of being an engineer is using the right tool for the right job. Python is the wrong tool for lots of jobs. That shouldn't be a controversial statement.
It's strongly/dynamically typed, not weakly typed. Why do people keep getting this wrong? Has any version of Python been weakly typed? I know Python 2 and 3 aren't, perhaps the first version or ABC, its predecessor language.
It's kinda funny to say people are getting it "wrong" when strong/weak typing isn't really defined anywhere or universally agreed upon.
In fact, even "dynamic typing" can be considered to be an oxymoron, since types are formally defined to be a static property of a language. A more correct term would be "uni-typed".
I'm not saying that the meanings you're using for static/dynamic and weak/strong are bad, just that chastising someone for getting them "wrong l" doesn't make sense for terms that are not widely agreed upon.
What I don't do is cultivate a "favorite language" and make it my whole identity, and then take criticism of that language as some sort of personal affront. Python objectively has some serious flaws. That shouldn't make anyone emotional, and I don't know why people get their backs up like this.
Problem with any popular language is an outsider sees one or two statistically-likely codebases that are total turds, and then gets one-shot by the Goomba fallacy.
I don’t know, but deflecting legitimate criticism of a language by calling it “language purism” seems pretty emotional to me.
What do you attribute Python's success to, in spite of being a disaster of a language and ecosystem?
First, it's easy to learn and reasonably powerful. You can make a lot of useful things really quickly, which was true even 15 years ago. It's only gotten easier since, and the ecosystem has continued to grow.
Second, ML latched onto it. That gave Python a lot of credibility for people coming through CS programs and into industry, especially as AI use cases were picking up momentum. Think Tensorflow starting 10-ish years ago, then Pytorch, and so on.
[opinion time] Unfortunately, ML has contributed to disaster. The quality of software engineering in ML applications lags badly behind that in other segments, and there's where most Python development is happening now. The feedback loop of training Bad Python into LLMs is only making it worse. The skill floor was dropping, and now it's practically zero.
It also wasn't helped much by language design decisions. Gradual typing was a huge mistake. It would have been much better to go the Typescript route and define a superset of the language that compiles to native Python. The grafted-in typing features that rely on runtime behavior and never got an actual spec for a type system haven't helped.
Apparently you can't be a senior dev unless you "just here to deliver"
It can do everything, it's a nightmare to write correctly and is so full of warts that really only a mother could love it.
Go is "elegant" and properly designed, which leads to fundamental unassailable limitations; like its GUI story or writing a backend for other languages (cgo is so slow and -build-mode=c-shared is a hog).
No operator overloading makes it difficult for numerical/scientific work - Python is stronger here.
"just get stuff done" is your crappy dump truck which is welded together out of spare bits and is barely hanging on, this is how I feel about C++.
Go is a lot more elegant and well designed, but it requires "smooth roads" (An OS and Runtime) and goes fast... it's more like a Dodge Hellcat..
EDIT: if we consider speed a function of development time rather than runtime, of course at runtime C++ can be as fast as it gets.
To me it seems more like C++ is the metal shop's old school 3-axis mill: effective and dangerous. Can do almost anything, including easily maim you unless you're continually vigilant.
Go seems like a CNC machine: just as effective, much less dangerous because it relies on digital safeguards and embedded controllers. You need to go to extreme lengths to make it do something it wasn't designed to do.
Python seems like lego. Shit simple to build things with, lets you start building immediately, fantastic for prototypes, but finished product is still just press-fit plastic bricks
We've known for a very long time that shitty things can become very successful in this field and why.
Cross platform interpreter.
NumPy and SciPy really set the stage.
I'll give Python one thing though, it is by far the most elegant way to glue together a large number of otherwise incompatible C libraries.
But Python peaked like 20 years ago. The later features were too ugly, and it was too slow to fill the obvious gaps in the language.
The language is a disaster since it deviated from its original purpose. The community is ruled by insane, mediocre narcissists who drove away all reasonable people.
- Reasonable ergonomics for describing data flows, as long as you never run the code, which you often don't care about if you're a mathematician
- Adoption by people who optimize pumping citations, not reproducible results -- non-working code is a feature when you're trying to BS
If you set a bar, any bar, there's really not much offered by Python that you cannot find in a more reasonable language. Especially if you're gluing together C++ and Rust libraries for data processing or ML workloads. Python is still disproportionately popular there but I'm also convinced its days are counted. C++ will be tremendously harder to get rid of, in comparison, if that's even possible.
I work in python. It's only real and big issue is the slow interpreter. Everything else is resolvable one way or another. The only other big issue it has is the envy of people who imagine that if not for python, their beloved language would be as used as python is now. Most of their beloved languages are older than python or when they were created, they had much bigger ticket backing than python and those languages are still not where python is. The reason? Python is made to solve the issue one has now, not the issue one might have in the future. Local optimum at its best and worst. And honestly, most people have the current issue to solve and rarely reach the imaginary issue to be. If python didn't exist, it would have been invented.
- performance is awful.
- gradual typing is sort of ok, but relies too much on runtime behaviour.
- async support is a bit all over the place.
- uv has made the packaging experience sort of liveable, but collectively it’s still very limited: feature support, conditional dependencies, rudimentary tree shaking, cargo-style workspaces, etc.
In an era where your options of tech stack are freer than ever, unless you explicitly need PyTorch, I’m not really sure why you’d choose Python over literally everything else.
Venvs, activate, deactivate, shitty scripts hacking on $PATH. How did this ever ship? Then there was poetry, `uv`, and maybe something in else in $CURRENT_YEAR.
Try to set it up on a new macOS, go on. Install a package from pip, and there's a bunch of garbage that won't let you do it.
It's horrible. Python packaging engineer is now an FTE, maybe that's what they wanted.
It lacks decent packaging and by design cannot handle multiple versions of dependencies or perform metadata-only/declarative resolution. To resolve the dependencies of a Python package you need to install it. Many Python packages resolve their dependencies imperatively depending on the current system state. When you need binary dependencies like numpy it gets even worse since libpython doesn't have a stable ABI.
It is one of the most underdesigned languages but it holds a dear place due to being easier to translate from pseudocode to actual implementation. This resulted many academics to pick it up and write advanced math libraries in it.
"unhinged" take