Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Applications Should Be Compiled

ediblepet.net

Post reply on HN
Print view View original

61–70 of 177 posts

Re: Web Applications Should Be Compiled

#61

Post by kingkongrevenge »

axod wrote: post #53
jerryji wrote: post #51

Earlier quoted context omitted.

But as your web application database grows more complex and larger, how do you intend to make them keep up with the 2k req/sec load?

Why would anything need to go to db? :/ Going to db should always be a last, final resort. People often seem to think a db is the only way to write any webapp, and that everything must depend on the db. That's bad architecture. In the case of Mibbit, db access is only done for writes, lazily, in the background. The bottlenecks for me, are CPU, network, and ram. And yes, you can throw servers at it, if you're frivolou…

The vast majority of web applications are straight-up CRUD. Not making that all about a normalized schema is the stupid mistake.

As far as relational DBs being the problem, that's more a matter of the free ones not cutting the mustard. Oracle and DB2 can handle jaw dropping load in the hands of an expert.

Re: Web Applications Should Be Compiled

#63

Post by knowtheory »

Guys, his point isn't valid. If you want to write things in C, the current implementation of ruby LETS YOU. That's the whole point of C extensions.

You can then ask, why bother writing in Ruby at all, and i think you'll find the answer to be, it's not anywhere near as much of a pain in the ass as writing C is.

The elitism argument is bullshit. We don't need fewer people programming. We need better ways to tell if someone knows what the fuck they're doing.

In my opinion the tools we use and develop should be as accessible as possible. Anyone should be able to pick them up and get what they need to do, done. Good luck doing that with C.

Re: Web Applications Should Be Compiled

#64

Post by bad_user »

bensummers wrote: post #33

Aside from the fact it's an obvious troll... I had that basic idea when web app frameworks starting becoming popular. So I implemented a web framework which took a 'description' of the app written in perl, and generated C++ which compiled into a single exe file which served the app with a built in http server. Small bits of business logic were written in C++, but basically it was done by the perl. All templates, inte…

I like Perl ... using modern Perl practices and CPAN modules. It's the best web development environment I worked with ... and I've worked on projects with PHP (my own framework :) + Symfony), Python/Django/web.py, ASP.NET, Java/Struts and Ruby/Rails.

You should give it another try sometimes. Take a look at Catalyst (the web framework), DBIx::Class, Moose and POE.

Re: Web Applications Should Be Compiled

#65

Post by greyboy »

kingkongrevenge wrote: post #61
axod wrote: post #53

Earlier quoted context omitted.

Why would anything need to go to db? :/ Going to db should always be a last, final resort. People often seem to think a db is the only way to write any webapp, and that everything must depend on the db. That's bad architecture. In the case of Mibbit, db access is only done for writes, lazily, in the background. The bottlenecks for me, are CPU, network, and ram. And yes, you can throw servers at it, if you're frivolou…

The vast majority of web applications are straight-up CRUD. Not making that all about a normalized schema is the stupid mistake. As far as relational DBs being the problem, that's more a matter of the free ones not cutting the mustard. Oracle and DB2 can handle jaw dropping load in the hands of an expert.

Is DB2 not free? I thought they had a free version?

http://www-01.ibm.com/software/data/db2/express/about.html

Re: Web Applications Should Be Compiled

#66

Post by swombat »

axod wrote: post #16

It's a valid point. I wrote the Mibbit backend from scratch in Java for these reasons. I can only start to imagine the horror I would be enduring if I'd chosen a scripting language. Having said that, choose the right tool for the job. edit: Downmod me all you like. A scripted language wouldn't handle 2k req/sec on a couple of VPSs.

It's a valid point for Mibbit, but Mibbit is not your average web app.

For the average web app, it's a lousy point, really (and, as pointed out by others, it's a troll/satire).

The fact that you take it seriously is a little worrying tbh. Are you feeling ok? :-)

Re: Web Applications Should Be Compiled

#67

Post by e4m »

torr wrote: post #43
vidarh wrote: post #22

Earlier quoted context omitted.

Because most scaling problems in web apps are ultimately architectural. Yes, you may need to buy a second server sooner rather than later if you run Ruby instead of finely tuned C or C++, but for most apps you're going to need to worry about a second database server and replication before that, and long before reaching either you will have enough traffic that you'll need to prepare to handle front-end scaling properl…

> As for developer availability - good luck to him finding good C programmers Are you saying it's difficult in general to find good C devs? Because it would seem that's the case for C++, but not for C.

I'm not sure that's accurate. c++ is a large language. Finding developers who use the parts of c++ that you need to get the task done is easy (boost, qt, stl, wx, etc). Finding developers that know all of c++ is next to impossible. c++ is large because it can solve very large, very complex problems, but not every c++ application attempts to do this. c++ can be used in very simple ways too and many people use it in that fashion.

Re: Web Applications Should Be Compiled

#68

Post by gamache »

silentbicycle wrote: post #27
grayhacker wrote: post #21

No. You really don't want to do this. Really. I have worked with a project for the past several years that, by necessity not choice, required a web application framework written in C (it's an embedded platform) and I can tell you it is pure hell. The most mundane and simple tasks, often trivial one-liners in scripting languages, require many lines of error-prone C code even with a fairly rich set of libraries availab…

Would Lua have worked there? It's a ~200k library designed to provide an embedded scripting language to C projects. (It's very similar to Python, but a tenth the size, and with a bit more Scheme influence.) While it may be too big for some especially tight embedded platforms, if you could fit it in, it would have likely been substantially less painful. It's also a pretty good scripting language on its own merits, and…

Lua is meant for embedding in C programs; that is different from running on embdedded systems. The latter typically features drastically less RAM and CPU cycles, so most interpreted languages (which are not shy about trading away some performance) don't cut it. There are some exceptions; FORTH, for instance, can fit in about a kilobyte and its performance isn't miserable. But putting e.g. Lua in a confined space would not work out well.

Re: Web Applications Should Be Compiled

#69

Post by swombat »

zepolen wrote: post #28
sounddust wrote: post #11

Earlier quoted context omitted.

If your site starts to take a performance hit in rendering pages, you can simply write a module in C to handle the part of the script that's using an excessive amount of CPU time, and keep the rest in script. But for most web apps, rendering HTML pages from script is not the bottleneck, it's the interaction with the database, and the solution is intelligent caching to reduce load on the database. The tools to mitigat…

Reread what you wrote :) Once you lower the the db io issues, rendering does become the bottleneck. Luckily rendering scales just by adding more servers. Rewriting templating code in C though rarely adds more speed, most dynamic languages tune their string handling as much as possible. Also, utilizing http caching mechanisms are a (quite underused) great solution for lowering load.

Reread what you wrote :) Once you lower the the db io issues, rendering does become the bottleneck.

Not really. Sending and receiving data to/from the browser becomes the bottleneck.

If it takes 50ms to receive the query from the browser, 0.1ms to retrieve the data from the cache, 10ms to render it, and another 50ms to send it back to the browser - the bottleneck is now network communications with the browser.

There are, unfortunately, limits on how much that can be improved.

Post reply on HN