Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yes, Python is Slow, and I Don’t Care

hackernoon.com

Post reply on HN
Print view View original

131–140 of 206 posts

Re: Yes, Python is Slow, and I Don’t Care

#131

Post by jerf »

monkmartinez wrote: post #117
jerf wrote: post #55

Earlier quoted context omitted.

"There's are still some big gains python could make, if python implementations were better." At this point, I would find it far easier to believe that you are underestimating the difficulty involved in what it takes to speed up Python than that there are enormous gains yet to be had in speeding up Python. I suspect JS has had more optimization effort expended overall, but Python has still had a ton of work by lots of…

Will you please share the languages you thunk are up and coming?

Go is an early entrant into this space, but I think part of the reason it is early is also that it is less ambitious. But to answer the ever-present question on HN about "why would anyone ever use this language?", something modern, almost as easy to use as a scripting language [1], and almost as fast as a compiled language, doesn't actually have a lot of contenders. (Old fogeys... like me!... like to observe that if you drop modern you have some things like Delphi that fit that slot, but they're all pretty much dead now, and Go has good support for concurrency in the modern processor environment.)

In the "you probably can't convince your boss yet" category I'd recommend Crystal (https://crystal-lang.org/) and Nim (https://nim-lang.org/).

Given the programming landscape and the general direction of things lately, I also bet there's a couple of serious contenders developing out there that haven't even hit HN yet.

[1]: For at least a broad class of problems. Put Go head-to-head with a problem someone would use NumPy for and Go will go down in flames in the ease-of-use and line count department. However I use Go for a lot of networks servers (not even necessarily Web servers, but network servers) and the line count for these comes out maybe 20% larger than Python, and it doesn't take much developer cognitive energy for those extra lines. I've also used Go for some command-line type apps where the line count is probably 50% over Python, but I also got some significant wins from the type system and concurrency, so, all in all there's a lot of things I can prototype with about the same mental effort in Go as I could in Python. Being able to declare interfaces that existing types conform to turns out to cover a surprising amount of those "duck-type" scripting-type cases.

Re: Yes, Python is Slow, and I Don’t Care

#132

Post by skybrian »

barrkel wrote: post #58
scarface74 wrote: post #20

I was all ready to savage his opinion after reading the headline but I agree looking at my architecture that I designed for the company I work for, CPU isn't the bottleneck. Every time I try to increase performance by multi threading as much as possible, the databases start screaming. On the other hand, the idea that dynamic languages are more productive than static languages are laughable. Statically type languages…

You sound like someone who hasn't used dynamic languages in anger, or you'd mention some of the things that dynamic languages do well that statically typed languages aren't so great at, to prevent your argument sounding like a straw man. For example: dropping into a debugger (binding.pry / pry_remote in Ruby) to write code interactively in the context of the application, transferring that code to the source, and cont…

Hot reload works well in Java and Dart (using IntelliJ).

As you say, you generally can't add new fields or classes, but it's not clear to me how important that is? Doing a full restart occasionally is not that big a deal.

I am skeptical about the long-term maintenance of systems with custom DSL's. Unless it's something popular like JSX, it seems like you end up with your own language dialect that nobody else understands?

Re: Yes, Python is Slow, and I Don’t Care

#133

Post by Can_Not »

nhumrich wrote: post #99
agentgt wrote: post #93

Earlier quoted context omitted.

I'm a Java dev (and the one you replied to) and in the past when I didn't work at my own company the real reason Python was often not picked was because it was considered "a toy language" or "scripting language" (ie hard to maintain) and also because it didn't have vendor support like Java did. Of course this was like 8-10 years ago. I still program and sadly prefer writing code in Java over Python even though I have…

Thats a very fair argument. But lets say hypothetically that language X was more "productive" than language Y. Wouldnt it be a worthwhile "investment" to learn X seriously? Sure it might slow you down for a year, but after that it pays dividends.

But if it's all unjustified hype, unmentioned drawbacks, and empty promises, then your losses can be extraordinary.

Re: Yes, Python is Slow, and I Don’t Care

#134

Post by ivm »

nadam wrote: post #37

"It used to be the case that programs took a really long time to run. CPU’s were expensive, memory was expensive. Running time of a program used to be an important metric." As hardware gets faster we give it new tasks that could not be achieved before. Like rendering high resolution stereoscopic images using physically based shading at 90 FPS on relatively cheap consumer hadware (VR). There are still quite a lot of c…

It's still expensive on client machines because most of the persons in the world are NOT software engineers with 6-digit salaries.

They run cheap computers with HDDs and Windows polluted by a ton of 3rd party crap. They don't know how to fix it and silently suffer.

I was cleaning a local vet clinic's devices recently – they were literally switching between two computers to not wait 5 minutes of non-responsiveness because some bloated software was occasionally consuming 100% of CPU.

Re: Yes, Python is Slow, and I Don’t Care

#135

Post by zwerdlds »

traverseda wrote: post #127
contravariant wrote: post #70

Earlier quoted context omitted.

A static type system doesn't protect you from choosing the wrong abstraction, and all the bugs that result from it. But if used properly I think it does help.

How? I don't think I've ever gotten a type I wasn't expecting in any of my python code. It's just not a problem for me. That is, past the first time I run it. I've been known to pass something an x when it wanted a y, but that's a "fail early, fail loud" bug and not an actual problem.

So, I have a tiny bit of experience with Python. What I think you're describing is a good representation of my experience: If you're not branching too much, or you unit test enough, Python can be really, fabulously, great.

If your logic is complex, the solace that having a really good type system (eg tagged unions paired with pattern matching) is that your edge cases are handled. Maybe not according to your business rules, but at least you'll find fewer runtime errors.

Python is a tool. I think of it similar to Legos: it allows you to build small units of work. But when the work gets more complex, it's time to look at something that can handle that complexity.

This was posted the other day, and probably communicates my point about runtime/compiler time identification of issues better: http://samwho.co.uk/blog/2017/09/06/move-your-bugs-to-the-le...

Re: Yes, Python is Slow, and I Don’t Care

#136

Post by freedomben »

rockostrich wrote: post #32
scarface74 wrote: post #20

I was all ready to savage his opinion after reading the headline but I agree looking at my architecture that I designed for the company I work for, CPU isn't the bottleneck. Every time I try to increase performance by multi threading as much as possible, the databases start screaming. On the other hand, the idea that dynamic languages are more productive than static languages are laughable. Statically type languages…

I came here to make the same point about statically typed languages. My previous job mostly involved writing web servers/services in Python. A lot of the existing unit tests in our codebase were solely there to check for type safety (one of the developers that had been there for most of the lifetime of the codebase over engineered a bit with OOP in Python). Now at my current job, we use Scala. I still prefer Python f…

This has been exactly my experience after working for years in Ruby and returning to Java & Golang. It truly does take me longer to write code without my precious Ruby, but that time is more than made up for by not having to write tests for every single possible code path, purely to check for type safety.

I've also experienced an unexpected benefit in that it is a lot easier to read other people's code since types are explicit and easy to see.

Re: Yes, Python is Slow, and I Don’t Care

#137

Post by dogweather »

carlmr wrote: post #56
scarface74 wrote: post #20

I was all ready to savage his opinion after reading the headline but I agree looking at my architecture that I designed for the company I work for, CPU isn't the bottleneck. Every time I try to increase performance by multi threading as much as possible, the databases start screaming. On the other hand, the idea that dynamic languages are more productive than static languages are laughable. Statically type languages…

>On the other hand, the idea that dynamic languages are more productive than static languages are laughable. Statically type languages prevent a lot of bugs and allow for a lot of automated provably correct refactorings that simple cannot be done with a statically typed languages. You can't even reliably do a "find usages" of classes using a dynamically typed languag Exactly, I get quick and precise code completion,…

I feel this about Haskell compared to Ruby: Really easy to jump back in to code I set aside months ago.

Re: Yes, Python is Slow, and I Don’t Care

#138

Post by simonh »

rockostrich wrote: post #34
simonh wrote: post #27

Earlier quoted context omitted.

'Dynamic languages' is too often used as a shorthand, or interchangeable with 'scripting language', as here. There are a ton of more relevant language features when it comes to productivity, automatic memory management being the biggest IMHO. Interpreted vs compiled makes a difference too because your code->launch->test cycle can be so fast. But I agree, I'm a huge Python fan and even though I appreciate not having t…

But with a statically typed language, you don't need to go through that code -> launch -> test cycle as often because everything is type-safe.

I do occasionally get problems in Python due to typing issues, but it's pretty infrequent. Nowhere near often enough to care about all that much.

Re: Yes, Python is Slow, and I Don’t Care

#139

Post by cup-of-tea »

progman wrote: post #106

Yes, time to market is important. However, you don't need to compromise convenience of development for the sake of performance. If you twist your Python code to get performance it takes time. If you need performance, and like the syntax of Python then you should take a look at Nim [1]. With Nim I develop as quickly as in Python while I get the performance of C. [1] https://nim-lang.org I believe application performan…

Nim seems really good, but does it have a decent REPL these days? I'm not sure if it would be as convenient with a statically typed language, but I like the incremental development approach so much that I only use C if I absolutely have to.

Re: Yes, Python is Slow, and I Don’t Care

#140

Post by boomlinde »

The author argues from his professional experience as a Python developer that it's fast enough, that you'll spend most time waiting for I/O anyway, that you can just throw more servers at the problem etc.

The problem is that his experience as a Python developer doesn't accurately reflect the prevalence of problems where runtime CPU performance actually is an issue. Of course not, because who in their right mind would make an informed decision to solve such a problem in Python? Python has worked for him because it is only useless for a category of problems that he hasn't had the opportunity to solve because he's a Python developer. Outside this professional experience, not everything is a trivially parallel web service that you can just throw more servers at if CPU time exceeds I/O waiting.

It all really boils down to what your requirements are, whether you have all the time and memory of a whole server park at your hands, or a fraction of the time available in a smaller embedded system, how timely the delivery of the software has to be and how timely it needs to deliver runtime results once it's up and running. There are times where Python just isn't fast enough, or where getting it fast enough is possible, but more convoluted and tricky than implementing the solution in a more performant language. Developer time may be more expensive than the platform that my solution is for, but that doesn't get around the fact that it eventually will need to run with the available resources.

Post reply on HN