4 ms·
I agree. Unless they make it like 10x faster it doesn't really change anything. It's still a language you only use if you absolutely don't care whatsoever about
by IshKebab 1y ago
I agree. Unless they make it like 10x faster it doesn't really change anything. It's still a language you only use if you absolutely don't care whatsoever about performance and can guarantee that you never will.
- nodesocket 1y agoIf you’re actually building and shipping software as a business Python is great. The advantages of Python for a startup are many. Large pool of talent that can pickup the codebase on essentially day 1. Fairly easy to reason about, mature, code velocity, typically one and only one way to do things as opposed to JavaScript. There is way more to the story than raw performance.
- OutOfHere 1y agoIt's not that great when you see that the majority of the Python code in businesses is a totally unmaintainable mess because it has incorrect, partial, or no type annotations, and is littered with serious errors that a most basic type checker would flag.
- IshKebab 1y ago> The advantages of Python for a startup are many. Large pool of talent that can pickup the codebase on essentially day 1. Large pool of mediocre Python developers that can barely string a function together in my experience.
- svara 1y agoThe counterargument used to be, the heavy lifting will be offloaded to python modules written in C, like numpy. Which was true, but maybe not the strongest argument. Why not use a faster language in the first place? But it's different now. There's huge classes of problems where pytorch, jax &co. are the only options that don't suck. Good luck competing with python code that uses them on performance.
- bowsamic 1y ago> Why not use a faster language in the first place? Well for the obvious reason that there isn't really anything like a Jupyter notebook for C. I can interactively manipulate and display huge datasets in Python, and without having to buy a Matlab license. That's why Python took off in this area, really
- IshKebab 1y agoI agree - Jupyter notebook is really the key feature Python has that makes it attractive for research/scientific computing. I would say the REPL too but until very recently it was extremely shoddy so I doubt many people did any serious work in it.
- pdonis 1y ago> I would say the REPL too but until very recently it was extremely shoddy Can you elaborate? I've been using the Python REPL for more than two decades now, and I've never found it to be "shoddy". Indeed, in pretty much every Python project I work on, one of the first features I add for development is a standard way to load a REPL with all of the objects that the code works with set up properly, so I can inspect them.
- IshKebab 1y agoVery obvious example - you can't paste code containing blank lines. Another example: navigating this history is done line by line instead of using whole inputs. It's just bare minimum effort - probably gnu readline piped directly into the interpreter or something. I think they did improve it a lot very recently by importing the REPL from some other Python interpreter but I haven't upgraded to use that version yet so I don't know how good it is now.
- pdonis 1y ago> probably gnu readline piped directly into the interpreter or something That is more or less how the REPL originally was implemented. I think there's more under the hood there now. I still don't think what you describe qualifies as "shoddy". There are certainly limitations to the REPL, but "shoddy" to me implies that it's not really usable. I definitely would not agree with that.
- bowsamic 1y agoWell, that's not true at all. Scientists care about performance, but it turns out that Python is really good for number crunching since it is really good for using very fast C libraries. I know people who use pandas to manipulate huge datasets from radar astronomy. Also, of course, it's used in machine learning. If Python was "only" used in situations where you don't care about performance, it would not be used in so many scenarios that definitely need high performance. Sure, it is not pure Python, but it's still Python being used, just used to orchestrate C libraries
- shcheklein 1y agoProbably people at some point were making same arguments about ASM and C. How many people though do ASM these days? Not arguing that for now it is relevant point, obviously Rust / C are way faster.
- IshKebab 1y agoI doubt it. C is well within 2x of what you can achieve with hand written assembly in almost every case. Furthermore writing large programs in pure assembly is not really feasible, but writing large programs in C++, Go, Rust, Java, C#, Typescript, etc. is totally feasible.
- pjmlp 1y ago1980's and 1990's game development says hi. C compilers weren't up to stuff, that is why books like those from Michael Abrash do exist.
- shcheklein 1y agoYep, exactly, It takes time to close the gap so that more and more teams taking that tradeoff
- theLiminator 1y ago> I doubt it. C is well within 2x of what you can achieve with hand written assembly in almost every case. Depends what you mean, if you preclude using targeted ASM in your C I think some hot loops can be much slower than 2x. Of course programs globally written in assembly largely don't make sense.
- mixmastamyk 1y agoObtuse statement. There are many ways of speeding up a python project if requirements change.
- IshKebab 1y agoA painful rewrite in another language is usually the only option in my experience. If you're really lucky you have a small hot part of the code and can move just that to another language (a la Pandas, Pytorch, etc.). But that's usually only the case for numerical computing. Most Python code has its slowness distributed over the entire codebase.
- mixmastamyk 1y agoIt’s not painful, that’s the point. You have a working prototype now ready to port. (If the destination language is painful perhaps, but don’t do that.) I recently ported a Python program to Rust and it took me much less time the second time, even though I write Rust more slowly per-line. Because I knew definitively what the program needed. And if even that is too much optimizing the Python or adding Cython to a few hot loops is less difficult.
- IshKebab 1y agoI have also ported a Python program to Rust (got a ~50x speedup) but this was a smallish program, under 10k lines of code. Porting larger programs is rarely tractable. You can tell that because several large companies have decided that writing their own Python runtimes that are faster is less effort (although they all eventually gave up on that as far as I know).
- mixmastamyk 1y agoCould happen with any language. The well-known Spolsky piece was about a C++ to C++ rewrite if memory serves. Blaming repeated poor decisions on a prototyping/glue language is yet another instance. Luckily there's lots of options today to dig out of them.
- analog31 1y ago>>> you absolutely don't care whatsoever about performance and can guarantee that you never will. Those are actually pretty good bets, better than most other technological and business assumptions made during projects. After all, a high percentage of projects, perhaps 95%, are either short term or fail outright. And in my own case, anything I write that is in the 5% is certain to be rewritten from scratch by the coding team, in their preferred language.
- IshKebab 1y agoSure but you're still screwing yourself over on that 5% and for no real reason - there are plenty of languages that are just as good as Python (or better!) but aren't as hilariously slow. And in my experience rewrites are astonishingly rare. That's why Dropbox uses Python and Facebook uses PHP.
- morshu9001 1y agoPeople use Python for things where performance matters, and it's fine