|
First revel in the fact that you actually get to choose :-) most programmers just get to play with a choice someone else made. First of all, are you going to be the product owner, or is this a consulting gig you're gonna walk away from? If the latter, chose what allow you do get the job done for the least amount of hours. As your reputation grows for getting the job done in few hours (cheap) you can increase your hourly rates. You don't need to read on. Also, if you're sure that no bottle neck is going happen. Meaning that the user will always get a response in less then 0.3 second, some thing. use whatever will get the job done fastest. In which case you should be looking at what components (like Databases, search engines, etc) are out there that allow you to get the job done fastest. Then choose you poison according to those sub systems. There is an argument for easy maintainability, in which case it comes down to how you tend to debug. I tend to use debuggers a lot, and that leaves be with Java from the languages I know from your list. You need to identify the bottle neck your application is going to have. You're rarely going to be wrong. I tend to operate with 5 bottle necks:
CPU
Memory
Disk
Network
IPC CPU: Easy, won't happen. It requires that you've avoided a memory bottleneck, meaning that you've figured out how to feed the CPU with data. There are only three languages where this is really possible, C, C++, and Fortran. Memory: Unusual for a backend project, but possible. Solving it requires that you lay out your data the right way in memory, and you're again basically back to C, C++, and (to a lesser degree) Fortran. Anything with a new operator and garbage collector tend to be bad. If possible try finding an existing piece of software to do the job for you, but it's rare. For disk and network bottle necks, programming languages don't matter. If disk bound you need to try picking a sub system that do proper caching for you, like a SQL, NoSQL, or other system. Your design choice here will be on what you base your language decision. Since you say backend, I'm assuming that you're on a web or mobile app frontend. In all likely hood, this is the bottle neck you're going to face. You should be concerning yourself with the frontend to backend interactions, not programing languages. Web frameworks and proper use of AJAX are more important. Worrying about languages is like worrying about getting a Ford model T, a Pinto, or a F-150 for a indy 500 or formula 1 race. You've asked the wrong question. IPC! Strictly not a bottle neck, but a problem that occur a lot. Remember that a IPC call take about 1 000 000 times longer than a method or function call within a program. You have to assume 40ms latency from the frontend to backend. Calling web services, database requests within you backend if you spread it over multiple servers have a 1-10ms latency. You can assume 5-10ms in practice. Trying to keep a response time for a user interaction below 0.3s, i.e 300ms you should realize that you have a tight budget for IPC calls. A backend operation that involves 1000 DB requests is just not going to get done in 300ms. If you know that your DB operations will be the bottle neck, avoid ORM's like hibernate. You're going to be spending your time making DB procedure and optimizing SQL. If you're going to have a lot of business logic, chosing a language that don't lend itself to writing large programs may run you into trouble. It's tend you to keep programs short and use IPC to call the business logic. As a result I tend to stick to Java. Well, have been doing a lot of C and C++ stuff earlier in my career, so I tend to be a little biased. On the otherhand, have been wringing a lot of frontend logic in Javascript as well, and detest the language. Hope this helps. |