9 ms·
Time of "Getting that shit done" and cost of long-term maintenance are two of the main reasons why people use Ruby/Python, not for the raw performance. I though
by d0m 14y ago
Time of "Getting that shit done" and cost of long-term maintenance are two of the main reasons why people use Ruby/Python, not for the raw performance. I thought that was an old debate. And anyway, from my experience, Python has never been the cause of the slowness.. It's more about tweaking that DB query, smartly packaging the assets or using a better algorithm. (I know it's not always the case. I.e. If my program has to run in the space where bits could be randomly shifted, some additional thoughts would be needed, obviously.)
- jacobmarble 14y agoTrue, the author doesn't really address "effort to get shit done", but Others have commented on this and there seems to be consensus around "Go is a very human readable/writable language". Anyone know of a human read/write-ability comparison of programming languages?
- zachrose 14y agoDepends on the human! (One end of the spectrum is a DSL customized to the concepts and patterns of domain experts.)
- antiterra 14y agoIsn't that a useless comparison? Chinese, Tamil and Estonian are all extremely human read/writeable, so much that children can write them. However, it's likely at least one of them is indecipherable to you. Perhaps the metric you're more interested in is the difficulty in learning to read/write decent code in a particular language. Of course, this difficulty can vary based on what other languages the learner is already familiar with.
- jesstaa 14y agoChinese is often even indecipherable to the Chinese and because of this there have been many attempts to simplify it. There is a subset that people actually use and the rest is avoided. This is a similar case with languages like C++, Ruby and Python. The languages are terrifyingly complex, but the subset that most people use is reasonably usable. If you stray outside this subset there be dragons.
- danenania 14y agoI see your point about C++, but I don't think anything in Ruby or Python could be described as "terrifyingly complex". They give you plenty of rope to hang yourself in various ways, but that's a different issue than language complexity.
- jes5199 14y agoYeah: your real bottlenecks are going to be 1) getting data out of your database and 2) sending packets across the internet. These are 100 times and 1000 times slower than your program, the 10x penalty to use ruby/python instead of C/C++/go/rust isn't going to matter.
- theoj 14y agoYou conveniently forgot a key bottleneck: the amount of RAM on your server. That's what determines how many concurrent sessions you can keep running before performance degrades and you need to add another server.
- jes5199 14y agoYeah, but as a programmer that's not really my domain, and anyway throwing more servers at the problem fixes it, and doesn't require much change in the architecture of most apps. The maximum speed of the internet, the maximum speed of your database, the maximum speed of your programming language are all basically constants that you can't improve by throwing money at the problem.
- eksith 14y agoThat is just plain appalling. As a programmer, available memory is absolutely your domain or else you're increasing hardware/VM costs for yourself or your employer needlessly. Then you've transferred the cost of increased hardware to host your app/site/whatever off to users. I can see today bit pinching isn't fashionable as it was long ago when memory wasn't cheap (it's not really "cheap" today either since you're paying proportionally greater per VM than the actual cost), but when a basic tenet like efficiency is ignored because DB all you're doing is compounding the problem. BTW. Most people already deal with the DB issues with aggressive caching and/or reverse proxy so that still leaves the core application.
- fleitz 14y agoMost garbage collected languages can't handle all the memory available on modern systems. Hardware costs pale in comparison to revenue and the cost of programmers. (Unless your service is free) In general if your server is making you money, you'll make more money improving the service than reducing the amount of RAM the service takes to run. In summary, test the conversion rate of a page/feature/etc, not how much RAM it uses. If you're going to performance optimize, attach a profiler and take the easy wins, don't spend too much time on it unless it's a ridiculous amount of resources or your margins on razor thin.
- pifflesnort 14y ago> Time of "Getting that shit done" and cost of long-term maintenance are two of the main reasons why people use Ruby/Python, not for the raw performance. Plenty of other languages "get shit done". > And anyway, from my experience, Python has never been the cause of the slowness. Then you're not actually performing performance analysis. Python is S-L-O-W. I've written large systems in Python. I've profiled them to find the hotspots. I've micro-benchmarked them against implementations in other languages (C, Java). Python lost. Always. By a lot. So then I had to rewrite critical sections of the Python in C (or accept that we'd need 32 servers instead of 2). Eventually I stopped bothering, and used a different language, because the aggregate cost of a thousand small performance issues (and a few big ones) is actually quite high.
- scott_w 14y agoI think you missed the point. There are plenty of use cases where Python isn't the cause of slowness. It doesn't matter if C is 100x faster than Python if your app is running 49/50 seconds running SQL queries.
- coldtea 14y agoNo. But it DOES matter to me than Python restricts you to using it for those cases, whereas I would want (and could technically be able to) use it for far more stuff.
- pekk 14y agoSo you prematurely optimize Python out of everything you write, because it might not be suitable for... some use case yet to be determined?
- coldtea 14y agoNo, I don't "prematurely optimize Python out of everything I write". The exact opposite, I would like to be able to use Python for more stuff but I can't because it's slow. Nothing about doing it "prematurely" here. I have tried it for specific problems and it was slow. If anything, having built in in Python first is the reverse of "prematurely". And I have, as many programmers have, a very good general idea of where it's slow and what it can be used adequately for without resorting to C. And what I argued is that people constrain themselves unconsciously, based on that very knowledge, to the kind of projects they do with pure Python. Nobody writes a AAA game in Python. Nobody tries to build a browser in Python. Nobody writes a performant Apache/Nginx class web-server in Python. Nobody writes a database engine in Python. Etc etc. (Note for the "Vulcan"-style literal readers: by "nobody" here I mean "not many" / "not a sane person". I'm sure you can find some experimental, bug ridden, half-developed example of all of those done in Python, with maybe 100 users at most. Oh, and I specifically wrote: "pure python").
- pointyhatuk 14y agoActually I find the opposite. Python is easy for quick wins but from a maintenance, performance and reliability perspective it rapidly falls off a cliff. If your code propels your business then these concerns need to be considered up front. Even off the shelf functionality doesnt have the same time/complexity properties as say c#, java or go resulting in a fairly basic algorithm reaching ridiculous time constraints very quickly. As for CRUD type apps, you are probably right but its the bits that aren't CRUD which add the most value to your product.
- nilliams 14y agoIf there really are business-critical parts of the app that are too slow a good developer will drop down to C (as noted by others). That doesn't negate the reasons for using Python for the rest of the app. Your mentions of maintenance and reliability in the opening sentence are unfounded. What makes a Python app less so than the same app written in any other language? Surely it comes down to the developer. A well-factored app written in Python (with tests) is going to be far more maintainable than a big ball of mud written in C. The choice of language has little to do with it.
- pointyhatuk 14y agoI didn't mention C :) I wouldn't drop down to C ever at application level. There is virtually no need to do this these days without introducing more risks from a security and memory perspective and the inevitable situation of "integration hell". I'd rather throw it in a JVM than drop to C. Then again if I started with a JVM I wouldn't have the problem to start with as it solves both ends of the problem. The CLR is equally applicable here. Go hits the mark too. From my experience here dealing with a massive 100kloc python project. Python maintenance: a) Horrible to refactor. I mean really horrible. You don't get everything right the first time and when it comes to fixing that it's hell. b) no type safety or contracts which is hell when working with other developers. c) indentation issues which are totally horrible at merge time as it introduces a shit ton more work to do. Reliability: a) Some algorithms don't scale the same way as they do in other languages due to the points the article raises. It gets to the point that for something in Java is O(N), it can approach O(N^2) due to all the dict fudging and copying which is not good. b) It's slow anyway - I mean really slow. If something feels slow, it is slow. PyPy may fix this but (c) below causes an issue as well. c) Optimisations aren't consistent across python versions (consider how crappy IO was in the first py3k drop). I wouldn't use Python for a new project now. The only utility I see is quick disposable bits of glue.
- coldtea 14y ago>And anyway, from my experience, Python has never been the cause of the slowness.. It's more about tweaking that DB query, smartly packaging the assets or using a better algorithm. That's because you constrain your use of Python in I/O bound problems, like webpages and such. If you had any CPU bound problems, then you would have found Python is quite slow -- and you can get 2-20-100 times the performance in another language. Python is very slow (compared to what it can be), which is what necessitates tons of workarounds like: C extensions, SWIG, NumPy and SciPy (C, Fortran, etc), Cython, PyPy, etc. A whole cottage industry around Python's slowness. Which is nice to exist, but not an ideal solution: suddenly you have 2 codebases to manage in 2 different languages, makefiles, portability issues, etc etc. All of those are barriers to entry.
- pointyhatuk 14y agoThis. Integration is hell. This is a universal fact. I'd rather pick a tool which doesn't add integration requirements!
- pekk 14y agoPython doesn't add integration requirements. If you want to just use PyPy for something, then use it in good health (without fearing that your e-penis is tiny and will hamper your 'performance' because you didn't do whatever coldtea said is necessary for ULTIMATE SPEED).
- coldtea 14y agoWhy the juvenile mockery about "e-penis" and "ULTIMATE SPEED" and such mocking? Are we 12 year old here? I made my case explicitly, and it's about technical limitations of CPython that can (and, at some points WILL) be overcome. PyPy is a step in that direction, though not mature yet. Python, in the form of the standard and most used implementation for scientific, technical etc programming, CPython, DOES add integration requirements. It necessitates the use of C/Swig/Cython etc extensions for performance critical stuff. And it necessitates it, not because it puts a gun in your head or says so in some contract clause, but in the pragmatic way, that people find it's not fast enough for their needs in pure form. That's why all the popular related Python projects are not written in pure Python, but in C/Fortran/et al (NumPy etc).
- RegRegReg 14y agoExactly, if you want shit done you need to use Ruby/Python. If you want actual stuff done you use something else.