4 ms·

Web 2.0: Shifting from "Get Fast" to "Get Massive" this

4 points by python_kiss 20y ago

ereldon 20y ago
The overall point is valid -- having a lot of users is the main way that a lot of companies make/want to make money, therefore companies should focus on scaling issues, therefore... "use Erlang." However, conflating Web 1.0 "get fast" with Ruby on Rails "develop fast" is: 1) wrong: with extremely limited resources and a long list of priorities, startups need to start with fast, basic tools in order to get a functional site up -- to then discover what people want to use. scaling comes later, if ever. 2) self-serving: this guy seems to be intent on getting more companies using what he has to offer Conclusion: mind the hyperbole.
- mickael 20y ago
  Hello, Of course, it is self serving, like 37signals buzz on Ruby was self-serving too. I does not mean that you have to trust me. You can check by yourself and make your own opinion. I really doubt that people will switch to Erlang because I said it is the way to go. They will do so because they have assessed the technology as an alternative. My goal is only to make Erlang known as an alternative for large scale infrastructure, which is not the case now. Nothing more.
bootload 20y ago
there are no 'silver bullets'. google has solved the 'get massive' partly in using the 'Map Reduce' [0] algorythm written in cpp. So looking at one particular language [1] alone to solve the problem(s) of parallel processing is bogus. Reference [0] Map Reduce, 'Google MapReduce tool' http://en.wikipedia.org/wiki/Mapreduce [Accessed Tuesday, 6 March, 2007] [1] Joel On Software, 'Can Your Programming Language Do This?' http://www.joelonsoftware.com/items/2006/08/01.html [Accessed Tuesday, 6 March, 2007]
- mickael 20y ago
  I am not talking about silver bullet. I am talking about alternatives. For now people largely think that ther is only one way to do it. The point of my article is to show that there is more than one way to do it and that it might pay off to think about this before hand if you have to make a living of a web-based service.
  - bootload 20y ago
    '... I am not talking about silver bullet. I am talking about alternatives. For now people largely think that ther is only one way to do it. The point of my article is to show that there is more than one way to do it and that it might pay off to think about this before hand if you have to make a living of a web-based service ...' I totally missed this in the article mickael. I'll go with TIMTOWTDI [0] anytime. I'll go back and read it again :) Reference [0] TIMTOWTDI, 'there is more than one way to do it, perl motto" http://www.perlmonks.org/?node_id=52073 http://www.perlmonks.org/?node_id=52073 [Accessed Wednesday, 21 March 2007]

4 points by python_kiss 20y ago

The overall point is valid -- having a lot of users is the main way that a lot of companies make/want to make money, therefore companies should focus on scaling issues, therefore... "use Erlang." However, conflating Web 1.0 "get fast" with Ruby on Rails "develop fast" is: 1) wrong: with extremely limited resources and a long list of priorities, startups need to start with fast, basic tools in order to get a functional site up -- to then discover what people want to use. scaling comes later, if ever. 2) self-serving: this guy seems to be intent on getting more companies using what he has to offer Conclusion: mind the hyperbole.

mickael 20y ago
Hello, Of course, it is self serving, like 37signals buzz on Ruby was self-serving too. I does not mean that you have to trust me. You can check by yourself and make your own opinion. I really doubt that people will switch to Erlang because I said it is the way to go. They will do so because they have assessed the technology as an alternative. My goal is only to make Erlang known as an alternative for large scale infrastructure, which is not the case now. Nothing more.

bootload 20y ago

there are no 'silver bullets'. google has solved the 'get massive' partly in using the 'Map Reduce' [0] algorythm written in cpp. So looking at one particular language [1] alone to solve the problem(s) of parallel processing is bogus. Reference [0] Map Reduce, 'Google MapReduce tool' http://en.wikipedia.org/wiki/Mapreduce [Accessed Tuesday, 6 March, 2007] [1] Joel On Software, 'Can Your Programming Language Do This?' http://www.joelonsoftware.com/items/2006/08/01.html [Accessed Tuesday, 6 March, 2007]

mickael 20y ago
I am not talking about silver bullet. I am talking about alternatives. For now people largely think that ther is only one way to do it. The point of my article is to show that there is more than one way to do it and that it might pay off to think about this before hand if you have to make a living of a web-based service.
- bootload 20y ago
  '... I am not talking about silver bullet. I am talking about alternatives. For now people largely think that ther is only one way to do it. The point of my article is to show that there is more than one way to do it and that it might pay off to think about this before hand if you have to make a living of a web-based service ...' I totally missed this in the article mickael. I'll go with TIMTOWTDI [0] anytime. I'll go back and read it again :) Reference [0] TIMTOWTDI, 'there is more than one way to do it, perl motto" http://www.perlmonks.org/?node_id=52073 http://www.perlmonks.org/?node_id=52073 [Accessed Wednesday, 21 March 2007]