6 ms·

>what matters most to me is speed of development and whether or not I enjoy the process. Matters most? There are 100x differences here. Take two companies writ

by columbo 14y ago

>what matters most to me is speed of development and whether or not I enjoy the process. Matters most? There are 100x differences here. Take two companies writing the same application, one in Spring the other in Rails. Both have easy access to knowledgable people, both are industry standard. However the Spring application would be several orders of magnitude more scalable[1]. I'd consider that to be a more important consideration over enjoying the language. [1] All benchmarks are suspect until proven otherwise. You can write slow software in Java/C/C++, you can write fast software in Python/Ruby etc etc etc

superuser2 14y ago
Performant, not scalable. You can throw money at Rails and it will handle the load, but it would cost a lot more.
- jamesaguilar 14y ago
  If budget is finite, performant ~= scalable once you get to the point where you're actually trying to scale.
  - Zak 14y ago
    I think most people these days take scalability to mean the ability to handle more load by adding hardware without changing the architecture. That's quite different from how much load the same hardware can handle (performance).
    - jamesaguilar 14y ago
      I dunno, I hear the term "scalable" applied to business decisions all the time. I think it encompasses more than "Is this problem embarrassingly parallelizable?"
      - Zak 14y ago
        In business terms, what people usually seem to mean is "able to bring in more revenue without having to hire people with skill sets that are rare or difficult to qualify". A software consulting business doesn't scale because it requires hiring programmers; a telephone support business might because it's much easier to hire people who can speak English and follow a script.
- columbo 14y ago
  Oh right, good point, I should have said performant.
wyqueshocec 14y ago
From my experience, the Spring one would take 10x as long to make, which means more developer cost and more feedback reaction time. Certainly not a deal breaker, but a cost/tradeoff one must consider. Edit: clarity.
- columbo 14y ago
  Oh sure, there are reasons to use an easier/faster-to-develop language, I believe every developer should know a 'hard-and-fast' language and a 'slow-and-easy' language... and know when to use them. 98% of the websites out there could run on python and I doubt we'd see a big performance difference. However, I really don't think there exists a 10x difference developing in Spring. Hell, I don't think there is a 10x difference in using Struts vs Rails. Spring development is considered slow as it brings images of enterprise shops taking several years to go through the bureaucratic red tape necessary to incorporate a new feature. I've worked with plenty of small companies using Spring and their development/release cycle is maybe 1/2 or 1/4 the speed of comparable 'easier-to-build' technologies, but it definitely isn't 1/10th the speed to develop.
  - wyqueshocec 14y ago
    I chose that number because of this anecdote: I worked at a start-up a few years ago. I worked on a PHP-powered website that spoke to a Java-powered (Spring/Hibernate) service layer. The PHP team consisted of one: me. The Java team consisted of over 10 engineers. I outpaced them easily and consistently. In other projects with similar divisions, I've had similar experiences, though not always so dramatic.
    - mtrimpe 14y ago
      I used to be a hired gun that would be called in occasionally to, like you, code circles around bigger teams when deadlines were tight. Last few years however I decided to stick around with one of my clients for a while and I realized that quite a few of the employees I considered sub-par before were actually pretty decent programmers doing their best to do quality work in a dysfunctional environment. I've since then learned to really appreciate this quote, which my gut tells applies to your situation as well: "Never attribute to incompetence that which is adequately explained by bad management."
brass9 14y ago
Do you really have any experience developing any real-world project on these disparate frameworks?
alberich 14y ago
Hm, I'm not sure a benchmark like these allows one to draw such conclusions. The benchmarks, although good, are a best case scenario and of limited aspects of those frameworks. Real applications don't behave like this. What if on the average case such huge differences in performance becomes eclipsed by other factors?

by columbo 14y ago

superuser2 14y ago

Performant, not scalable. You can throw money at Rails and it will handle the load, but it would cost a lot more.

jamesaguilar 14y ago
If budget is finite, performant ~= scalable once you get to the point where you're actually trying to scale.
- Zak 14y ago
  I think most people these days take scalability to mean the ability to handle more load by adding hardware without changing the architecture. That's quite different from how much load the same hardware can handle (performance).
  - jamesaguilar 14y ago
    I dunno, I hear the term "scalable" applied to business decisions all the time. I think it encompasses more than "Is this problem embarrassingly parallelizable?"
    - Zak 14y ago
      In business terms, what people usually seem to mean is "able to bring in more revenue without having to hire people with skill sets that are rare or difficult to qualify". A software consulting business doesn't scale because it requires hiring programmers; a telephone support business might because it's much easier to hire people who can speak English and follow a script.
columbo 14y ago
Oh right, good point, I should have said performant.

wyqueshocec 14y ago

From my experience, the Spring one would take 10x as long to make, which means more developer cost and more feedback reaction time. Certainly not a deal breaker, but a cost/tradeoff one must consider. Edit: clarity.

columbo 14y ago
Oh sure, there are reasons to use an easier/faster-to-develop language, I believe every developer should know a 'hard-and-fast' language and a 'slow-and-easy' language... and know when to use them. 98% of the websites out there could run on python and I doubt we'd see a big performance difference. However, I really don't think there exists a 10x difference developing in Spring. Hell, I don't think there is a 10x difference in using Struts vs Rails. Spring development is considered slow as it brings images of enterprise shops taking several years to go through the bureaucratic red tape necessary to incorporate a new feature. I've worked with plenty of small companies using Spring and their development/release cycle is maybe 1/2 or 1/4 the speed of comparable 'easier-to-build' technologies, but it definitely isn't 1/10th the speed to develop.
- wyqueshocec 14y ago
  I chose that number because of this anecdote: I worked at a start-up a few years ago. I worked on a PHP-powered website that spoke to a Java-powered (Spring/Hibernate) service layer. The PHP team consisted of one: me. The Java team consisted of over 10 engineers. I outpaced them easily and consistently. In other projects with similar divisions, I've had similar experiences, though not always so dramatic.
  - mtrimpe 14y ago
    I used to be a hired gun that would be called in occasionally to, like you, code circles around bigger teams when deadlines were tight. Last few years however I decided to stick around with one of my clients for a while and I realized that quite a few of the employees I considered sub-par before were actually pretty decent programmers doing their best to do quality work in a dysfunctional environment. I've since then learned to really appreciate this quote, which my gut tells applies to your situation as well: "Never attribute to incompetence that which is adequately explained by bad management."

brass9 14y ago

Do you really have any experience developing any real-world project on these disparate frameworks?

alberich 14y ago

Hm, I'm not sure a benchmark like these allows one to draw such conclusions. The benchmarks, although good, are a best case scenario and of limited aspects of those frameworks. Real applications don't behave like this. What if on the average case such huge differences in performance becomes eclipsed by other factors?