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.
> 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."
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.
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.
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...
Router configuration pages are usually awful. With string handling being an awful pain in C, it might explain why my router only does validation in javascript (thankfully, it means I can disable it when it is wrong).
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.
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.
If you have not already and can do so, I highly recommend adding Dtrace to your C development toolkit. Dtrace, Valgrind, and GDB make rooting out C runtime issues a lot more pleasant and complement one another well.
Indeed. It's a pity DTrace is not available in Linux (there are two ports, none work for real work). It's also a pity DTrace in OS X is starting to bit rot.
A clean room reimplementation of Dtrace is on my list of ideal computing wants that will probably never happen.
Also on the list is everyone targeting the same hypervisor for device drivers (such as Xen) so that hardware support is excellent for all operating systems and all devices.
I would really, really like a clean room reimplementation of Hexray's IDA pro so that I can use it on OS and architecture, an LLVM front end for Plan 9/Inferno OS, a clean room reimplementation of ZFS, GNUstep to have at least a 1:1 implementation of Cocoa so that no matter the OS and architecture one can target that GUI kit and we have inter-application reuse of functionality through scripts like we have for CLI apps, and a clean room reimplementation of AutoCAD and Candence's Orcad.
And as someone who uses a CAS or equivalent environment a lot, I would really appreciate if an ecosytem such as julia, ipython, or octave would reach and exceed Mathematica and Matlab in ease of use, degree of combination and semantics possibilities, and power as well as efficacy.
I really would like to be able to use Plan 9/Inferno OS all the time but developer tools are not comparable to any BSD or Linux ecosystem and there is not a good GUI toolkit available (I would like GNUstep here is why I want the implementation to succeed).
People who can reverse engineer software and hardware is a very small population compared to the res of the dev population though and they are very likely to end up in a lawsuit if they try.
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.
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.
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.)
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.
We actually used c in ~2000 in our web company (one of the biggest in our country at that time). Even the finnish EU commission site ran on C platform that I wrote. Oh the days..
I've no idea what the architecture is like, but being Ada, I'm pretty hopeful it delivers some nice guarantees (or at least hefty promises) regarding reliability.
An outdated, probably flawed (aren't they all) benchmark:
http://wiki.ada-dk.org/aws_vs_node.js
If nothing else it seems to indicate that aws isn't hopelessly slow.
There's also awa - the Ada web framework. I've yet to play with it, but it would appear to be relevant:
http://code.google.com/p/ada-awa/
According to a stack overflow answer[s], Ada also comes with a spitbol-package, allowing you to use spitbol/snobol rather than regexpes for pattern matching. See eg the bottom of:
Seems like the rules for C web development are the same as for any other language: don't trust user input, and delegate the sanitization to vetted library functions. It's not like it's 1991 and you have to use plain arrays and strcmp; there are really good, safe libraries for these things.
That said, doing web development in a language with neither a REPL nor built-in unicode support sounds like a Bad Time.
Still an order of magnitude easier not to shoot yourself in the foot in most higher level language.
Pretty sure you still have to use plain arrays and strcmp, what are these "safe" libraries you were going to use? Unless we are talking about C++ here?
Also C supports unicode fine (to the extent it supports strings) and REPL can't hardly be considered a requirement for web development considering Java, .NET and PHP* don't have REPL's.
Pretty sure you still have to use plain arrays and strcmp, what are these "safe" libraries you were going to use? Unless we are talking about C++ here?
There are others. Basically, if you wrap your dangerous C app in a thin, impenetrable layer of solid string processing and input validation, it's very manageable.
Valgrind and input fuzzing help considerably to work out any bugs.
> Still an order of magnitude easier not to shoot yourself in the foot in most higher level language.
There are some best practices that tend to help you to limit the risk a lot. Still... a lot of people do web development in JavaScript, and I'd cite it as a very strong exception to your assertion.
> Pretty sure you still have to use plain arrays and strcmp, what are these "safe" libraries you were going to use?
Pretty much all of the "NULL terminated" functions have a length terminated equivalent that you can (and should) use instead. There are also blob & string abstractions available that wrap arrays and strings in structs that have fields to track the size of the allocated space, with the side benefit of making C's evil type coercion a bit harder to bump into.
> Also C supports unicode fine
Particularly if you use ICU4C, C actually has the best unicode support out there (obviously there is ICU4J which gets merged into Java regularly, but often you get stuck with an old VM with an ancient version). It's actually kind of shocking how painful it is to have full unicode support with higher level languages that really ought to know better.
> and REPL can't hardly be considered a requirement for web development considering Java, .NET and PHP* don't have REPL's.
> Pretty sure you still have to use plain arrays and strcmp, what are these "safe" libraries you were going to use?
So, thought it would be worth giving some examples. By far the lowest level solution are things like strlcpy & strlcat, which basically still live in a NULL terminated world by try not to be stupid about it:
There's more sophisticated runtimes like glib or APR, which almost seem like they are trying to completely replace the C runtime, but they provide very clean memory management interfaces and string & blob/block abstractions that allow you to avoid having to worry about a buffer overflow.
Then there are solutions built on top of the likes of that. Things like the GGSK: http://gsk.sourceforge.net/
There's lots more, but it's late and I'm tired. ;-)
> Still an order of magnitude easier not to shoot yourself in the foot in most higher level language.
I would argue that C's lack of robust string concatenation encourages most people to avoid concatenating strings at all costs. Most DB libraries support bound parameters, which would be much easier to use than constructing an arbitrary sql string in C. So, I would argue the tendency for a competent C programmer is to do the safe thing rather than the lazy thing other languages make easy that exposes you to SQL injections.
Along with that, most scripting languages are written in C. I know a lot of people who have written PHP extensions in C. This article seems to suggest that no one does any web development in C, when almost every large company I know of does so, even if it is just to speed up slow parts of their app by adding new functions to PHP.
The author explicitly says it's not intended for production in the README:
> This code has every security flaw you imagine, tons of memory leaks, and when I wrote it I may have been awake for much longer than one should be when writing C.
On the other hand, if your development turnaround time is measured in seconds (due to fast compiles from a good toolchain) it really doesn't matter what you're programming in. C with a good set of libraries backing it up is probably just fine.
I'm not sure it's that cut and dry. For one thing, PHP itself has vulnerabilities, as do its flagship apps. These vulnerabilities are easy to scan for, because the default configuration advertises that it is there and what version it is. If you're worried about some kid running scripts or idly scanning, you're probably in better shape with a custom C program than with a widely-used PHP program, even though the custom C program is likely to be more fragile and crumple more easily under actual expert attention.
I use C every day, and I wrote a whole framework for writing websites in C (no longer maintained because I'm no longer that interested in writing websites):
What was amazing was that you could write pretty complex dynamic websites that fit into a few K of RAM and could trivially handle huge load.
I originally wrote that framework for a chat service. It ran for years on a single 32-bit CPU box with 128 MB of RAM, handling the chat requirements of dozens of English schools.
Unexpectedly popular comment :-) A bit more background:
- It used a scheme for cooperative threading that is similar to coroutines. This meant you could write straightforward code and all the event driven stuff was done automatically behind the scenes.
- Parallelism wasn't so important back in 2001 but you could also do that by forking N reactors (one for each core).
- There was a C string library modelled on Perl. It had lots of string management, vectors and hashes. Buffer overflows were effectively made impossible by the string handling library.
- UTF-8 was used throughout and it was fully i18n-able (using getttext).
- Template library.
- There was a pool-based memory allocator library (similar to Apache's APR / Samba's talloc). Effectively you didn't have to worry about memory allocation at all except in some rare corner cases, mainly when you wanted to store something in a global cache.
- All persistence done through PostgreSQL using a Perl DBI-like library. SQL injection was impossible because it used prepared statements.
- There was a rather experimental system built on top of this that allowed you to embed widgets in webpages so you could write very interactive stuff without using Javascript (something of a concern back in 2001, not so much now). It maintained the widget state transparently across page reloads. AFAIK no one has every done anything like this before or since.
It was, to some extent, a bit crazy that I wrote all of the above in about 6 months, but I was being paid a lot of money, working at a very disfunctional company that was on the verge of going out of business, and didn't have much else to do.
Using that same logic we shouldn't use C for anything, because we might make a mistake.
I wouldn't use this not because of possible mistakes leaking in, but because the higher-level languages have already solved some of the problems you would have to solve yourself, such as handling unicode. There are C frameworks you could use but my point is that you would come across problems that have already been solved, and you would have to solve them again, but this time for libCello.
Now that's for production and work. To mess around on my own time? Sounds like fun to me. C is my favorite language but I use it everyday programming mobile devices so I'm probably a little unusual. Maybe a little website experiment or something. If it goes down or gets owned, rebuild time.
I disagree completely. But again, I use it daily. The performance and footprint benefits of C outweigh the negatives, which are basically summed up as - it's too much power.
> If you aren't smart enough [to safely code a website in C...] the first clue that you aren't is that you think that you are
Gee, isn't that epistemology at its finest. Personally I've never met anyone who programmed in C because they were too dumb to learn anything else, but who knows. You may however be aware that, before an HTTP packet even makes it to your shiny, scripty web page, it's often processed by a succession of "segfault-y" and "arbitrary-code-running" software such as Apache and Linux.
I've never met anyone who programmed in C because they were too dumb to learn anything else
I have.
They were too dumb to understand that they were writing unsafe C code because they weren't skilled enough to write safe C code. So it never occurred to them that they had a problem that would be solved by writing part of their system in Python or Ruby or Java.
it's often processed by a succession of "segfault-y" and "arbitrary-code-running" software such w Apache and Linux
The vast majority of C programmers are much less skilled than Apache and Linux developers.
>They were too dumb to understand that they were writing unsafe C code
"Too dumb to catch vulnerabilities in their code" is a much wider category than "too dumb to learn anything else [besides C]". You're not really providing an example of the second.
>The vast majority of C programmers are much less skilled than Apache and Linux developers
So we agree that at least some C developers can write consistently safe code. So a person is not necessarily "not smart" just because of this language choice.
> it's often processed by a succession of "segfault-y" and "arbitrary-code-running" software such as Apache and Linux.
If your web code has ~20 years of security audits and fixes it's probably perfectly safe to use it. If you're adding large new features under tight deadlines I don't recommend it.
Yeah, nobody would let anything important rely on an application written in C. Like apache or nginx. Or postgresql. Or your whole operating system. That would be crazy.
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]
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.
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.
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.
> VMs and interpreters are the essence of dependence.
I find that an odd perspective. If you can rewrite your VM/interpreter from scratch, are you really dependent on it?
I guess I see it less as "use some black-box language runtime to solve this problem" and more as "I will use plain C to solve this problem... by writing an interpreter in plain C for a good DSL to solve this problem in, and then writing the solution in that DSL. But, you know, someone else already did the first part. I'd do it myself if they hadn't, though."
> 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.
Except modern processor architectures are no longer a one-to-one correspondence between Assembly code and C.
There has never been a one-to-one mapping (rather one-to-many), but it's still perfectly possible to transform C into assembly by hand. It's not even that difficult.
Yes, back in the old 8 and 16 bit days, it was pretty much one-to-one for most use cases.
Nowadays not any longer if you want to write code that takes advantage of branch prediction, speculative execution, cache lines, vector units, GPGPU ...
Just watch this Going Native talk on how sometimes generating code that is 4x bigger than the direct translation can yield up to 30% performance increase.
Auto vectorization can be impressive, but it applies to hard numerical code, not so much in regular code bases. I regularly debug assembly in my job, and in the vast majority of cases it's a fairly straightforward translation of the C/C++ code. Stuff like cache locality or using the GPU is still determined by the C code.
I'll concede there's more fine variations to think about than with an 8-bit system, though, with the padding, etc.
Maybe your problem is CPU-bound. Maybe there are good C libraries that solve your problem. Maybe you just want to learn C better. Maybe you have latency limits you need to work within. Maybe you just want to be contrary. Sometimes "why not" is worth more than "why."
Pretty much any decent language has a way to call out to C. I wrote a portion of a book on Tcl's C API, for instance, and it's very easy to farm out computationally intensive work to C code, as it is in Python, Ruby and most other things, one way or the other.
> Maybe your problem is CPU-bound. Maybe you have latency limits you need to work within.
Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell.
> Maybe there are good C libraries that solve your problem
Maybe, but most of the original post is about how lacking the library ecosystem is. I can well believe that you might have some useful domain-specific libraries for the backend, but that calls for writing a backend service in C (and using something like thrift to call it), not "web programming in C".
> Maybe you just want to learn C better.
If you try and learn on a fake problem you'll pervert your learning. Web development is not amenable to idiomatic C (Cello is a good example - it's not appropriate to the sort of problems C is appropriate for, and if you learn C based on using Cello it will not make you a good C programmer).
> lots and lots of time to spend micro-optimizing everything
If you're an experienced C developer you know what's fast and what not (and you know about things like cache coherency). You don't spend that much time on 'micro optimization' because you know how to layout your memory in the first place, etc.
>Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell.
This is just not true. Haskell is terribly (3x,4x) slow comparing to C for the most trivial of computing tasks. You can probably get it to 2x or 1.5x by giving up all the lists and other default data structures as well as writing everything in procedural (by monads) way.
If you do all this you can get close to C performance but you just gave up all the advantages of writing in Haskell in the first place. And you are still slow as hell.
You are just saying the equally wrong thing on the opposing side. You can get to 2x without giving up anything. Lists are just a data structure. So are vectors. You don't give anything up to choose one or the other, you pick the right one and use it. You do not write "everything in procedural (by monads) way" to gain performance. Do notation is literally syntactic sugar, and there is no "perform faster" monad to do it in. Haskell code gets to 2x C speeds the same way C gets to 1x C speeds: profile your code and fix the inefficiencies.
> Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell.
This is stating the case too strongly. Performance wise, the naive, unoptimized solution in Haskell (ex. using the default String type instead of Data.ByteString, number crunching using lots of iteration\recursion) is going to be much slower than than the naive, unoptimized solution in C or Lua. However, for a given subset of the range between "zero" and "micro" levels of optimization, for a given problem, Haskell may still represent the local maximum.
Spending the same amount of development time as the naive, unoptimized solution in C or Lua would take will get you something more performant than the naive, unoptimized solution in Haskell.
1) Whatever language you are most proficient in, that is often the most efficient tool for _you_ to get the job done right.
2) PHP is largely C for people who should never program in C (or PHP ;-). Depending on the nature of what you are doing, and if you use some basic support libraries (and the author mentions a few), your code needn't be that much more work to get done than any other language. In reality, it's not the typing in the code that tends to matter anyway.
3) If you are, for whatever reason, interfacing with a lot of systems components or C API's, there can often be a pretty big win using C as you avoid all the pain of language impedance mismatch.
4) Depending on what it is measured against and the nature of the problem, C can often be significantly more efficient, not just in terms of CPU, but the all important memory consumption these days. Depending on the problem, that can be highly highly relevant.
5) Portability. Okay, you can stop laughing now. ;-) Seriously though, if you talk to mobile game developers who've tried it, C and C++ tend to be the best languages for targeting a plethora of platforms. That goes double or triple for embedded systems. It's really not that hard these days to have very portable C/C++ code, and platforms that insist on making C a second class citizen tend to do themselves more harm than good (even Android ultimately relented).
Now, that's not to say that I think everyone should be doing their web projects in C, but depending on the context (the problem, the available tools, and the parties involved), it might well be a good choice.
I've done it. The use case was settings web pages on an small wifi audio device. Using a few hundred lines of code more was in all respects preferable to trying to fit some other language runtime into a 6 MB budget.
And I don't know why it would need to be so horrible to program web in C, once you have abstracted out common web tasks, using them is as simple as using them in any language, just call a function.
For a CRUD app, of course it doesn't make much sense and you'd probably have to be a masochist. :) But there are valid use cases I can think of: Anything that's very CPU intensive that would need to run very quickly: dynamic image generation, or something that does a complex series of operations on user input that needs to delivers the results ASAP.
Of course it's usually easier and safer to just throw more CPU at it, but at a certain scale that might get too expensive...
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.
> 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.
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.)
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.
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).
I don't see it as a talent filter proxy. More of a "Does this company understand what it is getting into and therefore what it needs" proxy.
e.g. You run a skyscraper building company. If you see job ads for competitors with things like "must have excellent woodworking knowledge" you are probably less worried than those with "must have excellent metallurgy knowledge".
That's fine. I was characterizing how pg was using it.
> Does this company understand what it is getting into and therefore what it needs?
I think it is actually a much poorer proxy for that. Maybe if they are a small company or don't have any engineers, that would make sense. As a company gets larger, job descriptions start to represent very small, specific parts of what a company does, and the internal context of the company often outweighs the importance of the external context that is visible to you.
As an example, when Facebook was still up and coming and had real competition, Facebook were the ones hiring C programmers, not their competitors... ;-)
Ah I considered the second bit in the historical context.
The poly-lingual software related company seems to be a more modern trend IMO. At the time PG is referring to I would have been very surprised to see that going on in the web industry.
> The poly-lingual software related company seems to be a more modern trend IMO. At the time PG is referring to I would have been very surprised to see that going on in the web industry.
Consider yourself surprised then. ;-)
Actually back in those days a lot of the web industry was just doing integration with existing systems, which means the tech stacks were as varied as those existing systems. Even when not, it was the wild west. You tended to have a lot of experimentation, false starts, and general insanity. Heck Apple had a really good run with a server-side Objective-C development framework! Impressive systems were built fairly easily with Perl (and later PHP), Smalltalk, C++, VBScript, Python, LISP, and then there was AOLServer stuff (TCL!), and that's ignoring some of the proprietary language developed specifically for the web... At any given company you'd probably find somewhere between 2 to 5 of those. Sure there might be a dominant language, but there'd be specific needs for people with skills in any of those languages.
There was one sign you could rely on to know a company was not on top of their tech stack: the gratuitous licensing of proprietary Java application servers. Open source, and in some cases even proprietary, servlet engines made a lot of sense for some places, and Java application servers could often make sense for enterprise solutions that needed to be dragged kicking and screaming into the web world, but all too often you'd see these companies paying tens of thousands in licensing fees for technical capabilities that not only were not of use for them, but _would actively hamper their efforts_.
I actually was a Java consultant at Sun during some of that era, and I often would arrive at client sites and feel an overwhelming need to smash my head against the wall until I forgot what I'd seen.
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++.
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.
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).
Given the choice C++ is way better than C, given that it allows to use higher level abstractions and replace all unsafe C heritage by library based safe constructs.
Of course, the best option would be to replace them by other languages with native compilers.
However at the level these languages are used, it will only happen when OS vendors push new languages for their OS.
So it will never happen in UNIX land or Mac OS X land.
In Windows land, Microsoft is pushing for C++ and C++/CX, maybe C# if they ever decide to offer a full native compiler, like the Bartok one.
The embedded market OS vendors are all about Ada, C and C++. A few do offer Basic, Pascal and Oberon, but are very small niche.
So there isn't any OS vendor left that would push new system programming languages for their OS.
For business programming, there are already plenty languages to chose from.
> Given the choice C++ is way better than C, given that it allows to use higher level abstractions and replace all unsafe C heritage by library based safe constructs.
You may have noticed that C++ is not always deemed universally better than C. What language are all the top web servers implemented in?
C has library based safe constructs as well, and C++ still has all of C unsafety. You just get to exercise those bugs at a higher level of abstraction.
> Of course, the best option would be to replace them by other languages with native compilers.
I think that is anything but clear. Certainly the option of doing so has been around. You just don't see a ton of big moves that worked out well.
> However at the level these languages are used, it will only happen when OS vendors push new languages for their OS.
Most OS's actually have a pretty small API footprint (Windows being the obvious outlier). If it were really just about the language bindings, it would not be a real impediment. A language runtime can abstract out the OS (as the C runtime does).
> So there isn't any OS vendor left that would push new system programming languages for their OS.
I'm going to claim this could well be a function of Darwinian forces.
> You may have noticed that C++ is not always deemed universally better than C. What language are all the top web servers implemented in?
Apache and nginx => C
Tomcat, Jetty => Java
IIS => C++/C#
> Most OS's actually have a pretty small API footprint (Windows being the obvious outlier). If it were really just about the language bindings, it would not be a real impediment. A language runtime can abstract out the OS (as the C runtime does).
If developers aren't forced to use it, then they won't use it, even if made available.
> I'm going to claim this could well be a function of Darwinian forces.
That is my hope, after all we only need a few generations of developers and then the issue is taken care of by itself.
Okay, if you are going to throw in Tomcat & Jetty, you should also throw in the likes of lighttpd, mongrel2, etc., all of which are written in C. Pretty much all the load balancers/reverse proxies are written in C too. Hmm.... is it maybe possible that it isn't always better to use C++ instead of C?
> IIS => C++/C#
Yup, the one outlier no doubt owes about 0% of its success to its tech stack. In general, if you don't work at Google and want a C++ web server on anything other than Windows, you are looking at a C++ server framework that has an embedded HTTP stack (tntnet, Wt, etc.).
> If developers aren't forced to use it, then they won't use it, even if made available.
I know. I spend all my time watching them because if I don't they just start doing everything in assembly.
> That is my hope, after all we only need a few generations of developers and then the issue is taken care of by itself.
> > Apache and nginx => C > Tomcat, Jetty => Java
> Okay, if you are going to throw in Tomcat & Jetty, you should also throw in the likes of lighttpd, mongrel2, etc., all of which are written in C. Pretty much all the load balancers/reverse proxies are written in C too. Hmm.... is it maybe possible that it isn't always better to use C++ instead of C?
No, they were developed by open source Linux guys that only care about C in what concerns compiled languages.
C++ was always badly received by the Linux community, in contrast with commercial UNIXes.
> IIS => C++/C#
> Yup, the one outlier no doubt owes about 0% of its success to its tech stack. In general, if you don't work at Google and want a C++ web server on anything other than Windows, you are looking at a C++ server framework that has an embedded HTTP stack (tntnet, Wt, etc.).
Yes, nothing like contributing to have more insecure servers around.
>> That is my hope, after all we only need a few generations of developers and then the issue is taken care of by itself.
> I think you missed my point. ;-)
I surely got your point, but it is not about Darwin of languages, rather of developers.
> No, they were developed by open source Linux guys that only care about C in what concerns compiled languages.
> C++ was always badly received by the Linux community, in contrast with commercial UNIXes.
You mean like KDE, Firefox, OpenOffice, OpenCV, VLC, bitcoin... heck even gparted is a C++ app.
The kernel developers obviously have a bias against C++ (and they'd argue that it is a justified bias). User space is a different land.
> Yes, nothing like contributing to have more insecure servers around.
? Not sure your point here...
> I surely got your point, but it is not about Darwin of languages, rather of developers.
> I surely got your point, but it is not about Darwin of languages, rather of developers.
My point was about Darwinian forces applied to language or developers.
I was responding to your point about OS vendors not being left around. It would appear that, for whatever reason, going with something other than C or C++ for your base OS doesn't seem to result in good survival odds.
>> No, they were developed by open source Linux guys that only care about C in what concerns compiled languages. > C++ was always badly received by the Linux community, in contrast with commercial UNIXes.
>You mean like KDE, Firefox, OpenOffice, OpenCV, VLC, bitcoin... heck even gparted is a C++ app.
>The kernel developers obviously have a bias against C++ (and they'd argue that it is a justified bias). User space is a different land.
I use Linux since 1995, and was for some time a Gtkmm contributor in the early days.
I know how it feels to be a C++ developer in Linux land.
> I use Linux since 1995, and was for some time a Gtkmm contributor in the early days.
> I know how it feels to be a C++ developer in Linux land.
The GNOME crowd was self selected to be a bunch of "C not C++" bigots. The KDE community was quite different (even if MOQ is an abomination ;-). The only community I can think of that would be more hostile to C++ is the kernel devs.
I don't think your experiences are accurately reflective of the larger community. Particularly as C++ has improved (really, pre-gcc 3.0 there wasn't a good C++ compiler, and pre-2000 hardly anybody understood RAII, so C++ was kind of a pain), the larger community's attitude has changed. You can see this reflected in the success of the Boost project.
Coming from Turbo Pascal background I tend to be very critic of unsafe by design nature of C and C++. Specially given my focus in compiler design during the university, which allowed me to have a broad focus and experience in many languages, the average HN crowd might not be aware of.
Having said this, I was already coding in C++ in MS-DOS around 1993 (Turbo C++) and only used plain C when forced to do so.
So I have been part of the C++ community since the early PC compilers were available, and experienced this C vs C++ for quite some years now.
The funny part is remember the performance complaints back then about C and C++, that nowadays people state in HN about languages trying to replace them.
> C has library based safe constructs as well, and C++ still has all of C unsafety.
The problem C's lacking one of most important primitives - data structures.
Bugs in standard library happen pretty rarely, I guess. So, C++ users have most common data structures for free.
And when I open some C-based project's code the first thing I usually expect and see is some homegrown linked list and/or map implementations (of SIGSEGV fame). I know, there are tons of libraries that offer them, but in my experience of "hey, that server crashed, could you figure out what went wrong"-type tasks, they're very rarely used.
> And when I open some C-based project's code the first thing I usually expect and see is some homegrown linked list and/or map implementations (of SIGSEGV fame). I know, there are tons of libraries that offer them, but in my experience of "hey, that server crashed, could you figure out what went wrong"-type tasks, they're very rarely used.
Fortunately, C++ developers just always use the STL because it is considered the bastion of all that is good in collection classes:
Don't get me wrong. I love C++ and use the STL by default, but it's all too rare that I look at a decent sized C++ project and see anything different from what you'd expect if the project were written in C.
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
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.
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.
> 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.
I think that is absolutely on the money?... but what if you are building one of those components?... or what if you are writing a very thin wrapper on one of those components, and it is brand new and only has C bindings?... or what if you need to be portable to dozens of different platforms, many of which don't share much toolchain overlap except for gcc?
> but I guarantee I'll probably leave a buffer overflow exploit open when trying to parse GET variables.
It's pretty easy to avoid that if you are worried about it. There are buffer/blob abstractions that give you "safe" interfaces with 0 risk of buffer overflow. Really, there is no good reason to have those unless you really are trading safety for performance.
> Or I can just do it in Java, and get all the performance and almost all the advantages of doing it in C.
Sometimes you can, sometimes you can't. It depends on the problem... and your levels of skill with both Java & C.
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.
> 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.
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.
sumatra is for parallelizing mainly on GPU, not for SIMD - current C/C++ compilers neither do that. Java has SIMD support for quite a long while now, probably since Java 6 or even earlier and generally C-like Java code using raw arrays and primitives is as-fast-as-C these days. I'd be more afraid of lack of true value types in Java. This one thing makes C still a better choice for high performance stuff.
Modern JVMs do support SIMD vectorisation now and I've seen at least one example where JVM outperformed GCC 4.5 in loop vectorisation by 2x. There is no reason JIT compilers cannot do all the same SIMD optimisations that static compilers do.
If you want really top performance for non-trivial cases, e.g. matrix multiplication, I guess you need to probably vectorise by hand and go down right to assembly level.
> 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.
Exactly. String parsing is the biggest shortcoming in C that always gives me a second thought when I'm about to choose a language for a higher level application (especially if it incorporates user input as strings). Even such trivial thing as AT command parser is a pain in C. Of course, there are parser generators as Bison, but still it's tedious amount of work and usually not worth it.
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.
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.
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;
}
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.
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.
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.
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...
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.
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.
212 comments
[ 4.5 ms ] story [ 246 ms ] threadDeveloping a whole CRUD app in C however? Seems like it would feel like digging a swimming pool with a spoon.
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."
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...
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.
Also on the list is everyone targeting the same hypervisor for device drivers (such as Xen) so that hardware support is excellent for all operating systems and all devices.
I would really, really like a clean room reimplementation of Hexray's IDA pro so that I can use it on OS and architecture, an LLVM front end for Plan 9/Inferno OS, a clean room reimplementation of ZFS, GNUstep to have at least a 1:1 implementation of Cocoa so that no matter the OS and architecture one can target that GUI kit and we have inter-application reuse of functionality through scripts like we have for CLI apps, and a clean room reimplementation of AutoCAD and Candence's Orcad.
And as someone who uses a CAS or equivalent environment a lot, I would really appreciate if an ecosytem such as julia, ipython, or octave would reach and exceed Mathematica and Matlab in ease of use, degree of combination and semantics possibilities, and power as well as efficacy.
I really would like to be able to use Plan 9/Inferno OS all the time but developer tools are not comparable to any BSD or Linux ecosystem and there is not a good GUI toolkit available (I would like GNUstep here is why I want the implementation to succeed).
People who can reverse engineer software and hardware is a very small population compared to the res of the dev population though and they are very likely to end up in a lawsuit if they try.
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.
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.
(Disclaimer: Don't get my tone wrong please, I'm asking not suggesting, thus I respect your experience.)
http://www.adacore.com/adaanswers/gems/gem-29/
http://libre.adacore.com/tools/aws/
I've no idea what the architecture is like, but being Ada, I'm pretty hopeful it delivers some nice guarantees (or at least hefty promises) regarding reliability.
An hello-world example web server:
An outdated, probably flawed (aren't they all) benchmark: If nothing else it seems to indicate that aws isn't hopelessly slow.There's also awa - the Ada web framework. I've yet to play with it, but it would appear to be relevant:
According to a stack overflow answer[s], Ada also comes with a spitbol-package, allowing you to use spitbol/snobol rather than regexpes for pattern matching. See eg the bottom of: [s] http://stackoverflow.com/questions/5904053/web-programming-i...That said, doing web development in a language with neither a REPL nor built-in unicode support sounds like a Bad Time.
Pretty sure you still have to use plain arrays and strcmp, what are these "safe" libraries you were going to use? Unless we are talking about C++ here?
Also C supports unicode fine (to the extent it supports strings) and REPL can't hardly be considered a requirement for web development considering Java, .NET and PHP* don't have REPL's.
*Looks like PHP has some now.
glib: https://en.wikipedia.org/wiki/GLib
There are others. Basically, if you wrap your dangerous C app in a thin, impenetrable layer of solid string processing and input validation, it's very manageable.
Valgrind and input fuzzing help considerably to work out any bugs.
There are some best practices that tend to help you to limit the risk a lot. Still... a lot of people do web development in JavaScript, and I'd cite it as a very strong exception to your assertion.
> Pretty sure you still have to use plain arrays and strcmp, what are these "safe" libraries you were going to use?
Pretty much all of the "NULL terminated" functions have a length terminated equivalent that you can (and should) use instead. There are also blob & string abstractions available that wrap arrays and strings in structs that have fields to track the size of the allocated space, with the side benefit of making C's evil type coercion a bit harder to bump into.
> Also C supports unicode fine
Particularly if you use ICU4C, C actually has the best unicode support out there (obviously there is ICU4J which gets merged into Java regularly, but often you get stuck with an old VM with an ancient version). It's actually kind of shocking how painful it is to have full unicode support with higher level languages that really ought to know better.
> and REPL can't hardly be considered a requirement for web development considering Java, .NET and PHP* don't have REPL's.
> *Looks like PHP has some now
Not only does PHP have one, but Java has since forever (http://www.beanshell.org/), and .NET really kind of does have a few semi-reasonable options (http://www.linqpad.net/, http://www.sliver.com/dotnet/SnippetCompiler/, http://www.mono-project.com/CsharpRepl, not to mention: http://technet.microsoft.com/en-us/library/bb978526.aspx).
Of course, so does C (http://root.cern.ch/drupal/content/cint, http://root.cern.ch/drupal/content/cling, http://www.softintegration.com/products/chstandard/, and arguably even things like https://code.google.com/p/picoc/ or http://ups.sourceforge.net/main.html can serve if you are desperate).
So, thought it would be worth giving some examples. By far the lowest level solution are things like strlcpy & strlcat, which basically still live in a NULL terminated world by try not to be stupid about it:
http://www.gratisoft.us/todd/papers/strlcpy.html
There are some specifically targeting strings and making them both more efficient and safer:
http://bstring.sourceforge.net/
There's more sophisticated runtimes like glib or APR, which almost seem like they are trying to completely replace the C runtime, but they provide very clean memory management interfaces and string & blob/block abstractions that allow you to avoid having to worry about a buffer overflow.
Then there are solutions built on top of the likes of that. Things like the GGSK: http://gsk.sourceforge.net/
There's lots more, but it's late and I'm tired. ;-)
Also you should compile your app with apparmor and run it under grsecurity.
REPL like behaviour you can get with gdb. :)
I would argue that C's lack of robust string concatenation encourages most people to avoid concatenating strings at all costs. Most DB libraries support bound parameters, which would be much easier to use than constructing an arbitrary sql string in C. So, I would argue the tendency for a competent C programmer is to do the safe thing rather than the lazy thing other languages make easy that exposes you to SQL injections.
Along with that, most scripting languages are written in C. I know a lot of people who have written PHP extensions in C. This article seems to suggest that no one does any web development in C, when almost every large company I know of does so, even if it is just to speed up slow parts of their app by adding new functions to PHP.
https://github.com/tyler/Bogart/blob/master/bogart.c#L53
I'm sure nothing could possibly go wrong there...
> This code has every security flaw you imagine, tons of memory leaks, and when I wrote it I may have been awake for much longer than one should be when writing C.
http://web.archive.org/web/*/http://www.annexia.org/freeware...
What was amazing was that you could write pretty complex dynamic websites that fit into a few K of RAM and could trivially handle huge load.
I originally wrote that framework for a chat service. It ran for years on a single 32-bit CPU box with 128 MB of RAM, handling the chat requirements of dozens of English schools.
- It used a scheme for cooperative threading that is similar to coroutines. This meant you could write straightforward code and all the event driven stuff was done automatically behind the scenes.
- Parallelism wasn't so important back in 2001 but you could also do that by forking N reactors (one for each core).
- There was a C string library modelled on Perl. It had lots of string management, vectors and hashes. Buffer overflows were effectively made impossible by the string handling library.
- UTF-8 was used throughout and it was fully i18n-able (using getttext).
- Template library.
- There was a pool-based memory allocator library (similar to Apache's APR / Samba's talloc). Effectively you didn't have to worry about memory allocation at all except in some rare corner cases, mainly when you wanted to store something in a global cache.
- All persistence done through PostgreSQL using a Perl DBI-like library. SQL injection was impossible because it used prepared statements.
- There was a rather experimental system built on top of this that allowed you to embed widgets in webpages so you could write very interactive stuff without using Javascript (something of a concern back in 2001, not so much now). It maintained the widget state transparently across page reloads. AFAIK no one has every done anything like this before or since.
It was, to some extent, a bit crazy that I wrote all of the above in about 6 months, but I was being paid a lot of money, working at a very disfunctional company that was on the verge of going out of business, and didn't have much else to do.
That's one of the best things I've read in a last few days.
I wouldn't use this not because of possible mistakes leaking in, but because the higher-level languages have already solved some of the problems you would have to solve yourself, such as handling unicode. There are C frameworks you could use but my point is that you would come across problems that have already been solved, and you would have to solve them again, but this time for libCello.
Now that's for production and work. To mess around on my own time? Sounds like fun to me. C is my favorite language but I use it everyday programming mobile devices so I'm probably a little unusual. Maybe a little website experiment or something. If it goes down or gets owned, rebuild time.
It's too little safety.
Gee, isn't that epistemology at its finest. Personally I've never met anyone who programmed in C because they were too dumb to learn anything else, but who knows. You may however be aware that, before an HTTP packet even makes it to your shiny, scripty web page, it's often processed by a succession of "segfault-y" and "arbitrary-code-running" software such as Apache and Linux.
I have.
They were too dumb to understand that they were writing unsafe C code because they weren't skilled enough to write safe C code. So it never occurred to them that they had a problem that would be solved by writing part of their system in Python or Ruby or Java.
it's often processed by a succession of "segfault-y" and "arbitrary-code-running" software such w Apache and Linux
The vast majority of C programmers are much less skilled than Apache and Linux developers.
"Too dumb to catch vulnerabilities in their code" is a much wider category than "too dumb to learn anything else [besides C]". You're not really providing an example of the second.
>The vast majority of C programmers are much less skilled than Apache and Linux developers
So we agree that at least some C developers can write consistently safe code. So a person is not necessarily "not smart" just because of this language choice.
If your web code has ~20 years of security audits and fixes it's probably perfectly safe to use it. If you're adding large new features under tight deadlines I don't recommend it.
I've said it before, but it bares repeating:
PHP is C for people who shouldn't write in C... or PHP.
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/
[2] http://www.techempower.com/benchmarks/
[3] http://www.treefrogframework.org/documents/tutorial
[1] https://github.com/TechEmpower/FrameworkBenchmarks/pull/283
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
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.
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.
I find that an odd perspective. If you can rewrite your VM/interpreter from scratch, are you really dependent on it?
I guess I see it less as "use some black-box language runtime to solve this problem" and more as "I will use plain C to solve this problem... by writing an interpreter in plain C for a good DSL to solve this problem in, and then writing the solution in that DSL. But, you know, someone else already did the first part. I'd do it myself if they hadn't, though."
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...
Except modern processor architectures are no longer a one-to-one correspondence between Assembly code and C.
Nowadays not any longer if you want to write code that takes advantage of branch prediction, speculative execution, cache lines, vector units, GPGPU ...
Just watch this Going Native talk on how sometimes generating code that is 4x bigger than the direct translation can yield up to 30% performance increase.
http://channel9.msdn.com/Events/GoingNative/2013/Compiler-Co...
I'll concede there's more fine variations to think about than with an 8-bit system, though, with the padding, etc.
Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell.
> Maybe there are good C libraries that solve your problem
Maybe, but most of the original post is about how lacking the library ecosystem is. I can well believe that you might have some useful domain-specific libraries for the backend, but that calls for writing a backend service in C (and using something like thrift to call it), not "web programming in C".
> Maybe you just want to learn C better.
If you try and learn on a fake problem you'll pervert your learning. Web development is not amenable to idiomatic C (Cello is a good example - it's not appropriate to the sort of problems C is appropriate for, and if you learn C based on using Cello it will not make you a good C programmer).
If you're an experienced C developer you know what's fast and what not (and you know about things like cache coherency). You don't spend that much time on 'micro optimization' because you know how to layout your memory in the first place, etc.
This is just not true. Haskell is terribly (3x,4x) slow comparing to C for the most trivial of computing tasks. You can probably get it to 2x or 1.5x by giving up all the lists and other default data structures as well as writing everything in procedural (by monads) way. If you do all this you can get close to C performance but you just gave up all the advantages of writing in Haskell in the first place. And you are still slow as hell.
This is stating the case too strongly. Performance wise, the naive, unoptimized solution in Haskell (ex. using the default String type instead of Data.ByteString, number crunching using lots of iteration\recursion) is going to be much slower than than the naive, unoptimized solution in C or Lua. However, for a given subset of the range between "zero" and "micro" levels of optimization, for a given problem, Haskell may still represent the local maximum.
1) Whatever language you are most proficient in, that is often the most efficient tool for _you_ to get the job done right.
2) PHP is largely C for people who should never program in C (or PHP ;-). Depending on the nature of what you are doing, and if you use some basic support libraries (and the author mentions a few), your code needn't be that much more work to get done than any other language. In reality, it's not the typing in the code that tends to matter anyway.
3) If you are, for whatever reason, interfacing with a lot of systems components or C API's, there can often be a pretty big win using C as you avoid all the pain of language impedance mismatch.
4) Depending on what it is measured against and the nature of the problem, C can often be significantly more efficient, not just in terms of CPU, but the all important memory consumption these days. Depending on the problem, that can be highly highly relevant.
5) Portability. Okay, you can stop laughing now. ;-) Seriously though, if you talk to mobile game developers who've tried it, C and C++ tend to be the best languages for targeting a plethora of platforms. That goes double or triple for embedded systems. It's really not that hard these days to have very portable C/C++ code, and platforms that insist on making C a second class citizen tend to do themselves more harm than good (even Android ultimately relented).
Now, that's not to say that I think everyone should be doing their web projects in C, but depending on the context (the problem, the available tools, and the parties involved), it might well be a good choice.
Sometimes it is hard to beat just doing it in C.
And I don't know why it would need to be so horrible to program web in C, once you have abstracted out common web tasks, using them is as simple as using them in any language, just call a function.
Of course it's usually easier and safer to just throw more CPU at it, but at a certain scale that might get too expensive...
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.
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.
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.)
http://www.paulgraham.com/avg.html
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).
e.g. You run a skyscraper building company. If you see job ads for competitors with things like "must have excellent woodworking knowledge" you are probably less worried than those with "must have excellent metallurgy knowledge".
That's fine. I was characterizing how pg was using it.
> Does this company understand what it is getting into and therefore what it needs?
I think it is actually a much poorer proxy for that. Maybe if they are a small company or don't have any engineers, that would make sense. As a company gets larger, job descriptions start to represent very small, specific parts of what a company does, and the internal context of the company often outweighs the importance of the external context that is visible to you.
As an example, when Facebook was still up and coming and had real competition, Facebook were the ones hiring C programmers, not their competitors... ;-)
The poly-lingual software related company seems to be a more modern trend IMO. At the time PG is referring to I would have been very surprised to see that going on in the web industry.
Consider yourself surprised then. ;-)
Actually back in those days a lot of the web industry was just doing integration with existing systems, which means the tech stacks were as varied as those existing systems. Even when not, it was the wild west. You tended to have a lot of experimentation, false starts, and general insanity. Heck Apple had a really good run with a server-side Objective-C development framework! Impressive systems were built fairly easily with Perl (and later PHP), Smalltalk, C++, VBScript, Python, LISP, and then there was AOLServer stuff (TCL!), and that's ignoring some of the proprietary language developed specifically for the web... At any given company you'd probably find somewhere between 2 to 5 of those. Sure there might be a dominant language, but there'd be specific needs for people with skills in any of those languages.
There was one sign you could rely on to know a company was not on top of their tech stack: the gratuitous licensing of proprietary Java application servers. Open source, and in some cases even proprietary, servlet engines made a lot of sense for some places, and Java application servers could often make sense for enterprise solutions that needed to be dragged kicking and screaming into the web world, but all too often you'd see these companies paying tens of thousands in licensing fees for technical capabilities that not only were not of use for them, but _would actively hamper their efforts_.
I actually was a Java consultant at Sun during some of that era, and I often would arrive at client sites and feel an overwhelming need to smash my head against the wall until I forgot what I'd seen.
Back in the day (particularly before they started doing ads), almost everything was C++.
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.
Of course, the best option would be to replace them by other languages with native compilers.
However at the level these languages are used, it will only happen when OS vendors push new languages for their OS.
So it will never happen in UNIX land or Mac OS X land.
In Windows land, Microsoft is pushing for C++ and C++/CX, maybe C# if they ever decide to offer a full native compiler, like the Bartok one.
The embedded market OS vendors are all about Ada, C and C++. A few do offer Basic, Pascal and Oberon, but are very small niche.
So there isn't any OS vendor left that would push new system programming languages for their OS.
For business programming, there are already plenty languages to chose from.
You may have noticed that C++ is not always deemed universally better than C. What language are all the top web servers implemented in?
C has library based safe constructs as well, and C++ still has all of C unsafety. You just get to exercise those bugs at a higher level of abstraction.
> Of course, the best option would be to replace them by other languages with native compilers.
I think that is anything but clear. Certainly the option of doing so has been around. You just don't see a ton of big moves that worked out well.
> However at the level these languages are used, it will only happen when OS vendors push new languages for their OS.
Most OS's actually have a pretty small API footprint (Windows being the obvious outlier). If it were really just about the language bindings, it would not be a real impediment. A language runtime can abstract out the OS (as the C runtime does).
> So there isn't any OS vendor left that would push new system programming languages for their OS.
I'm going to claim this could well be a function of Darwinian forces.
Apache and nginx => C
Tomcat, Jetty => Java
IIS => C++/C#
> Most OS's actually have a pretty small API footprint (Windows being the obvious outlier). If it were really just about the language bindings, it would not be a real impediment. A language runtime can abstract out the OS (as the C runtime does).
If developers aren't forced to use it, then they won't use it, even if made available.
> I'm going to claim this could well be a function of Darwinian forces.
That is my hope, after all we only need a few generations of developers and then the issue is taken care of by itself.
Okay, if you are going to throw in Tomcat & Jetty, you should also throw in the likes of lighttpd, mongrel2, etc., all of which are written in C. Pretty much all the load balancers/reverse proxies are written in C too. Hmm.... is it maybe possible that it isn't always better to use C++ instead of C?
> IIS => C++/C#
Yup, the one outlier no doubt owes about 0% of its success to its tech stack. In general, if you don't work at Google and want a C++ web server on anything other than Windows, you are looking at a C++ server framework that has an embedded HTTP stack (tntnet, Wt, etc.).
> If developers aren't forced to use it, then they won't use it, even if made available.
I know. I spend all my time watching them because if I don't they just start doing everything in assembly.
> That is my hope, after all we only need a few generations of developers and then the issue is taken care of by itself.
I think you missed my point. ;-)
No, they were developed by open source Linux guys that only care about C in what concerns compiled languages.
C++ was always badly received by the Linux community, in contrast with commercial UNIXes.
> IIS => C++/C# > Yup, the one outlier no doubt owes about 0% of its success to its tech stack. In general, if you don't work at Google and want a C++ web server on anything other than Windows, you are looking at a C++ server framework that has an embedded HTTP stack (tntnet, Wt, etc.).
Yes, nothing like contributing to have more insecure servers around.
>> That is my hope, after all we only need a few generations of developers and then the issue is taken care of by itself.
> I think you missed my point. ;-)
I surely got your point, but it is not about Darwin of languages, rather of developers.
You mean like KDE, Firefox, OpenOffice, OpenCV, VLC, bitcoin... heck even gparted is a C++ app.
The kernel developers obviously have a bias against C++ (and they'd argue that it is a justified bias). User space is a different land.
> Yes, nothing like contributing to have more insecure servers around.
? Not sure your point here...
> I surely got your point, but it is not about Darwin of languages, rather of developers.
> I surely got your point, but it is not about Darwin of languages, rather of developers.
My point was about Darwinian forces applied to language or developers.
I was responding to your point about OS vendors not being left around. It would appear that, for whatever reason, going with something other than C or C++ for your base OS doesn't seem to result in good survival odds.
>You mean like KDE, Firefox, OpenOffice, OpenCV, VLC, bitcoin... heck even gparted is a C++ app.
>The kernel developers obviously have a bias against C++ (and they'd argue that it is a justified bias). User space is a different land.
I use Linux since 1995, and was for some time a Gtkmm contributor in the early days.
I know how it feels to be a C++ developer in Linux land.
The GNOME crowd was self selected to be a bunch of "C not C++" bigots. The KDE community was quite different (even if MOQ is an abomination ;-). The only community I can think of that would be more hostile to C++ is the kernel devs.
I don't think your experiences are accurately reflective of the larger community. Particularly as C++ has improved (really, pre-gcc 3.0 there wasn't a good C++ compiler, and pre-2000 hardly anybody understood RAII, so C++ was kind of a pain), the larger community's attitude has changed. You can see this reflected in the success of the Boost project.
Having said this, I was already coding in C++ in MS-DOS around 1993 (Turbo C++) and only used plain C when forced to do so.
So I have been part of the C++ community since the early PC compilers were available, and experienced this C vs C++ for quite some years now.
The funny part is remember the performance complaints back then about C and C++, that nowadays people state in HN about languages trying to replace them.
Oh, and I really like Boost.
The problem C's lacking one of most important primitives - data structures.
Bugs in standard library happen pretty rarely, I guess. So, C++ users have most common data structures for free.
And when I open some C-based project's code the first thing I usually expect and see is some homegrown linked list and/or map implementations (of SIGSEGV fame). I know, there are tons of libraries that offer them, but in my experience of "hey, that server crashed, could you figure out what went wrong"-type tasks, they're very rarely used.
Fortunately, C++ developers just always use the STL because it is considered the bastion of all that is good in collection classes:
http://www.codeofhonor.com/blog/avoiding-game-crashes-relate... http://engineering.adap.tv/2012/03/29/why-we-use-c-without-u...
Don't get me wrong. I love C++ and use the STL by default, but it's all too rare that I look at a decent sized C++ project and see anything different from what you'd expect if the project were written in C.
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.
I think that is absolutely on the money?... but what if you are building one of those components?... or what if you are writing a very thin wrapper on one of those components, and it is brand new and only has C bindings?... or what if you need to be portable to dozens of different platforms, many of which don't share much toolchain overlap except for gcc?
> but I guarantee I'll probably leave a buffer overflow exploit open when trying to parse GET variables.
It's pretty easy to avoid that if you are worried about it. There are buffer/blob abstractions that give you "safe" interfaces with 0 risk of buffer overflow. Really, there is no good reason to have those unless you really are trading safety for performance.
> Or I can just do it in Java, and get all the performance and almost all the advantages of doing it in C.
Sometimes you can, sometimes you can't. It depends on the problem... and your levels of skill with both Java & C.
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.
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/.
.NET? While Microsoft does not offer anything, Mono has SIMD support since 2008, http://tirania.org/blog/archive/2008/Nov-03.html
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.
The IBM J9 VM already has them.
http://duimovich.blogspot.ca/2012/11/packed-objects-in-java....
http://www.slideshare.net/mmitran/ibm-java-packed-objects-mm...
If you want really top performance for non-trivial cases, e.g. matrix multiplication, I guess you need to probably vectorise by hand and go down right to assembly level.
Exactly. String parsing is the biggest shortcoming in C that always gives me a second thought when I'm about to choose a language for a higher level application (especially if it incorporates user input as strings). Even such trivial thing as AT command parser is a pain in C. Of course, there are parser generators as Bison, but still it's tedious amount of work and usually not worth it.
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.
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.
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.
Source code: https://bitbucket.org/fusiongyro/exchange_rates/src
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.
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:
It's an interesting exercise, but as soon as I left they scrapped it for something maintainable.