131–140 of 177 posts
His point is valid, but the bottom line is that hardware resources are far cheaper than human resources today. Yes, many of us know C, but a lot of us would rather use the abstractions provided by scripting languages.
Earlier quoted context omitted.
Even though the tone of the article was abrasive, it was far more interesting and insightful than the one-line comment to which I responded. Your asserted arguments for dynamic languages are well-trodden ground: Assertion: "Some scripting languages are as fast as compiled languages." No, not really. I challenge you to prove that statement with a non-trivial benchmark. Assertion: "most of the time, web apps are waitin…
"There's no reason that it can't be handling other requests while waiting for a DB response or a pipe." Concurrent request processing most likely belongs in the server, not in the application. "Scaling Rails is a nightmare." For someone who complains of "well-trodden ground" in others' arguments, you certainly seem to have a deeply-rooted belief in the myth that particular languages and/or frameworks "scale" or "don'…
Plus there's the whole portability thing, which is entirely pissed away by C compilation (yes, arguably you can write generic C, but there are fundamental differences (file i/o, sockets, etc.) between different OS's, and restricting yourself is dumb)
Pre-compilation of scripting languages isn't necessarily a bad thing though.
And this guy is no C expert. He's just got a golden hammer. http://en.wikipedia.org/wiki/Golden_hammer
Earlier quoted context omitted.
Even though the tone of the article was abrasive, it was far more interesting and insightful than the one-line comment to which I responded. Your asserted arguments for dynamic languages are well-trodden ground: Assertion: "Some scripting languages are as fast as compiled languages." No, not really. I challenge you to prove that statement with a non-trivial benchmark. Assertion: "most of the time, web apps are waitin…
"Scaling Rails is a nightmare." I find this similar to Woody's fear in the following exchange: Cliff Clavin: Boy oh boy, talk about your lucky days, huh, I just found twenty smackers back there in the pool room. And to celebrate my good fortune, I'm going to buy a round a drinks for all my friends. Carla Tortelli: What are you going to do with the other nineteen bucks? Sam Malone: Woody, that could be your twenty dol…
In any case, at this point I think it's fairly safe to say that I have some direct experience scaling Rails, and it's not as easy as the hand-wavers suggest. It's certainly worth a bit of work early on to avoid the nightmares that come with trying to scale something like Rails later on.
Not to be too silly, but if someone wrote a web framework in C++ that was 10% more difficult than Rails, I'd still consider it. The distribution of suck for Rails is exponential over time, so the expected value of suck is much higher than it initially seems.
Earlier quoted context omitted.
I think Mibbit, much like twitter, is one of those apps that is a non-traditional webapp. While its a web based frontend the traffic and distribution of chat messages is a much different beast then what most webapps do. Java is very likely a much better choice for these reasons.
Twitter runs under serious load using "scripting languages". The issue is runtime, not language.
Earlier quoted context omitted.
"If a web app is spending most of it's time blocking for I/O, it's poorly designed. There's no reason that it can't be handling other requests while waiting for a DB response or a pipe" If your request-handling logic is responsible for concurrent requests, your application (and the platform it runs on) is poorly designed. This belongs to a thread/process dispatch mechanism in the platform, not inside your app. When o…
In my experience once you get over a few hundred thousand users and have tweaked your web server/proxy setup and tuned your database, you will still have major slowness and memory issues with your Rails code. I.e. it's usually not the database's fault. Also you might want to look at the profile of the guy who said that rails scaling is a nightmare. I wouldn't use the word nightmare as I'd prefer to think my professio…
The beauty of the ORM is that you can replace the underlying layer without disrupting the code running on top or add fancy things like local memory caching or a networked memcached store. I insist that if your application was built from the start with this kind of issue in mind, it will be easy to scale it if and when the time comes. Until then, you are solving a problem you don't know you have.
This gets harder the lower-level your language gets.
Earlier quoted context omitted.
The VisualWorks Smalltalk Server Pages framework already does this. SSP results in web pages as compiled machine language. The HTML file is translated into a new Smalltalk method, the tags become Smalltalk message sends, and the HTML between the dynamic tags just become accesses into an Array. Because Array access is optimized and JITed as machine code, the only message sends are due to the dynamic tags. When the web…
I believe the framework discussion is of a compiled C "Rails" type MVC framework, I'm not familiar with Smalltalk Server Pages but from an initial google search it doesn't seem to be on par with what rails provides?
Earlier quoted context omitted.
At least he's planning on putting his money where his mouth is. If he creates this framework, more power to him!
The VisualWorks Smalltalk Server Pages framework already does this. SSP results in web pages as compiled machine language. The HTML file is translated into a new Smalltalk method, the tags become Smalltalk message sends, and the HTML between the dynamic tags just become accesses into an Array. Because Array access is optimized and JITed as machine code, the only message sends are due to the dynamic tags. When the web…