Yeah: 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.
>Yeah: 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.
Only if you're talking about the typical CRUD, website, etc program.
Why should we? People use Python for numerical analysis, scientific computing, etc. Why not let them be able to do that, while still writing in Python (instead of using libraries that delegate to C/Fortran/etc)?
And even a website can do intensive computation work. Why HAVE to write it in 2 languages?
The people who use python for numerical analysis use solutions like numpy, with which their programs spend most of their time executing optimised numeric routines.
This is exactly what Numba is designed to help with. And it already works extremely well for such cases. Numba lets you have ease of use (un-typed containers) and speed (with typed-containers) in the same run-time and the same syntax. Here is are some IPython notebooks which illustrate:
Ultimately I needed to run a math formula on some surfels and connect an edge in a graph if the formula came out True. Following that I had to prune a bunch of edges in the graph. In 2009 (when I did it), I had to drop down to c++. (Admittedly, this was also partly due to a lack of a good python graph lib.)
I'd be very surprised if Numba is helpful with something like that - the branching and complex data structures don't seem like a great fit for it.
The scientific community seems to be welcoming Julia open arms, given its performance improvements over Python, if you look at the rate code is being ported to such a young language.
Do you use Python for numerical analysis, scientific computing, etc.? If so, why are you saying "why not let them be able to do that"? If not, why are you holding forth on Python's unsuitability for these applications without knowing about the available tools?
>Do you use Python for numerical analysis, scientific computing, etc.? If so, why are you saying "why not let them be able to do that"?
1) Yes I do (occasionally).
2) Because it applies to everybody, not just me. You surely heard of the plural form of speaking before.
>If not, why are you holding forth on Python's unsuitability for these applications without knowing about the available tools?
I never said Python is "unsuitable for these applications".
On the contrary, I acknowledged that Python IS USED for these applications.
What I said is that the tools you mention (the ones that make it suitable for these applications) are written in other languages, which is kludgy. I'd rather be able to have them written (and modified etc) in Python too.
So, Python + NumPy + etc is suitable for these applications, but Python the interpreted language without external C/Fortran help is not.
if you're doing numerical analysis, you're doing it offline, not in real-time. And so again, bit-packing doesn't matter. If your space usage grows exponentially, that becomes a problem, but in that case the difference between programming languages is just a multiplier, and is dwarfed by your algorithmic problems.
Python and the faster extension languages used are the same kind of tool (well, obviously, both are languages).
So, let's compare them to two hammers.
The difference is Python is made from soft plastic, and while it is light, it only works for softer nails. For harder stuff you need a metallic hammer, which is heavier.
And the sad thing is, the Python-hammer can also be almost as hard as the other hammer while remaining light, it just needs some coating (faster interpreter innards).
So nothing (except besides the man-years of work needed on the interpreter) forbids you to have a hammer both light AND strong (== dynamic and expressive as Python WHILE many times faster).
You 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.
"Conveniently forgot" is a very rude thing to say. Even if you think someone left something out on purpose, your argumentation won't benefit from the usage if that phrase.
I haven't run into a situation where RAM was a limit I cared much about for many years. If you rely on hamstrung VPS's, perhaps, but RAM is cheap. The servers we buy at work rarely have less than 32GB these days, and most can take 384GB or more. A couple can take up to 768GB.
If anything, I work hard to put more stuff in RAM to avoid hitting disk, as even though we have SSD's in all our new servers, disk IO is still inevitably where we hit limits first, followed by CPU. Running out of memory is a rare event, and when it is it is consistently an indication of a bug.
Yeah, 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.
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.
At an hourly rate of $120, thinking 10 minutes about saving RAM costs my client $20. With that money he could've bought 1GB extra RAM. I'm sure 99.999% of the times the saved RAM, would be less than 1GB. It's a simple cost/benefit equation. If you can save more than 1GB by thinking 10 minutes about it, you're writing shitty code to begin with.
There are times when the benefits are greater, for example when your software is running a million instances, or you're working on a hardware-intensive game, but those are certainly not common case.
The cost of 1GB of extra RAM is $20 in a certain range, namely where your system fits fairly comfortably on a single machine.
Once you get past a certain level, though, the cost of the next 1GB isn't $20, it's $20 plus the cost of another computer plus the cost of exploiting multiple machines rather than just running on a single one.
Then it's $20/GB for a while again, then $20 plus the cost of adding another machine, and at a certain point you need to add the cost of dealing with the fact that performance isn't scaling linearly with amount of hardware any more.
That last bit might be a concern only in fairly rare cases. But the first, where you make the transition from needing one machine to get the job done to needing more than one, isn't so rare. And that can be a big, big cost.
(Very similar considerations apply to CPU time, of course. Typically more so.)
We can't afford hourly rates of $120 and RAM most definitely doesn't just cost $20 when you factor in the inevitable new VM/machine. RAM is critical for maintaining concurrent connections plus there are times you need to keep large datasets in memory to avoid hitting the database.
This casual disregard for resources would explain why a lot of startups run into infrastructure issues so quickly and settle on terrible solutions (or outright snake oil) to mitigate problems that shouldn't exist in the first place.
People need to start realizing that The Cloud is only a metaphor. Hardware isn't intangible and neither is their cost.
Servers don't grow on trees; they live on a rack and grow on electricity and NAND.
Yes, $20 for the memory, and $200 in time spent getting approval, another $200 to physically install it, because you 'obviously' can't just open up that server as there are procedures fr that kind of stuff, and then $2000 in time wasted by the users while they spent 6 months waiting for that one ram stick to get installed.
It's easy to think everyone has their acts together like facebook or google, but most companies i've dealt with have hardware upgrade processes measured in months or years, not hours or days. You absolutely have to take responsibility for your work as a programmer and make stuff run fast instead of labeling it somebody else's problem.
Most 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.
"Hardware costs pale in comparison to revenue and the cost of programmers."
That's not a law of physics. The number of servers you need depends on the number of users you have. The functionality you have to build usually doesn't. So the more users you have, the less true your statement becomes.
"Most garbage collected languages can't handle all the memory available on modern systems."
I don't think that has anything to do with the languages. I think that has everything to do with the quality of the memory manager implementation, and there is at least one memory manager that does deliver in this respect, namely C4.
Most apps just don't have computation patterns where RAM usage could even be a problem; most apps are IO-bound in some way. The companies I've worked for have deployed new servers because of high load averages (in the unix-load sense), not because of RAM shortages.
That's only true because most companies admit defeat before trying: they hit the disk when serving. The big Internet companies (Google, Facebook, LiveJournal, hell, even Hacker News and Plenty of Fish) all serve out of RAM: they keep everything a user is likely to hit in main memory so that a request never needs to perform I/O other than network. In this situation you're absolutely RAM-constrained.
I remember trying to optimize some financial software a couple jobs ago and hitting a brick wall because that's the speed the disk rotates at. We ended up buying an iRAM (battery-backed RAM disk) and sticking the DB on it. You can get this a lot cheaper by avoiding the DB and using a RAM-based architecture if you're willing to sacrifice fault-tolerance under power outages (or if you have some other architectural solution for fault-tolerance, like writing to multiple computers).
It's not that they admit defeat, it's that they admit success. Yes, there are ten companies that are pushing hardware so hard that every bit counts again because if it didn't they'd be in danger of exhausting the earth's supply of elemental silicon. But everyone else can make a good living without going there.
This is terrible. It's your job to know how much memory you're using and not to use too much if you can help it. In many environments it's set at a very low value - desktop, mobile, client-side web apps, embedded. Even in an environment where RAM is cheap and you can scale it as you want... using too much RAM can cause paging issues, cache-miss issues, increase your server startup time, etc. All of these are real world issues that you, as a developer, are responsible for.
Well, you're talking about making easy things even easier (CRUD web apps connected to DBs; the inherent complexity is low). That's very important for horizontal technology expansion, i.e. 'easy IT everywhere'.
For vertical progress, i.e. making complex things possible, these micro-bottlenecks are important.
These same DBs with their query processing and other domains with extremely high inherent complexity would greatly benefit from high-level languages yet still the most difficult parts have to be written in the already difficult C(++).
Neither. Less friendly ("language complexity") than Python, and less performant than Java (not in the same league).
Its just another trade off. Beyond the hype, it has interesting choices, and some very poor ones. (No algebraic datatypes, conservative exploitable will-break-your-program garbage collector, no tail recursion)
But the trade off between performance, safety and compile time is quite unique, and should be considered its main contribution to the language design space. Its just too bad it ignores every other contribution from the last thirty years. Like how to do a type system, or how to write a garbage collection that survives long run proccesses.
My experience with Go is that it is as friendly as python. Not a lot of tricks and was incredibly easy to pick up and understand. But FWIW, I don't think its as fast/mature as Java yet.
