3 ms·

For any web-based app, it really makes sense to take the approach of using a rapid development language first, then as you need to scale, convert to something t

by orev 7y ago

For any web-based app, it really makes sense to take the approach of using a rapid development language first, then as you need to scale, convert to something that’s compiled and focuses on speed. It’s not one or the other kind of thing — they both have a role (at least until we reach the holy grail where fast to develop is also fast to run).

zozbot234 7y ago
What's a "rapid development" language? I know about RAD, but that was a buzzword that was only ever used to push terrible languages like Visual Basic, and somewhat less terrible ones like Embarcadero Delphi.
- cle 7y ago
  Dynamic languages (so you can hack together stuff and quickly bypass any roadblocks), with REPLs (quick feedback and avoiding writing tests), and low cognitive overhead (so new folks can ramp up quickly). Some example languages that come to mind here: Python, Ruby, JavaScript, Clojure, Groovy. Go actually comes close here, even though it doesn't have a REPL and isn't very dynamic, because of its focus on minimizing cognitive overhead and getting the job done with minimal fuss. Other languages carry a lot of community baggage. Java is one of the worst IMO...if you try to hire Java programmers, it's going to take a lot of effort and risk to find and reject applicants who've read too many design pattern books, are architecture astronauts, or come from an enterprise-y background. The signal-to-noise ratio is just really poor.
  - AtlasBarfed 7y ago
    Rubys devs said the same thing about Java when Rails first came out. Now look at Ruby, its stack is gigantic and cumbersome. I guess Go will try to resist that, but over time Go will become burdened with a huge stack of outmoded software.
scarface74 7y ago
Like one of the former engineers at Twitter said about their early issues with stability and when someone blamed Ruby for the performance issues - short version it was a bad architecture not the language. Stateless web servers are one of those things which are ridiculously and easily parallelizable, you can scale a web server horizontally easily. The ROI of rewriting everything in another language as opposed to just adding more web servers would probably take years unless you’re running at a ridiculously large scale. For the cost of one developer’s fully allocated salary, you can throw a lot of hardware at performance issues with web apps. I prefer statically typed languages, but performance isn’t one of them. Besides, how much processing is a typical web app doing?

by orev 7y ago

zozbot234 7y ago

What's a "rapid development" language? I know about RAD, but that was a buzzword that was only ever used to push terrible languages like Visual Basic, and somewhat less terrible ones like Embarcadero Delphi.

cle 7y ago
Dynamic languages (so you can hack together stuff and quickly bypass any roadblocks), with REPLs (quick feedback and avoiding writing tests), and low cognitive overhead (so new folks can ramp up quickly). Some example languages that come to mind here: Python, Ruby, JavaScript, Clojure, Groovy. Go actually comes close here, even though it doesn't have a REPL and isn't very dynamic, because of its focus on minimizing cognitive overhead and getting the job done with minimal fuss. Other languages carry a lot of community baggage. Java is one of the worst IMO...if you try to hire Java programmers, it's going to take a lot of effort and risk to find and reject applicants who've read too many design pattern books, are architecture astronauts, or come from an enterprise-y background. The signal-to-noise ratio is just really poor.
- AtlasBarfed 7y ago
  Rubys devs said the same thing about Java when Rails first came out. Now look at Ruby, its stack is gigantic and cumbersome. I guess Go will try to resist that, but over time Go will become burdened with a huge stack of outmoded software.

scarface74 7y ago

Like one of the former engineers at Twitter said about their early issues with stability and when someone blamed Ruby for the performance issues - short version it was a bad architecture not the language. Stateless web servers are one of those things which are ridiculously and easily parallelizable, you can scale a web server horizontally easily. The ROI of rewriting everything in another language as opposed to just adding more web servers would probably take years unless you’re running at a ridiculously large scale. For the cost of one developer’s fully allocated salary, you can throw a lot of hardware at performance issues with web apps. I prefer statically typed languages, but performance isn’t one of them. Besides, how much processing is a typical web app doing?