Live data from Hacker News

The Python Paradox (2004)

paulgraham.com

191–200 of 275 posts

Re: The Python Paradox (2004)

#191
post #135

Earlier quoted context omitted.

That was the past, helped by Kubernetes and Docker respective decisions to migrate from Java and Python into Go. Plenty of them are still Java and .NET based, as the ecosystems counter reacted to Go's adoption hype, and Rust is the new kid on the block specially for cloud native Webassembly projects and eBPF. Like Helm creators nowadays doing mostly Rust, https://deislabs.io/posts/

cloud native web assembly... ...x86_64? ;)

https://krustlet.dev/

https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-po...

https://www.docker.com/blog/docker-wasm-technical-preview/

https://www.fermyon.com/platform

Re: The Python Paradox (2004)

#192
this piece was an article relevant to that certain point in time.

where at that time - java had slow velocity - because it was tied up in marketing speak - and enterprise jargon.

however reading in between the lines - languages or ecosystems that are not shaped up by hype / marketing to do tend to encourage faster velocity and an uncanny advantage.

in this day and age though - maybe due to resume driven development - influx of vc funding. keep in mind - when YC started it was just a seeder fund - which encouraged companies to reach ramen profitability as soon as possible, not survive on the next round of funding.

what you now experience in the present - is rubber gum / viscous velocity amongst startups due to marketing i.e things like k8s, cloud tools etc which reach the complexity of J2EE tools of back then; when only the appointed prophets could show you the right true path.

now every company big and small - talks about doing things at scale. yet if you take a step back - no one has a definition of what scale is.

at $job - the talk of scale is prevalent - yet we're reaching for tools to solve human problems. that wouldn't need tech at all.

good luck finding a place that shuns complexity, isn't afraid of letting servers fail - to make sure they're robust and reliable enough. where the presentation layer - isn't going through a yearly ritual of sacrificing hours dealing with dependencies.

Re: The Python Paradox (2004)

#193
post #125

PHP dominated the internet and then eventually became shunned with people embarrassed to admit they use it. I sometimes wonder if Python is on this trajectory but much slower or not. We are already at the point where there are very clearly better alternatives from nearly every technical perspective, so it's carried primarily by momentum and ecosystem. Can that last forever?

Python is fine as scripting language for scienctific computing. What do you need more ?

Too many reasons to list. Numpy, pandas, matplotlib are all pretty badly designed and very annoying to work with. Dealing with different array types in numpy, pytorch, etc, I shouldn't have to do. Different array types have different interfaces, they shouldn't, I don't care why. Terrible packaging system. No threading. Slow loops. Etc.

Re: The Python Paradox (2004)

#194
post #191

Earlier quoted context omitted.

cloud native web assembly... ...x86_64? ;)

https://krustlet.dev/ https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-po... https://www.docker.com/blog/docker-wasm-technical-preview/ https://www.fermyon.com/platform

Gotta respect the grift I guess! Like MLM crypto schemes maybe I just Don't Get It, or I'm not the mark...

Re: The Python Paradox (2004)

#195
post #46

It's called "anecdotal evidence", the only thing that makes this post credible(-ish) is that PG wrote it.

Well said. This read like pure pseudoscience to me, hehe.

Pseudoscience feels like the wrong label, because it's not trying to be science. To me, it's clearly just an opinion post based on his personal experience.

Re: The Python Paradox (2004)

#197
post #186
post #108

Earlier quoted context omitted.

> Ruby is still great for throwing something together fast and maintaining it until it runs into scale problems. It added gradual typing with sorbet and RBS. I think Ruby is much better than Python for building large applications. Ruby is essentially Smalltalk with a neat Algol-like syntax and some Perl-isms. Its OO system is a joy to work with. Python got so popular in data-oriented applications because it's a reall…

That's sort of outdated. Python now has type hints, protocol oriented programming support, and is quite fast (for what it is). This wasn't the case back in the day but it's all there now.

Python might have nice features, but it also has terrible features. Like using dicts for everything. It's not enough to allow good practices, you have to prevent (or at least reduce) bad practices.

Re: The Python Paradox (2004)

#198
I love learning new languages because of learning, not because it's cool. That's why learning Rust shows more about the person than being on a hype train. This is one of the best indications for hiring if I'd hire someone.

Re: The Python Paradox (2004)

#200
post #153

It was right then, but it's kind of dated and misses an evolutionary lesson: beautiful code isn't enough, it has to be safe, beautiful, maintainable, productive, understandable, and resource efficient. Ruby is still great for throwing something together fast and maintaining it until it runs into scale problems. It added gradual typing with sorbet and RBS. Crystal is a neat typed, compiled Ruby-alike but it's buggy. R…

> Rust makes enormous binaries But it DOES make binaries. Such a breath of fresh air after years of Java/Scala.

Java also makes binaries with GraalVM.
Post reply on HN