
Web development in C: Crazy? - dysoco
https://medium.com/code-adventures/ff723209f8f5
======
jerf
So, people can't hardly write safe web apps in PHP without spraying XSS and
auth bypasses and arbitrary shell executions and arbitrary SQL injections
everywhere, and you _also_ want to hand the attackers the ability to segfault
your server or possibly even straight-up run arbitrary code?

Anyone smart enough to truly safely code a website in C is smart enough to
learn a language to create that website which doesn't get on all fours and
_beg_ to be owned.

Yes, I mean that 100% seriously. If you're smart enough to safely write that C
code, you won't. If you aren't smart enough to write that C code safely... and
the first clue that you aren't is that you think that you are... you don't
stand a chance. It's suicidal.

~~~
srl
I once wrote a website (a search engine for a specific set of websites) in C.
It actually worked, once I spend 20 hours in valgrind. I've grown since then,
in two important ways. First, I'd probably do a better job now, and not have
to spend any time in valgrind at all (I still use C quite frequently). Second,
I'd never, ever, try to pull that stunt again.

~~~
pjmlp
> It actually worked, once I spend 20 hours in valgrind

Thia is exactly the main problem with C.

You need to rely on tolling outside the language to be able to write safer
code.

While languages like Ada and Modula-2 and their descendents, offer the same
hardware capabilities as C with stronger type checking.

~~~
harrytuttle
We use C# which allows you to write safe code. However, people still manage to
fuck it up at an implementation level often enough for it to cause high risk
problems.

~~~
pjmlp
I do mostly JVM and .NET based development nowadays, in consulting projects.

Sometimes I wish to be part of a C or C++ based project, then I try to imagine
how the quality of our offshore guys would map to those languages and realize
how lucky I am not to be part of such projects.

~~~
X4
Don't you do something wrong, when you consult the company to use (more)
offshore guys? I thought that a company is best led, when developers share
their knowledge cooperatively and ask their managers to outsource unimportant
time-consuming things like api-/file-/conversions, legacy code support, CSVs …

(Disclaimer: Don't get my tone wrong please, I'm asking not suggesting, thus I
respect your experience.)

~~~
pjmlp
Most consulting projects in Fortune 500 companies end up with outsourcing the
whole project department to the consulting company, in the cases where IT is
not the main business.

~~~
X4
Oh, I didn't know that it's so extreme.. thanks for reporting back, I
appreciate it :)

------
wwweston
At my first web job circa 1996, our shopping cart product was mostly C, so I
did web development in C for about two years.

I'm not sure that using C was the craziest thing about how we did things.
Nobody really had an idea how to structure a web app, so it was more or less a
dozen or so CGIs which read/wrote to flat files through custom-written dbm
clone (woo, NoSQL in '96!). Lots of unsophisticated string munging.

Maybe if we'd had some better abstractions, it wouldn't have been as painful,
but C code written to do a lot of ad hoc string cobbling is, in fact, a little
crazy.

Despite this, the product pretty much worked and actually had a few hundred
customers and a future.

(We even got looked at by Yahoo, but they bought some outfit named Viaweb
instead.)

~~~
ced
_During the years we worked on Viaweb I read a lot of job descriptions. A new
competitor seemed to emerge out of the woodwork every month or so. The first
thing I would do, after checking to see if they had a live online demo, was
look at their job listings. After a couple years of this I could tell which
companies to worry about and which not to. The more of an IT flavor the job
descriptions had, the less dangerous the company was. The safest kind were the
ones that wanted Oracle experience. You never had to worry about those. You
were also safe if they said they wanted C++ or Java developers. If they wanted
Perl or Python programmers, that would be a bit frightening-- that 's starting
to sound like a company where the technical side, at least, is run by real
hackers. If I had ever seen a job posting looking for Lisp hackers, I would
have been really worried._

[http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

~~~
cbsmith
That's using language choice as a proxy for developer talent. It's a proxy,
not a real metric of the language itself.

I'd note that pg ultimately sold to Yahoo, who a) wrote a fair bit of C in
house themselves and b) were severely trounced by a competitor that initially
was primarily using C++ (Google).

~~~
marssaxman
Google still does primarily use C++.

~~~
cbsmith
Google is so huge now, I'm not sure if that is really something that you can
state unequivocally. The search engine and a lot of the plumbing that
everything is built on top of is written primarily in C++, but there is a TON
of both Java and Python code there (and that's not counting things like Go and
specialized languages like the infamous Sawzall).

Back in the day (particularly before they started doing ads), almost
everything was C++.

~~~
acchow
Only tools, one-offs, and small internal products at Google can use Python. In
general, for production it is disallowed (with exception of YouTube). They
learned with YouTube that Python doesn't scale well to hundreds or thousands
of developers. Even Mondrian, the code review system started by Guido and
written in python, was replaced by something more scalable.

~~~
cbsmith
> Only tools, one-offs, and small internal products at Google can use Python.

Also YouTube (you may have heard of it).

> with exception of YouTube

Oh, you have. ;-)

You didn't mention java though... there's a TON of stuff in Java at Google.

~~~
acchow
Yeah, I'd say Java and C++ are about equally prevalent at Google. A lot of the
older products and core infra is still C++, and a ton of new stuff is Java
(See: Android).

------
PhasmaFelis
WHYYYYYYYYY

No, seriously, _why_? As far as I can tell, his entire argument is "web
development in C is terrible and limiting, but not as quite as terrible and
limiting as you might think." I guess that's good news if terrorists are
forcing you to write websites in C, but I don't see even an attempt at
explaining why you would _choose_ to do this.

~~~
DigitalJack
There exists a form of survivalist mindset in some programmers. It goes
roughly like this: if you can't boot it, it's fluff programming.

The attraction of C to this mindset is that it can be transliterated (vs
translated) into machine code. This transliteration is so straight forward
that if you know C and are familiar with the basics of the instruction set you
can do it by hand.

The survivalist mindset fears dependence. VMs and interpreters are the essence
of dependence. So those with this mindset always seek find a way to do it in
plain C when they can.

~~~
readme
On the next episode of "Doomsday Coders"

Programmer writes an entire operating system from scratch in case all the
copies of Linux in the world are deleted.

A web developer writes his entire application in x86 assembly to prepare for
an event in which all the world's compilers and interpreters disappear.

And more...

~~~
reinhardt
Replace "disappear" with "cannot be trusted to not be owned by NSA" and
someone might actually take a stab..

------
moron4hire
I've done a number of projects that were web-oriented in C and C++ over the
years, and they are by no means my primary language. It wasn't that bad,
especially if you take the time to learn how to do string manipulation
properly (which isn't really _that_ hard).

Come to think of it, even though we consider C to be "low level", that's
really only a temporary problem that solves itself the longer you work with it
and the more you build with it. It's a site different issue than the opposite
issue of Ruby and PHP, which will never be able to have quite the raw
performance of C.

It's a bit like the difference between fast-food and gourmet. Yes, fast-food
American burgers is _probably_ easier than fast-food... French ratatouille.
When you're employees are barely passed childhood and not particularly trained
in the arts, you'll bet your business on the burger (RE: the similar bubbles
in the gastro-pub market vis technologicalist startup). But a practitioner at
the top their game will do wonderful things with either.

~~~
derleth
> It wasn't that bad, especially if you take the time to learn how to do
> string manipulation properly (which isn't really that hard).

It's hard in the way that counts: It's tedious and prone to precisely the
kinds of errors humans make when a task is tedious. Worse, string manipulation
is _precisely_ where all of the potentially dangerous bugs can live in the
average C program, especially if you're accepting data from untrusted sources.

> Come to think of it, even though we consider C to be "low level", that's
> really only a temporary problem that solves itself the longer you work with
> it and the more you build with it.

Aside from the fact you can say the same about assembly, this is another
reason to disfavor C: Reinventing the wheel. Over and over again.

I say all this as someone who actually likes C, and even somewhat enjoys doing
string processing in C. I even know about strstr(3), which _never_ seems to
get mentioned. The main thing I know, however, is that it isn't worth it
unless you live in a contrived circumstance.

Yes, you can go really fast by strapping yourself to that rocket, and if you
remove the helmet you'll reduce your weight and go even faster. Nobody's
doubting you. However, very few people want to stand downrange of you.

------
noonespecial
I wrote a little backend section in C once to do a FFT on some data and it
ended up being 7 times faster or so than the perl the rest of the backed was
written in. It made sense there.

Developing a whole CRUD app in C however? Seems like it would feel like
digging a swimming pool with a spoon.

~~~
auvrw
> I wrote a little backend section in C once to do a FFT on some data

yeah, this kind of thing is what i thought the article's title meant and was
going to say "no, actually quite common," but then read the article. and given
the choice between "crazy" and "crazy like a fox," i'd say "crazy like a fox,
but still crazy."

------
chrismorgan
A language like Python or Ruby gets you ease of coding and a moderate level of
safety; a language like C gets you speed but at a high safety risk.

Haskell could get you often similar speed benefits, and there are even a
couple of rather interesting frameworks for it (with even things like compile-
time template checking), but the barrier for entry is unfortunately high.

Thus a language like Rust really comes into its own: speed kin to C with
safety significantly exceeding that of Python and Ruby. Users of Python and
Ruby may find the parts of its type system which must be specified explicitly
arduous, but it does make it _ever_ so much more likely that code that you
write just works, correctly, which (as primarily a Python developer) I have
found marvellous.

Rust isn't there yet for web development, but solid support for the HTTP layer
is well in progress: [https://github.com/chris-morgan/rust-
http](https://github.com/chris-morgan/rust-http). When that's far enough
along, then I'll get on to the framework I have in mind.

~~~
jamesjporter
I think Julia has the potential to be a contender in this space as well. The
advantage over Rust or Go is that you get a dynamic language (with a REPL and
everything), and still can have C-like performance. You also get
metaprogramming and optional typing (so its there if you want safety but you
can ignore it if you just need to crank something out). To me it really feels
like a blend of the best of Python/Ruby and statically typed languages.

~~~
chrismorgan
The impression that I at least have got of Julia is that it's designed
specifically for technical computing (mathematics, science, etc.) rather than
general purpose programming as Rust is. I think that would be likely to
influence what people use it for significantly? That could be a pity, because
Julia does look like quite an interesting language.

Rust's REPL, rusti, is presently broken, but it will be being fixed up later.

I presume Rust's safety will also go beyond Julia's, with its algebraic data
types and lack of such things as null, and its rigidly checked type system.

~~~
KenoFischer
Disclaimer: I'm a Julia core developer

Julia's type system is very similar to Rust's. Julia has composite types, type
unions and parametric dependent types. It is certainly designed with technical
computing in mind, but that does not at all limit its ability to do general
purpose programming and in fact can help significantly in high load
situations. I personally have done more general purpose programming in Julia
than I have done technical computing (and in fact, it's focus on technical
computing was one of the least important reasons when I decided to become one
of the Julia core developers). You have a good point that the ability to do
easy technical computing certainly will influence the initial audience, but, I
think, as the language matures, this will shift towards a more general
audience.

------
nemothekid
There are hardly any benefits in writing your web app in C ove r Java or Go.
That 1% speed increase is nothing compared to the huge amount network wait
these apps will be doing.

If you really consider it, what 95% of people write these days is glue between
various services, and the parts that do matter, where you need the most
performance, are already written in C. The reason why Redis, MongoDB and
Postgres have good C bindings, because they themselves are written in C.

So when it comes down to it all you are really doing is string parsing and
string transporting, thats really the last thing you want to leave to C. I
haven't done straight-C code that has required me to do a lot of string
manipulation, but I guarantee I'll probably leave a buffer overflow exploit
open when trying to parse GET variables.

Or I can just do it in Java, and get all the performance and almost all the
advantages of doing it in C.

~~~
moconnor
C and C++ compilers can produce faster execution than Go or JVMs as they
support SIMD vectorization e.g. SSE/AVX. For CPU-bound workloads you can get
more than 2x speed up.

It doesn't mean you should write your entire server stack in C vs calling a C
function for heavy computation, but the idea that Java and Go approach 99% the
speed of C/C++/Fortran is generally only true for programs that are not
optimized for performance.

~~~
pjmlp
> C and C++ compilers can produce faster execution than Go or JVMs as they
> support SIMD vectorization e.g. SSE/AVX. For CPU-bound workloads you can get
> more than 2x speed up.

This is an implementation issue.

Nothing prevents a compiler vendor to offer the same capabilities to their
language compilers.

Vectorization is not part of ANSI/ISO C or ANSI/ISO C++.

For the time being, do you want vectorization in Go? Write a tiny assembler
routine. Done.

JVM? They are working on making it part of the reference JVM
[http://openjdk.java.net/projects/sumatra/](http://openjdk.java.net/projects/sumatra/).

.NET? While Microsoft does not offer anything, Mono has SIMD support since
2008,
[http://tirania.org/blog/archive/2008/Nov-03.html](http://tirania.org/blog/archive/2008/Nov-03.html)

~~~
moconnor
It's an implementation issue that matters if you're writing a system that
needs to offer high performance today.

Regarding writing assembly - that's fine, you could also write a routine in C
and call it. The thrust of my comment is that it is untrue to argue that
native Go and Java match the performance of C/C++. They don't. They might in
the future.

~~~
pkolaczk
In the majority of cases they do. For a few minor cases where they don't (but
they are close to) you can drop to C or assembly.

------
fusiongyro
I wrote a small (~300 line) C program to scrape an email and insert the part I
wanted into a Postgres database. I used PCRE for the extraction and ECPG for
the Postgres part. ECPG stands for embedded SQL in C for Postgres, and it
looks like this:

    
    
        // Open the storage subsystem.
        void open_storage()
        {
          EXEC SQL BEGIN DECLARE SECTION;
          const char* database = DATABASE_NAME;
          const char* username = USERNAME;
          const char* schema = SCHEMA;
          EXEC SQL END DECLARE SECTION;
    
          EXEC SQL WHENEVER SQLERROR CALL quit();
          EXEC SQL CONNECT TO :database USER :username;
          EXEC SQL SET search_path to :schema;
        }
    

ECPG:
[http://www.postgresql.org/docs/current/interactive/ecpg.html](http://www.postgresql.org/docs/current/interactive/ecpg.html)

My takeaway was that it was a lot easier than I expected, but it was still
kind of a minefield. ECPG isn't widely used or highly intelligent, so there
are a lot of stumbling blocks despite the pretty high quality documentation. I
would recommend hiding your ECPG behind some functions so you only have to run
some of your files through the pre-processor. But it is a neat tool and I
could see myself using it again.

~~~
X4
This made me curious! Why did you do this? To create a database of
"signatures" to be used in your contact-list?

~~~
fusiongyro
No, I signed up for the xe.com daily currency exchange rates email and it
occurred to me I could build a database around it. So now I have daily
exchange rate data going back a couple years. Thankfully they haven't changed
their format. They have a service you can pay for if you want to download this
data in bulk but I was being cheap and didn't really have any particular use
for the data.

Source code:
[https://bitbucket.org/fusiongyro/exchange_rates/src](https://bitbucket.org/fusiongyro/exchange_rates/src)

~~~
X4
Thank you! I am curious about the trade-market too

~~~
fusiongyro
If you find a bug, please let me know. My C is probably pretty poor. Thanks!
:)

------
jaredsohn
I've always found it interesting that OkCupid is built with C++, although they
started it before 2001.
[http://www.okcupid.com/about/technology](http://www.okcupid.com/about/technology)

~~~
jacques_chester
OKWS is interesting to study because it's one of the few Staged, Event-Driven
Architecture (SEDA) websites in well-known production use. Max Krohn's 2004
paper describing the design of OKWS is excellent reading[1].

With the rise of VMs, jails, containers etc it should be much easier for
general webapps to adopt this architecture.

[1]
[http://pdos.csail.mit.edu/~max/docs/okws.pdf](http://pdos.csail.mit.edu/~max/docs/okws.pdf)

------
danjayh
Why C? Performance. I wrote a C webserver on a PIC32MX795F512L (80 mhz/ 128kB
RAM), and it was _screaming_ fast (for what it was running on). Easily handled
~100 clients making 2-3 requests/sec continuously to a JSON based API (I
really don't know how far you could push it before it got slow), which is
respectable for that chip ... but this was written to the bare metal with no
OS (did use libraries for IP/TCP/HTTP/JSON, though). C isn't my first choice
for web development either, but there's absolutely no way you could pull that
off in a higher-level language.

~~~
pjmlp
Modula-2, Turbo Pascal, Ada...?

~~~
pestaa
... Haskell...?

~~~
pjmlp
I was just listing some languages that were designed as system programming
languages as well.

But any language with native code compilers, that is able to have small
footprint executables would do.

------
rjzzleep
You think? Cpoll[1] is actually on top of the techempower web framework
benchmark [2]

onion to be honest looks more like a http server generation framework. similar
to what rob fitzpatrick was talking about when he was advocating gos net/http.
but then again what do i know i haven't tried any of them.

Personally, even though ruby makes my salary I like C. Always did. Treefrog
looks the most like a modern web framework to me. [3]

[1]
[http://sourceforge.net/projects/cpollcppsp/](http://sourceforge.net/projects/cpollcppsp/)

[2]
[http://www.techempower.com/benchmarks/](http://www.techempower.com/benchmarks/)

[3]
[http://www.treefrogframework.org/documents/tutorial](http://www.treefrogframework.org/documents/tutorial)

~~~
bhauer
Treefrog is coming in Round 7 [1]. (And sorry, we still don't have an ETA for
Round 7 but we are hoping for this month.)

[1]
[https://github.com/TechEmpower/FrameworkBenchmarks/pull/283](https://github.com/TechEmpower/FrameworkBenchmarks/pull/283)

------
damian2000
Might anyone looking for a speedup akin to C do better to look at Go instead?

~~~
programminggeek
I would second this. Go has enough batteries included that you can write nice
little web things with the same basic development experience you get in python
or ruby or php. It's really quite wonderful.

------
simias
I'm mainly a C dev and I would never ever use C to write a web app. Not
because I don't think it could be done, not because I don't think it could be
done well but simply because string manipulations in C are a pity. Containers
which are not dumb arrays in C are a pity. SQL bindings are much more tedious
than the higher-level languages counterparts (I wrote quite a bunch of C
interfacing with SQLite, it works well but requires a lot of LoC compared to
perl for instance).

Basically 90% of what you do in a typical web framework in your scripting
language of choice becomes 10 times more tedious and error-prone in C (and
probably 100 times faster but frankly, who cares?)

It's already painful when I need to write sysfs and debugfs interfaces (and
the linux kernel has a pretty nice API to write in those).

The only reason I can imagine for using C in a web app is performances but
then:

1/ I would try to profile my app and see where the bottleneck is. If it's
really CPU-bound and C would really help I'd try to write a small C library
for this particular piece of code and bind it in my scripting language.

2/ If I really must write the whole thing in C for some reason I'd try to push
for a subset of C++ with at least std::string, std::map, constructors and
destructor to ease ressource management and maybe exceptions for error
handling. Done well you'll get similar performances and with a bit of luck you
might actually come up with something remotely maintainable.

------
Figs
A lot of embedded systems have web configuration interfaces written in C. For
example, your wireless router's configuration page is probably written in C.

~~~
stevelaz
True that. I've written a few Web interfaces for embedded devices in C. That
being said, I now try to use Lua along with C for projects of this type. It
all really depends on memory and performance requirements.

I was once part of a team on a project that we wrote an embedded webserver
that we compiled in all the html, images(converted to c arrays), css and js,
into a single binary so that we wouldn't have to read from flash to load those
resources for speed boost and less flash access.

I've learned now, that given the target hardware and resources, that wasn't
really necessary...

------
alexkus
It all depends on whether you've got a compelling reason to or not.

For us it was a simple decision, we have a mature stable product[1] that's
written in C. So the path of least resistance is to write out own web
framework (from scratch to avoid IP infringement problems). Sure it took time,
a lot more time than grabbing something written by someone else, but that's
not how it works everywhere (especially in corporate environments). Now we've
got this library it makes adding HTTP client/server stuff to any of our C
binaries relatively easy.

Likewise string processing in C isn't a problem once you've got a suitable
library built up; ADT libraries (no I don't need to implement my own buggy
hashtable again and again), regexp wrapper libraries, etc. They also help
maintain consistency across platforms (our product ships on 6 different
platforms including Windows).

If you're looking for instant gratification then C isn't the right language
for you but a huge amount of the Internet is built on the back of things
written in C. Are webservers (Apache, nginx) written in C similarly crazy? No.

Of course, it needs someone to write a solid C HTTP framework and then open
source it so that it can be maintained/improved, now that would be useful.
Sadly our employer has no plans to release ours, which is a shame but I have
no control over that.

1\. Coming up 20 years old now and >$1.5bn in revenues over those years, not
too shabby.

------
akbar501
Reasons not to use C for web dev: 1\. Maintenance costs will go through the
roof with C. C developers are not cheap, and most people who use C have are
not web developers. 2\. Hiring will be exceptionally painful. Again, most C
devs are not web devs. Put another way, most web devs use other languages. 3\.
Some C developers are so good that very few people can understand their code
(Linus talks about this, and I've seen it happen at a prior company)

By way of personal experience, in '99 we had an outstanding developer who was
a rock star in C. When he left, I remember sitting in a meeting when an A+
developer (he really was good) was asked by the VP Eng, "Can you support his
code". The response, "No". VP Eng: "Why is it not commented?". Response, "It's
commented. In fact it's the best code I have ever seen. But I cannot support
it, it's amazing, but its way beyond my skill level."

I have never seen a repeat of this experience in a 4th gen language. I'm sure
it can/may happen, but have not yet.

------
ruben_varnish
Although we try not to talk too much about it, many users of Varnish Cache
actually use it "because it is the easiest way to get a C layer in our web
stack".

Others are proud creators developing web sites in it using both VCL (which is
compiled into C) and C directly through VMODs or Inline-C in VCL. More:

* [https://www.varnish-cache.org/docs/trunk/users-guide/vcl-inl...](https://www.varnish-cache.org/docs/trunk/users-guide/vcl-inline-c.html)

* [https://www.varnish-cache.org/docs/trunk/reference/vmod.html](https://www.varnish-cache.org/docs/trunk/reference/vmod.html)

* [https://www.varnish-cache.org/vmods](https://www.varnish-cache.org/vmods)

* [https://www.varnish-cache.org/trac/wiki/VCL](https://www.varnish-cache.org/trac/wiki/VCL)

------
briannickel
I once inherited a website written in C. I actually tried moving it to PHP but
the server was hitting a rogue MySQL instance with a file socket and I
couldn't find a PHP API to handle it.

There were two things I did that actually made it pretty painless to work
with: I implemented a Dreamweaver template processor that you could hook up to
output a string or execute a block on each template element. I also
implemented a preprocessor that allowed injection of large HTML blocks:

    
    
        for (int i = 0; i < n; i ++) {
            [[[<tr><td>(((i))). {{{strings[i]}}}</td></tr>]]]
        }
    

It's an interesting exercise, but as soon as I left they scrapped it for
something maintainable.

------
spmurrayzzz
Doug Crockford at the TC-39 panel last night talked about how one of the most
exciting things about JavaScript is that its a wildly successful general-
purpose programming language that "doesn't have to look like C to be
successful."

His point was that we used to live in a software ecosystem where the
conventional wisdom was that if a programming language didn't look like C, it
wasn't going to take off. JavaScript (and even more so variants like
CoffeeScript) are showing that we've moved on from that sentiment.

In some ways, this article feels like a retreat to that older assumption. As
if we somehow are expected to be searching for ways to work C into the modern
web app landscape. Perhaps this point may somewhat orthogonal to the topic of
the article and the related discussion, but I can't help but ask what problems
are we solving by going back to C for web development? Is the assumed
performance gain going to outweigh all the other benefits of using a higher
level abstraction?

None of the framework examples listed in the article really seem elegant at
all when compared to higher level counterparts (Rails, Django, Spring, et al).
Of course, I'm saying this without having attempted to build an application
with any of them.

~~~
ahoge
JavaScript is a C-like language though. It looks like C. It borrowed its
syntax and even many of its keywords.

Also, in some of his earlier talks he said that it looks familiar to C or Java
developers (because it's a C-like language) and that this perceived
familiarity is the reason why most people don't bother learning the language.

------
eaxitect
I don't want to start a language war here but as a phd student working on
distributed systems, choice for "C" as a language for developing high
throughput web applications has some rationale. For instance, when you read
most of the articles in HS.com or C10K at least, web development at large-
scale requires every performance bit out of machine. Indeed, some -caugh-
google-caugh- still use C++ at backend (even not in the frontend) or we see
twitter switched to JVM from RoR for performance.

For regular earthlings, RoR, Py, PHP and alike are still more feasible than C
for "getting the job done".

But the article's point of view is a bit shallow in that sense, since it's
looking a way of replacing conventional frameworks (RoR etc.) for C. If you
gonna develop a high-perf application in C, you probably use more wide variety
of specialized libraries for focused tasks(like json processing, I18N,
handling SSL, developing nginx/HAproxy modules,extensions for load balancing,
etc.) rather than using a single "C framework".

------
seryoiupfurds
The Fossil DVCS has a built-in web interface for reviewing commits, along with
a bug tracker and a wiki. It's all written in C, albeit with a couple of
custom macro preprocessors.

I once wrote a toy web page in C; Lex made for nice HTML templating and with
pseudOO it actually felt pretty modern, but I still wasted a whole lot of time
reinventing various wheels.

~~~
e12e
Thanks for the reminder about fossil. I tend to forget that it's all c (and
therefore, must contain a wiki in c). Reviewing in that code base added to
todo...

------
eksith
Well, C++ already has a couple of web frameworks :
[http://cppcms.com/wikipp/en/page/main](http://cppcms.com/wikipp/en/page/main)

[http://www.webtoolkit.eu/wt](http://www.webtoolkit.eu/wt)

I'm not sure that's a good idea though. It's hard to fail safely in a language
that can fail silently. And failure modes include, not just blatant hacks into
the underlying system, but surreptitious insertion that can propagate to all
your visitors.

Besides the fact that it's pretty hard to find a decent C developer these days
who's also interested in web development, you have a climate that's not
exactly conducive to development in it. If it breaks or needs upgrading, will
you do the work yourself? If it's that small, then it's probably not something
you'd worry about too much, but then it's only on your shoulders.

------
electic
Also, OKCupid is written in C++.

~~~
stevekemp
See this link for more details on that :
[http://pdos.csail.mit.edu/~max/docs/okws.pdf](http://pdos.csail.mit.edu/~max/docs/okws.pdf)

------
e12e
If you do want do do it in c, I think php pretty much got it right -- write an
extension in c, and use something else for the rest. Se eg:
[http://phalconphp.com/en/](http://phalconphp.com/en/)

Then there's of course G-Wan -- source of a lot of speculation, and frequent
border-irrational (counter)claims by it's author -- but undoubtedly a good
contender for easy-to use server with c-language "scripting":

[http://gwan.com/](http://gwan.com/)

A newer server in the same space is nxweb, which seems made for doing the kind
of work the article talks about - simple, high performance web-services in c:

[https://bitbucket.org/yarosla/nxweb/wiki/Home](https://bitbucket.org/yarosla/nxweb/wiki/Home)

For other languages, have a look at hello-world webservers at rosetta:

[http://rosettacode.org/wiki/Hello_world/Web_server#C](http://rosettacode.org/wiki/Hello_world/Web_server#C)

Other related projects:

mongoose - small embeddable, cross platform web server w/lua scripting:
[http://cesanta.com/](http://cesanta.com/)

lighttz - webserver in c using libev:
[http://arekzb.wordpress.com/2008/04/27/lighttz-a-simple-
and-...](http://arekzb.wordpress.com/2008/04/27/lighttz-a-simple-and-fast-web-
server/)

Still, if it were me, and I needed "c-speed", I'd probably go with cgi (or
fastcgi). Forking on every request might not be the absolute fastest, but with
the binary cached in ram, it's still pretty fast on Linux. Or maybe just use
mongrel2 and a c handler:

[https://github.com/derdewey/mongrel2_c_handler/tree/master/l...](https://github.com/derdewey/mongrel2_c_handler/tree/master/lib)

------
JeremyMorgan
Why? If you want the speed of compiled code you can come very close with .Net
or JVM based solutions.

------
yk
Writing web services in C can of course be done; I even believe that there are
legitimate designs were it makes sense. Namely, if the back end is anyhow
custom written and all you need is a smallish server to talk to the client. (
For example games, were the server simulates a world.) But the problem I have
with the article is, that in this case frameworks don't help. Web applications
were C makes sense, require a very different coding style from the one the
article deals with. So it makes no sense to fetch just some values from a DB
and give it to a server using C. C only makes sense if one has to do a large
part of the heavy lifting oneself.

------
D9u
This is a nice summary, and the links are handy reference for the subject.

Security concerns aside, I've occasionally used small C routines in web-app
CGI calls, and often wondered if others have gone further with C and web
development.

------
AndyKelley
You can have the best of both worlds by writing low-level modules in C for use
within a higher level framework.

For example, I've been having a great time writing this music player backend
in C[1], but as soon as it's solid I'm going to write a node.js addon module
and then use that as the backend for my web-based audio player[2].

[1]:
[https://github.com/superjoe30/libgroove](https://github.com/superjoe30/libgroove)

[2]:
[https://github.com/superjoe30/groovebasin](https://github.com/superjoe30/groovebasin)

------
fetbaffe
Sure, cool stuff and probably great fun doing it.

However what matters in web development is not performance, nor that it is bug
free and not even security. All of those things can fixed one way or the other
on the server with more hacks.

The one thing that matters is speed of development, that is why PHP rules so
hard.

"Let's argue about whether Haskell or Clojure is better while somebody else
ships products using PHP and duct tape."

[https://twitter.com/agentdero/status/174965036928868352](https://twitter.com/agentdero/status/174965036928868352)

~~~
asdasf
But that comment is such a transparent and absurd red herring that it is an
insult to your intelligence to repeat it. People talk about PHP too. That
doesn't stop them from shipping products using it. Talking about languages has
absolutely no detrimental effects on writing code.

~~~
fetbaffe
Did you understand my point how web development works?

Web development is fundamentally different from application/system
development.

~~~
asdasf
[http://en.wikipedia.org/wiki/Non_sequitur](http://en.wikipedia.org/wiki/Non_sequitur)

------
edsiper2
You missed to mention Duda I/O:

    
    
       http://duda.io
    

On this case this framework target web services, you can do web development
but the goal is to be a fast HTTP/Websocket stack instead of a friendly MVC
renderer.

Even is do in C, i tries to present a friendly C API as you can see in
[http://duda.io/api](http://duda.io/api), if you think into a fast big data
server front-end, Duda I/O fits pretty well. A few slides:

    
    
        http://duda.io/slides/

~~~
X4
hehe, yeah duda and MonkeyHTTPd ftw. ! Been using both and many other
webservers including nxweb for a quite some time now for trial. I do webdev in
C and Julia for the Backend.

------
sbmassey
The main problem, I think, is that web development usually requires lots of
string processing, and the C standard library makes this complicated and
opaque. Maybe Cello helps with that?

------
kybernetyk
No, not crazy. Just really tedious. I've been there and even webdev in C++ was
magnitudes more comfortable than webdev in C.

But webdev is a solved and trivial problem. More so it is an I/O-bound
problem. So you can use the slowest language in the world as long as it boosts
your productivity or makes your life super easy. (Sure, there are edge cases
but 99.9% of webdevs never will be in the situation of having thousands of
requests a second.)

------
ajslater
We wrote Bloglines, the first and greatest RSS reader web app, in C. And by
"we" I mean Mark Fletcher did, and the people he hired like me, continued it.

It wasn't bad. You just get used to keeping track of memory, arrays lengths
and pointers like you do anything else. While I do prefer Python these days, I
always enjoyed the looks of horror Java and PHP programmers greeted me with
when I mentioned our language of choice for Bloglines.

------
stephengillie
If you want to make an Arduino serve websites, you'll have to write embedded-C
commands that write HTML to browsers and can interpret POST commands.

------
fayyazkl
I would like to add that apart from being professionally chosen or not, this
sort of opens up a way for learning web dev concepts for those who learned
programming with c as the first language. They just get to see internals of
all libraries quickly rather than having lots of frameworks with no easy
access to source to see what is going on underneath. Good idea.

------
mistercow
It seems like if you want to get the performance benefits of C with web
development, that's something you can do, but it does seem downright crazy to
try to do it _all_ with C. Use something safe and abstract as glue and for
talking to the client, and use C for any heavy lifting, if the benefit can
justify the extra work.

------
abimaelmartell
i been working with ntop, its a web interface written in C, the HTML is
embedded within the C code. As a rails/php developer this is kind of crazy :P
Heres the source
[https://svn.ntop.org/svn/ntop/trunk/ntop/httpd.c](https://svn.ntop.org/svn/ntop/trunk/ntop/httpd.c)

~~~
stevelaz
Hehe, this looks similar to some stuff I've worked on with embedded devices.

------
gizzlon
_The reasons for this [that no one uses C] aren’t terribly difficult to
discern. Let’s face it: compared with higher-level languages, C is hard. Like,
objectively hard_

So.. instead of leading with one of the many, many great reasons not to use C,
he pretty much calls everyone too stupid to make it work.

------
n1ghtmare_
The worst abomination I've worked with was a web app written in PL/SQL. It was
lovely to maintain.

------
16s
_" And when was the last time you wrote a function that returned 1 or 0? If
you’re a Rubyist or a Pythonista or a server-side JavaScript devotee, you may
never have done so."_

That's just returning True or False (bool). Lot's of people return that from
functions in all languages.

------
fenesiistvan
I am using the atozed intraweb framework for web dev:
[http://www.atozed.com/intraweb/index.en.aspx](http://www.atozed.com/intraweb/index.en.aspx)
Comfortable C++ framework with session management and all the other stuff you
need

------
philhippus
When you get 90x the performance using C rather than PHP, the only thing
stopping its use is human resources. To put it into perspective, you would
need 90 PHP servers to do the same work in the same time as a single C server.
Any more debate?

~~~
debacle
Yes, the cost equation of _X PHP developers + 90 servers_ might be cheaper
than the cost equation for _Y C programmers + 1 server_.

 _Y_ is almost certainly greater than _X_.

~~~
philhippus
While that may be true for the short term, what about the power, maintenance,
storage etc costs that recur? I'm not sure a C dev's pay is equal to the
running costs of a server farm...

------
dalore
In the early days when Perl was the CGI de jure the company I worked for wrote
their cgi in C and ran on Zeus webservers. This was for performance on one of
the most highly traffic'd sites at the time.

------
zx2c4
Cgit is written by C and it's quite easy to develop with a fairly clean code
base:

[http://git.zx2c4.com/cgit/about/](http://git.zx2c4.com/cgit/about/)

------
Qantourisc
Sorry using C is a security nightmare. You need to use a higher language like
C++ that can encapsulate and abstract your web-framework enough.

Or use a C framework that has secure string handling and others.

------
npx
Slightly offtopic, but I love Node.Native[1].

It provides an API similar to Node.js using C++11 lambdas.

1\. [https://github.com/d5/node.native](https://github.com/d5/node.native)

------
sgt
Also worth mentioning, a Websocket server library in C.
[https://github.com/m8rge/cwebsocket](https://github.com/m8rge/cwebsocket)

------
kbart
Sounds like a fun side project. But I would not risk doing such thing for
money - support would be a nightmare. And by the way, wasn't that what Go was
developed for..?

------
JanneVee
He forgot the use case for C web development. Small embedded systems. Not
everything is CRUD.

------
popee
libfcgi (C) + postgres worked like a charm for me. There are also things like
libmicrohttpd, libevent/libev, ... that are also very useful if you want to
play even more. It's not that hard if you know C.

------
vasilipupkin
why use C? if you want to go down that path why not use C++ frameworks, like
[http://www.webtoolkit.eu/wt](http://www.webtoolkit.eu/wt) ?

------
trimbo
Weather Underground is implemented in C.

------
auggierose
Yep. Just bat shit crazy.

------
francis-
Not crazy, just stupid.

------
ezyang
Yes.

------
throwaway420
I don't think the author has offered a great argument in this article.
Building a new website in C sounds like a fun learning experience, but it's
not a practical choice for the typical startup CRUD app.

When you're a startup, your biggest problem 99.999% of the time isn't running
out of memory or not having a fast enough app, but getting an MVP up and
launched and finding enough paying customers so that you don't run out of
money. Except in specialized cases where your app is very CPU intensive, C
provides a major headache without a major immediate advantage.

But C is a great choice for replacing parts of your app if you start growing
and when you start figuring out exactly what services need to be faster and
use less memory.

