

Web Applications Should Be Compiled - csbartus
http://ediblepet.net/2009/05/23/web-applications-should-be-compile/

======
raganwald
I will live to be a happy old man if I never read another blog post telling me
in absolute terms what I _must_ do and why I'm an idiot if I don't. I blame
Joel Spolsky for this, his tone and style seems to have kicked off an entire
sub-culture of blogging where the posts read like a lunatic standing on a
street corner demanding that we repent before the end of the world and the
coming of the messiah.

Bloggers, please try a kinder, gentler tone, one that suggests you and I are
colleagues. One that suggests you have discovered some neat thing and won't I
have a look at it and isn't it interesting to play "what if" games with it and
maybe, just maybe I might experiment with it.

Looking back on my own posts, I would say the strongest ones are those where I
found a more reasoned voice. An essay can be strongly opinionated without
being imperative.

~~~
axod
I agree, but TBH there have been a lot of ridiculously overhyped blog
posts/articles telling us how totally _awesome_ every scripting language is,
and how it's completely a 'game changer' and how you can do completely
revolutionary things in them really easily.

I guess this is just a reaction to the froth+hype. Both sides need to step
away from the keyboard, and calm down.

~~~
raganwald
If a blog post says "wonderful, amazing, fun, life-affirming," we can always
respond with "oh? what about..." My thought is that there's no need for a post
saying "You're gonna die if you try to build a social bookmarking site in
Lisp" regardless of how much fun other people are having doing it.

What have people got against enthusiasm, any ways? There's some kind of weird
puritanical thing going around programming culture that seems to view youthful
exuberance as some kind of a sin, like wearing buttons on a frock coat. Yeah,
some twenty-somthing year-old has discovered something way-cool really neat
amazing thing while hacking on a macbook in the café. Isn't that exactly the
attitude you're supposed to have in your twenties? How would anything ever
change if people didn't get super-excited beyond all rational limit?

Can you imagine Wozniak and Jobs trying to blog about microcomputers these
days? They'd get flamed as hippies fiddling with toys :-)

~~~
edw519
"Isn't that exactly the attitude you're supposed to have in your twenties?"

Why stop? It's a great attitude to have forever.

~~~
raganwald
Does my writing read like I'm telling kids to get off my lawn? If so, please
tell me, I own a funhouse mirror. When I look into it, I see a guy that still
loves programming and thinking about for its own sake...

------
PhilChristensen
Sweet merciful lord. Is this guy channelling Zed Shaw or what?

Apart from all the hand-waving and generalizations, this guy doesn't sound
like he's ever really a webapp under serious load.

I'm not a Ruby guy, so I don't know how things fly with that, but I've never
once had a problem with a webapp being slow because of the language it was
written in. Bad database queries, unnecessary assets being loaded, definitely.
But CPU-bound limitations caused purely because of the cost of interpretation
of a scripting language? Not so much...

~~~
timr
I've worked on a webapp under serious load, and I think he's right.

You're correct that database queries and resource bottlenecks are the usual
problems for web application scaling, but even taking that into account, I've
had more than one problem that was caused by the simple fact that Ruby is a
dog of a language. Python is better, but only just so. Perl is faster than
both, but still nowhere near as fast as a C++ program.

But let's ignore execution speed, since one can make a reasonable argument
that even the slowest scripting language can saturate the network I/O on
modern hardware. I think I'd still consider using a compiled language, because
the type-safety and compile-time guarantees of a statically typed language
would go a long way toward eliminating a huge class of silly bugs that we deal
with on a daily basis. That's developer time in the bank.

~~~
apgwoz
> I think I'd still consider using a compiled language, because the type-
> safety and compile-time guarantees of a statically typed language would go a
> long way toward eliminating a huge class of silly bugs that we deal with on
> a daily basis.

Not all compiled languages are statically typed.

> That's developer time in the bank.

And the time spent in the edit, compile, test, run, cycle? I'd think there's
more developer time in the bank if I can edit, test, run.

~~~
timr
No, not all compiled languages are statically typed. I wouldn't use those
languages.

The time spent compiling is a red herring. I know that I've spent dozens of
hours chasing down weird runtime bugs in Ruby that a C++ compiler would have
caught for me during static analysis. That time more than makes up for the 15
minutes a day I might spend waiting on a compiler (I waste more than 15
minutes a day on coffee breaks!)

------
bensummers
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,
internationalisation, everything, compiled down to a few database queries,
string concatenations and the odd if statement.

I then build a couple of production sites in this, one on my own, and another
with a few other developers.

Conclusions from this:

1) It's really really fast and efficient, and the single exe model for
deployment is lovely.

2) It's a pain to implement such a framework, and a pain to use it.

3) I'm never using perl again.

4) Life's too short for this kind of game.

The code is here: <http://www.boxbackup.org/trac/ticket/6>

~~~
bad_user
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.

~~~
bensummers
I think I just got a bit fed up of the crufty syntax for object-orientated
code.

Everything computer-related sucks, you just have to choose something which
sucks the least where it matters for your project. And familiarity counts for
a lot too.

------
grayhacker
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 available. Working
in this environment, you'll quickly realize why the rest of the world doesn't
do it this way. Thankfully, this project is finally moving away from this
architecture and I couldn't be happier about it.

~~~
silentbicycle
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 has replaced
Python as my default language. (Unlike Python, its design expects you to know
at least a little C, but in exchange, it avoids cluttering the language with
things that C already does well.)

~~~
gamache
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.

~~~
silentbicycle
To my understanding "embedded systems" spans from something with 1k of memory
to something like a cell phone or a router. Working with Lua is quite
comfortable _on the latter_ , hence my qualification. It's been ported to Lego
Mindstorms (<http://www.hempeldesigngroup.com/lego/pbLua/index.html>), for
example, which is "a 32 bit ARM7 microcontroller with 256K of FLASH and 64K of
RAM."

It's not clear from the post which end of the spectrum he or she works with.
(I don't work with embedded systems professionally, I've just tinkered with
OpenWRT, cell phones, etc. as an enthusiastic amateur.) It would be usable in
the same niches that SQLite is, for example.

------
axod
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.

~~~
mikeryan
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.

~~~
tptacek
Twitter runs under serious load using "scripting languages". The issue is
runtime, not language.

~~~
Tichy
Scala is not a scripting language.

~~~
tptacek
"Scripting language" is a stupid term, but it's the term the article used.

------
mdasen
The reason why people choose to go with languages like Ruby is because the
trade-off on speed is worth it.

Web front-ends scale very easily. You can just add more web heads and load
balance between them. Databases are much harder to scale since you need to
keep data consistency and can't just throw more boxes at the problem.

So, you don't _need_ to be computationally efficient. However, you do need to
develop fast. You need to be able to create features before your competition.
You need to be able to make your system more reliable and bug-free than your
competition. And that's where Ruby (and similar languages) helps you.

Sure, you and Linus have a point that selection of language can keep out the
riff-raff (Linus Torvalds having a huge rant against C++ simply because of the
programming community), but it also means that you're missing out on the good
parts of the community. Ruby programmers tend to put a lot of thought into
user experience. While you've ranted against testing, I don't think any IT
manager would agree with you there. Testing substantially improves one's
ability to create new features because you can easily spot anywhere you've
broken something. And that leads to better quality applications too.

There's a difference between speed and scaling and if something scales fine,
that's ok. Look at it this way, array indexing in a slower way to go through
an array in C than incrementing a pointer. And if you had a lot of code you
could go through and change all instances. However, it wouldn't be worth your
time. Such an improvement wouldn't net you any real benefit while you'd be
neglecting improving your product.

Your product is what matters.

~~~
baguasquirrel
I think your point is exacerbated by the fact that it's hard to get web UIs
"right". I was critical of languages like python and ruby until I had to do
the frontend for some company code. Box looks like it needs to be shifted a
few pixels right? Modify code, compile, check. Logo looks better with an
offset? Modify code, compile, check. Writing in a scripting language makes it
just Modify, check.

You just can't do that in compiled languages, and the compiled language of
choice for the web-- Java --isn't known for blazing compilation speed. You'd
probably also have to jar it up and copy the damn thing over, whereas psps
could be modified in-place. I think this is something that compiled folks like
me simply failed to grasp: all the things about scripting languages that make
them orders of magnitude faster for developing, especially for the web.

~~~
ontilt
I've done a lot of webapp development in both Java and Rails. I would agree
that the iteration cycle is shorter in Rails, but it's not as bad as your
description makes it sound. If you have to redeploy a jar file as part of your
development process, then that's a problem with your process, not your
language.

When I do Java webapp development in Eclipse, it compiles and hot-swaps my
code in the background without requiring any restart or redeployments. Works
pretty well.

I do have to restart occasionally because the hot-swapping has limitations, so
that does slow things down a bit, but when you consider the time saved by
having good compiler integration, then I don't think there's a big difference
in productivity.

~~~
baguasquirrel
Good point. Thanks for the tip! :)

That said, I don't need no stinkin IDE integration for .psps. Being able to
log in remotely and edit something with vi is kind of handy.

------
wooby
I wrote the upload and download handlers for droplink.me in C as FastCGIs,
anticipating performance problems. I built it; but they never really came. It
was a fun exercise, but if I wasn't interested in having fun with C, I would
have written it in a dynamic language.

I think the reason there isn't a "C web development community" is that
programmers are more than willing to trade time for performance. Safe,
readable code can be written in high level languages in a snap. You can see
your ideas happen very quickly. If you run into performance problems (which I
think is safe to say is a fairly rare occurrence for the average web developer
who produces decent code, in any language), you can a) refactor or streamline
what you already have or b) start fresh, lessons learned, in something lower
level.

An aside: the site <http://halfbakery.com> is implemented entirely as an
Apache module.

------
jimbokun
Not a bad troll. Not the best I've ever read, but not bad, either.

~~~
dryicerx
I don't think it's a troll, but just someone who is really in to performance,
like I do, and I agree with him on some points.

But what I don't agree is using just C. C is too low level and is a horrific
unfit task for web development. Instead C++ would be a good fit (and writing
in C mixed in). The STL/Boost provide a wonderful abstraction layer that does
pretty much anything you throw at it with ease, plus there are lot of other
libraries for anything else you can ever think of. I've written several web
applications in C++, and it was actually very much like writing in
Python/PHP/Ruby and at time prefered writing it in C++ after writing a poc in
a scripting language. They were just a little bit less readable but very
clean, but the biggest plus the the multiple magnitude performance increase of
the application it self with FastCGI. (all these applications were serious
number crunchers and had lot of CPU and Memory Bound problems).

tldr; C for web dev painful, C++ with STL/Boost good/easy/fast/clean.

Also I've heard of wt, a C++ web framework although I've never used it
<http://www.webtoolkit.eu/wt>

~~~
grignr
I've been hacking C++ long enough to agree C++/STL/Boost is good and fast...
but I can't remember the last time I heard anyone accuse C++ of being
_easy_...

~~~
e4m
I find it easy. The bad thing about c++ is its size. It's large and that tends
to make it complex. However, I find that I only use about 40 to 60 percent of
what c++ can actually do. Focus on the parts that you use and you'll find a
lot of the complexity goes away.

~~~
silentbicycle
One problem is that if you work with other people in c++, the 40 to 60 percent
they use won't necessarily overlap with yours.

~~~
fauigerzigerk
If you work with other people, the odds of their C++ code being utterly
broken, inefficient and dangerous is 99% ;-)

~~~
silentbicycle
Hey, I was showing restraint. ;)

------
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.

------
jerryji

      > So this is why I’m writing a web framework in C.
    

Why C, why not assembly? In fact, you know what real programmers use? --
<http://xkcd.com/378/>

    
    
      > Grow the fuck up...
      > finding Rails developers is fucking impossible...
    

You grow up

    
    
      > ediblepet.net is proudly powered by WordPress
    

When will you release your compiled blog platform?

~~~
burke
Oh, you haven't heard? He ported WordPress to C. I was pretty impressed.

~~~
petercooper
Did he outsource it to Tim Ferriss or something?! I thought he was busy
finishing off Duke Nukem Forever.

~~~
burke
Yeah, I heard it only took him four hours, too.

------
laktek
Actually the same people he bash, did it before him. Remember Campfire's
poller was written in C?

Only recently they decided to change it to a must robust Erlang based
implementation - [http://www.37signals.com/svn/posts/1728-nuts-bolts-
campfire-...](http://www.37signals.com/svn/posts/1728-nuts-bolts-campfire-
loves-erlang)

------
JulianMorrison
Ruby vs C misses out the middle ground of SBCL, Java, Scala, Haskell.

------
jerf
Actually, the problem isn't compiled vs. non-compiled, the problem is C vs.
languages that you can actually safely manipulate strings in without
segfaults, buffer overflows, and other "own the box/own the webservice" flaws.

Arguably, all the languages that show up down near C in the Shootout would be
fine languages to write webservices in, since nearly all of them are as fast
as C without the eXtreme danger.

Some web services are "shovel strings from the DB out to the user", like CMSs,
but for those that aren't, this isn't a terrible point.

(It's easy to forget when you're the type of person who hangs out on HN, but
for most people, compiled == C, or C++ if you're lucky.)

------
ryah
Web site performance problems usually don't have much to do with the raw
executing speed of the language they're written in. The problems derive from
poor understanding of how to handle concurrent connections. If your app is
written in C, but is accessed through a CGI interface - starting a process for
each request - then it's going to be slow. Similarly if you write a web server
which makes blocking connections to a backend database, your server will be
slow. If you use threads to handle concurrent connections, you're going to
allocate 2mb stacks for each user - and your website is going to suck. This
all has little to do with how fast a language can invert a matrix.

~~~
warfangle
And then there's situations like porting a Rails app to Lift and seeing a huge
improvement in performance without touching the database / storage IO:
<http://lambda-the-ultimate.org/node/2147>

Granted, it's not from the most unbiased source, so take it with a grain ;)

~~~
ryah
That has to do a lot with Ruby's awful thread implementation. You could
possibly port the app again to Ruby EventMachine and see even better
performance.

The point is - for 99% of people it's not the language, it's the I/O

------
nathanwdavis
There are already a few options for a MVC web framework in compiled code. I'm
working on ASP.NET MVC now. It's compiled, but development does not feel like
that because of JIT compilation. Also, it will run in Mono on Linux if I want.

~~~
vyrotek
I love Asp.net MVC :)

------
goodkarma
If you're going to write it in C, why not just write it in Java? You could use
the Google Web Toolkit..

~~~
jdbeast00
removed ... i'm embarrassed at the wrongness of what i typed

~~~
jimbokun
Kind of. Similar syntax and design patterns, but I don't think you can
directly compile a Cocoa application to Cappucino, or vice versa.

------
Deadly_B
I notice comments on the blog post are currently closed. I wonder why. ;)

Although I understand the author's position, it is obvious this is a tech
person and not a well-rounded business person. The thing about programming is
it's not all about tech.

A program typically serves one purpose: to make a company money. This requires
more than just pristine tech. First and foremost it requires time to market so
that a company can stay competitive. It also requires the ability for more
than just a handful of people to be able to write it for expandability and,
God forbid, staff changes.

C is fast. But slow to market. And slow to pick up a program. And slow to
test. That's why there is so much WYSIWYG.

Don't get me wrong: there needs to be a lot more code behind and a lot less
script out there, but in the end coding is a balance. Anytime anyone says it's
all this or all that, you know the position is not sound. It's part speed,
part usability, part scalability, part development speed, part readability,
part expandability, part pretty pictures, etc. Balance in all things.

------
maigret
That is why there are things called "application servers". Java is not perfect
but it has a fine feature called JIT (Just In Time compiling) that produces
machine code whenever it makes sense. Raw compiled language goes against the
current trend for virtualization, whose goal is to save energy too. So in my
opinion JIT is a good solution.

------
petercooper
_I chose C because C is the dominant language right now_

Good bit of satire. I wouldn't call it a troll because it's funny and just
unbelievable enough, rather than inflammatory and merely misguided.

~~~
icefox
Indeed, I would have to say that Javascript is the dominant language right
now.

------
st3fan
I don't think the guy is troll. I think he simply doesn't know better. This is
a classic case of micro-optimization. While he should look at the bigger
picture. It is all about global architecture.

------
tlrobinson
No, the solution is not to write web application in C, it's to make faster
interpreters for higher level languages.

I like not having to worry about buffer overflows and memory management and
such.

That said, I'll be interested to see what he comes up with.

------
piramida
Funny article, I hope the author was not being serious. C is everything when
you need performance, but having something done quick _and_ maintainable - in
C - no sorry. If somebody would dare to actually create a rails or django
level framework in C it would simply have no community - not because it won't
be 'hip' - I'd use it - but because implementing the same app would take
exponentially more time. And that's what matters in the webworld.

No matter how many rps your app can serve, if there is no app you get no
requests to serve...

------
avibryant
Has anyone else actually looked at this guy's code?
<http://github.com/joelmichael/memereap/tree/master>

Perhaps unsurprisingly, it shows no awareness of SQL injection, buffer
overflows, or concurrency. These seem like things a web framework might need
to deal with...

------
alexgartrell
I would NOT trust a website with my private data if they wrote their app in C.
Buffer overflow -> execute your own code -> write a function that pipes an
entire database out to you. It really is a _trivial_ problem given the buffer
overflow, and programmers (myself included) generally suck at not putting
buffered overflows into code.

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>

------
edw519
"I predict in the future all the good web engineers will be moving to compiled
languages, and all the academic idiots programming social networking
applications, ajax widget home pages, and projects to better improve our
democracy will be staying behind coding in the latest and greatest slow
language, going to circle jerk conferences to hear some scumbag just oozing
hubris from every pore tell them to get in shape and learn to fly a kite."

+1 for "academic idiots"

+1 for "improve our democracy"

+1 for "circle jerk conferences"

+2 for "scumbag just oozing hubris"

I just hope his c isn't as poetic as his prose.

------
e4m
I have done this in c++... not write an entire web framework, just use
compiled c++ code to do some heavy lifting on a shared web server. It worked
great. Before, I was using python/django. c++/cgi did the same task and was
about 30 times faster.

I'm not sure I'd throw away the scripting languages entirely, but making it
easy to integrate c or c++ into these languages in this manner is probably a
good idea. It's not that hard to write very highly optimized c++ and it can
have a huge impact on performance... at least that has been my experience.

While the article was inflammatory, I think the guy has a valid point. He just
needs better people skills ;)

------
vlod
The first thing that came to into my head was 'What problem is he trying to
solve?'

Does he have performance problems? Is it cost effective to solve those
performance problems using C? What is the ROI?

Has the performance problem been analyzed to a degree that its been identified
that its the web framework? (Most of the time a decent database index will
help)

Go after the lower hanging fruit first and make decisions on quantitive data
analysis.. not just your gut.

------
trjordan
Ranting aside, this seems like a valid complaint. Scaling and performance seem
to be reasonably important in web applications, so why not write them in C? If
the only complaint is the lack of good tools, why not build those tools?

Disclaimer: I don't actually work on web apps, and therefore have no
experience with these things.

~~~
vidarh
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 properly soon anyway.

An example - from messaging middleware, not web frontends since it's somewhere
I _do_ have proper data:

I did a messaging middleware system in C a couple of years back. It's easy.
I've done it before. After a while needs were changing and I decided to try
writing the replacement in Ruby. It was a lot quicker to write (1/10th of the
code size for roughly the same feature set).

We were handling 3-4 million events a day, which could easily result in 2-10
messages each.

The Ruby replacement spent 10% of a single 2Ghz Xeon core handling those
messages. Of that 90% was spent in the kernel handling system calls that
would've been roughly the same in a C/C++ version.

Even if the Ruby part of the equation was 10 times slower for the userland
part, the most we'd have saved for our load was 0.9% of a single core. The
most we'd save overall, regardless of scale, would be around 9-10%.

Doesn't mean there aren't things for which a language like C is better suited
- I did my MSc. thesis on reducing error rates for OCR, and some of the image
processing I did was prototyped in Ruby, but then translated to C for the
final version because processing literally would've taken days for things that
took less than an hour in C.

But scaling is very often constrained by other things than the performance of
the laguage you write your app in. _Especially_ in the web space where most
interesting apps are database backed.

If your DB gets maxed out, having a hyper-optimizing compiler is not going to
help you. If your app isn't designed to be scale across multiple servers (or
at least cores - these days you can rent managed hosting on a 24 core server
for less than $1k/month) you could very likely be screwed in ways that no
compiler will save you from.

The extra developer time spent doing web development in low level languages is
unlikely to be worth it unless you're at a massive scale.

If you can fit in 24 cores with a language like Ruby, your best case saving
from switching to a compiled language these days is around $10k/year on
hosting if you're ok with a single server, and about $20k if you want
redundancy.

That doesn't pay for a lot of wasted developer time. Most web apps can fit in
that, and for the lucky (or unlucky, depending on reason) that need to scale
beyond that, the CPU time spend on the actual web app is likely to be a
relatively small fraction of the total CPU time spent (on databases etc.) -
architectural decisions is likely to be a far more important cost driver than
the language of the web frontend.

As for developer availability - good luck to him finding good C programmers,
and even more so finding good C programmers who aren't expensive _and_ knows
web development.

~~~
torr
> 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.

~~~
e4m
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.

------
sounddust
It's been done. <http://advogato.org/proj/mod_virgule/>

------
rythie
Most sites aren't CPU or memory intensive. If you are lucky enough to have
enough users for that to be a concern you can add more servers. Sites normally
bottle neck around the database and writing front end code in C is distraction
from fixing the real problem which should be scaling the database.

~~~
worldhello
Why not use clearsilver(<http://www.clearsilver.net/>) to wrote frontend code?
They do have a few large projects using clearsilver.

------
marcofloriano
I think you don´t have to stick with C (or any another language ) for
everything. Each language are good for something. Right now, for example, i´m
working in a financial intelligent software analyzer. I wrote the web crawler
in ruby (not rails) and now i´m planing to write the core of the system, the
decision maker, at Lisp. I think a programmer should not be sticked with just
one language, there´s a lot of cool things out of the C world. You dont have
to write an entire C framework to build an web apps at C ... it´s just too
troublesome. You have another challenges. But when it comes to process data
very fast in your server, so maybe you should consider another language.

------
niyazpk
In web the model is different: You develop an app, push it live and find out
what works and what does not, change and iterate.

This means that doing the iterations with minimum time and effort are
important than worrying about scalability and performance.

You can always throw hardware at the perfortmace problem. If you get enough
traffic to become worried about performace, that itself is the mark of
success. But to become successful, first you must build the app and get it
live somehow instead of worrying about performace issues or wasting months
coding in some very low level language!

~~~
CodeMage
_You can always throw hardware at the performance problem._

No, you can't. That's what scalability _means_. If you don't have scalability,
then additional hardware will only take you so far before you begin wasting
it.

~~~
nostrademons
Many dynamic-languages frameworks (notably PHP) are _more_ scalable than
writing a custom webapp in C. This is because C encourages you to store state
in memory on the server, because it's really easy when everything is a single
long-lived process. Good for performance, terrible for scalability.

PHP (and Rails/Django, if you ignore their ORMs) encourage you to store state
on some collection of backend servers and communicate via RPC to retrieve
that. This is bad for performance, but good for scalability. The front-end is
just a dumb intermediary that converts data into HTML, so if you need to
scale, just add more of them. Scaling the backend is more challenging, but at
least you can do it without dragging all the front-end code around.

~~~
CodeMage
Absolutely! Just for the record -- since people seem to assume otherwise --
I'm not agreeing with the article. I'm just disagreeing with the idea of
ignoring "scalability and performance" and then expecting to solve performance
problems by "throwing hardware" at them.

------
wglb
Well, if I were forced to write in C these days, I would seriously write a
C/C++ generator in Lisp to speed the time to market.

But if I could do it where nobody was watching, I would use a different
compiled language, Lisp (SBCL) that would get good enough performance and get
to market before the manly C/C++ coder.

So on a semi-serious note, why is (apparently) nobody going for the real
performance kill, which is to write a framework in hand-coded assembler? Would
it be twice as fast as C?

------
snorkel
If you must write web apps in C then consider writing it as an Apache module.
But how much traffic would you need to justify this? Web app developers have
an unhealthy obsession with performance and scalability that distracts them
from building what really matters: features. Twitter proved you can be just as
successful if you work on features now and scalability later.

~~~
warfangle
"Twitter proved you can be just as successful if you work on a feature now and
scalability later"

fixed that for you ;)

------
synnik
I find it ironic that he mocks "the losers who don’t know how to code and
instead just pontificate endlessly about the hippest new blog post that
totally changed their way of thinking"

Isn't that exactly who is writing to? Doesn't he WANT people to pontificate
about his post and change our thinking?

So why is he mocking his intended audience?

------
Ionic_Walrus
the blog misses a central point - its not the choice of language thats a
bottleneck. I'll trade performance to large number of users any day because I
know I can solve the performance issue.

Personally I'd go with perl - as thats the language Im most comfortable with.

------
DannoHung
If you're going to the trouble of compiling something, why the fuck are you
serving web pages?

~~~
prodigal_erik
If I only pay for the server hardware, I don't care how inefficient the client
is unless it's completely unusable.

------
absconditus
Investigating the many frameworks and libraries available for Java would
probably be a better course of action.

<http://projects.apache.org/indexes/language.html#Java>

------
Kalimotxo
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.

~~~
alexgartrell
False. You only have to write ONE application, you have to buy N servers. It
doesn't take very large N to overcome the price of a good programmer. Hardware
is expensive when you have to buy _lots_ of it.

------
ynniv
Why can't we downmod articles?

------
trickjarrett
On the upside, it means web developers have another way to slack off: "But we
can't work, the project is compiling!" As if web devs needed another way to
burn our time.

------
jonursenbach
Sounds like this guy was fucked over by a contractor.

------
pyman
This site is becoming the next Reddit! Full of stupid comments. Stop wasting
your time people, go and read a book or build something.

------
cosmo7
I agree that compiled statically typed code is more robust than scripts, but
I'd choose a safer language like C# or Java over C.

------
waratuman
Na, why should the be compiled! Come on, do some ASIC for some real
performance!

------
zandorg
Viaweb used C on the backend.

~~~
pg
Not really. The shopping basket (this was before everyone settled on "cart")
was written in C, but the shopping basket wasn't the back end of the rest of
the system, just one of several components that ran in parallel.

~~~
zandorg
I stand corrected. I just remember reading about Viaweb using C on your
website. But I was right in that the cart used it.

------
eli
The thing is, most webapps are just database frontends.

------
ckinnan
Has this guy never heard of op-code cache? You can easily avoid a lot of
script compiling on a production web server.

------
utx00
this was either written by someone with no experience in C, or a C uber
expert.

------
Flemlord
Why write your own framework when you can use Silverlight?

------
Rob15283
Wow, who peed in his oatmeal?

------
kingkongrevenge
I don't see how it's possible to make a good framework in C. It lacks the
necessary abstractions. It lacks even basic vital things like namespaces. Why
on earth would someone attempt this in C rather than C++?

You could come pretty close to simply rewriting a scripting framework in C++.
I don't know what you can get done in C. It will be so dependent on programmer
conventions it will be hideous.

People actually have made some damn good C++ frameworks. See asio. What are
the C ones? Any complex C system devolves into a mess of macros, casts, and
naming conventions.

~~~
huherto
Actually what I would most miss in C is really basic stuff like dynamic
strings, dynamic arrays and hashes.

------
sarvesh
Isn't that's what CGI is for? If you want a full blown web application
framework in C is going to be a lot of work. String manipulation, parsing HTML
with standard C libraries is not going to be easy. Java, C# and Python have
pretty decent frameworks to do this I don't see the point of writing one using
C.

~~~
gdee
Why does the server side (whatever might live there) have to parse HTML?

------
c00p3r
Google already trying to run native x86 code in browser, so, they probably
will be compiled soon. =)

------
loincloth
Dick. USE IT. OR DON'T. NEXXXXTTTTT.

------
jonursenbach
WE'LL DO IT LIVE. FUCK IT. I'LL WRITE IT. FUCKING RUBY SUCKS

