6 ms·

Web Applications Should Be Compiled

129 points by csbartus 17y ago

jimbokun 17y ago
Not a bad troll. Not the best I've ever read, but not bad, either.
- nuclear_eclipse 17y ago
  From 2008-09-28: The old blog software, Typo, is nowhere near as good as Wordpress. I only used it because it was written in Ruby on Rails and I am a Ruby on Rails coder. This is a very poor means of choosing software.
- mildweed 17y ago
  At least he's planning on putting his money where his mouth is. If he creates this framework, more power to him!
  - stcredzero 17y ago
    The VisualWorks Smalltalk Server Pages framework already does this. SSP results in web pages as compiled machine language. The HTML file is translated into a new Smalltalk method, the tags become Smalltalk message sends, and the HTML between the dynamic tags just become accesses into an Array. Because Array access is optimized and JITed as machine code, the only message sends are due to the dynamic tags. When the webpage/method is JITed, you have a web page compiled into machine code.
    - mikeryan 17y ago
      I believe the framework discussion is of a compiled C "Rails" type MVC framework, I'm not familiar with Smalltalk Server Pages but from an initial google search it doesn't seem to be on par with what rails provides?
      - stcredzero 17y ago
        You're right that SSP is more like ASP/JSP, and not like Rails. But the same idea can be used with a more comprehensive web framework and with a language that has a really good JIT, like LuaJIT, or maybe IronPython/IronRuby.
    - fauigerzigerk 17y ago
      Sounds pretty much like JSP.
- dryicerx 17y ago
  I don't think it's a troll, but just someone who is really in to performance, like I do, and I agree with him on some points. But what I don't agree is using just C. C is too low level and is a horrific unfit task for web development. Instead C++ would be a good fit (and writing in C mixed in). The STL/Boost provide a wonderful abstraction layer that does pretty much anything you throw at it with ease, plus there are lot of other libraries for anything else you can ever think of. I've written several web applications in C++, and it was actually very much like writing in Python/PHP/Ruby and at time prefered writing it in C++ after writing a poc in a scripting language. They were just a little bit less readable but very clean, but the biggest plus the the multiple magnitude performance increase of the application it self with FastCGI. (all these applications were serious number crunchers and had lot of CPU and Memory Bound problems). tldr; C for web dev painful, C++ with STL/Boost good/easy/fast/clean. Also I've heard of wt, a C++ web framework although I've never used it http://www.webtoolkit.eu/wt http://www.webtoolkit.eu/wt
  - grignr 17y ago
    I've been hacking C++ long enough to agree C++/STL/Boost is good and fast... but I can't remember the last time I heard anyone accuse C++ of being easy...
    - e4m 17y ago
      I find it easy. The bad thing about c++ is its size. It's large and that tends to make it complex. However, I find that I only use about 40 to 60 percent of what c++ can actually do. Focus on the parts that you use and you'll find a lot of the complexity goes away.
      - silentbicycle 17y ago
        One problem is that if you work with other people in c++, the 40 to 60 percent they use won't necessarily overlap with yours.
        fauigerzigerk 17y ago
- bena 17y ago
  It made me laugh. I liked the part about the "hippy shit".
- timr 17y ago
  Your comment adds less to an intelligent discussion than does the article you're calling a troll. First, this isn't a troll. The guy posted a blog post on his own blog. He didn't post off-topic content to a thread and didn't try to provoke an argument in an otherwise civil conversation. The only possible way that you can characterize this as a troll is that he uses some crude language, and says some things that are unpopular on HN. But say what you will about the content, he didn't try to make you read it. Second, the guy has a point. I've had a rant like this building in my craw for a long time, and this guy nailed nearly every point I've wanted to make. From a software engineering perspective, web development is in the dark ages. What's worse, it's a luddite process -- a totally self-made exile from the benefits of 50 years of progress: Type safety is shunned. Language efficiency is ignored. Data structures beyond the hash table are exotic and rare (and worse, I've met more than one "professional" web developer who couldn't tell me the difference between open and closed hashing!) I understand very well that programmer time is more valuable than computer hardware, and that the speed/development time trade-off is often biased toward development time. But if you ask me, what was once an intelligent guideline is now becoming a cult. It is possible to do rapid development in a compiled language, and there are some really good reasons -- beyond execution speed -- to revisit the idea.
  - rbanffy 17y ago
    "Your comment adds less to an intelligent discussion than does the article you're calling a troll." Sometimes the truth is very simple. It can be considered a troll because it is in the tone "if you don't do as I say you are an idiot, like everyone else". Second: not all scripting languages are interpreted on the fly. In fact, many of the most popular frameworks load objects once and keep their compiled forms in memory. Even for languages that run under VMs, some of them run under JIT that, in the end, results in machine-language-like times. Third: I have profiled a lot of web applications and most of the time they are either waiting for the pipe to deliver a request or waiting for the database to deliver the data. Very few web applications I know of do heavy processing. For those, I agree compiled code may help. and, finally, by the time the guy finishes his C code, an equivalent competing application that uses Rails will be approaching the millionth registered user.
jerryji 17y ago
> So this is why I’m writing a web framework in C. Why C, why not assembly? In fact, you know what real programmers use? -- http://xkcd.com/378/ http://xkcd.com/378/ > Grow the fuck up... > finding Rails developers is fucking impossible... You grow up > ediblepet.net is proudly powered by WordPress When will you release your compiled blog platform?
- burke 17y ago
  Oh, you haven't heard? He ported WordPress to C. I was pretty impressed.
  - petercooper 17y ago
    Did he outsource it to Tim Ferriss or something?! I thought he was busy finishing off Duke Nukem Forever.
    - burke 17y ago
      Yeah, I heard it only took him four hours, too.
- chanux 17y ago
  Maybe he has saved time for the real work with wordpress.
trjordan 17y ago
Ranting aside, this seems like a valid complaint. Scaling and performance seem to be reasonably important in web applications, so why not write them in C? If the only complaint is the lack of good tools, why not build those tools? Disclaimer: I don't actually work on web apps, and therefore have no experience with these things.
- burke 17y ago
  The increased productivity of writing in a scripting language typically outweighs the cost of extra servers. Whereas with a desktop application, you only have X resources to allocate to a task, you can always "just throw more servers at" a web application to some degree. It is done occasionally though; last I heard, large portions of Amazon.com were written in C.
- sounddust 17y ago
  If your site starts to take a performance hit in rendering pages, you can simply write a module in C to handle the part of the script that's using an excessive amount of CPU time, and keep the rest in script. But for most web apps, rendering HTML pages from script is not the bottleneck, it's the interaction with the database, and the solution is intelligent caching to reduce load on the database. The tools to mitigate these problems are already written in C (memcached, etc).
  - zepolen 17y ago
    Reread what you wrote :) Once you lower the the db io issues, rendering does become the bottleneck. Luckily rendering scales just by adding more servers. Rewriting templating code in C though rarely adds more speed, most dynamic languages tune their string handling as much as possible. Also, utilizing http caching mechanisms are a (quite underused) great solution for lowering load.
    - bad_user 17y ago
      > Once you lower the the db io issues ... It is highly unlikely that happens. Once you lower your DB issues, if the application is responsive enough you start working on other features. By the time you're done the application got new users and the DB is a problem again ... it's a cycle :) Fortunately HTTP servers do scale by caching and load-balancing. The author of the post probably never worked in real-world conditions. You first have to have users and real needs for scaling, and that doesn't happen unless you deliver a useful application first, and you also have to deliver it pretty fast, otherwise you might lose to a competitor with the same idea.
wooby 17y ago
I wrote the upload and download handlers for droplink.me in C as FastCGIs, anticipating performance problems. I built it; but they never really came. It was a fun exercise, but if I wasn't interested in having fun with C, I would have written it in a dynamic language. I think the reason there isn't a "C web development community" is that programmers are more than willing to trade time for performance. Safe, readable code can be written in high level languages in a snap. You can see your ideas happen very quickly. If you run into performance problems (which I think is safe to say is a fairly rare occurrence for the average web developer who produces decent code, in any language), you can a) refactor or streamline what you already have or b) start fresh, lessons learned, in something lower level. An aside: the site http://halfbakery.com http://halfbakery.com is implemented entirely as an Apache module.
sounddust 17y ago
It's been done. http://advogato.org/proj/mod_virgule/ http://advogato.org/proj/mod_virgule/
niyazpk 17y ago
In web the model is different: You develop an app, push it live and find out what works and what does not, change and iterate. This means that doing the iterations with minimum time and effort are important than worrying about scalability and performance. You can always throw hardware at the perfortmace problem. If you get enough traffic to become worried about performace, that itself is the mark of success. But to become successful, first you must build the app and get it live somehow instead of worrying about performace issues or wasting months coding in some very low level language!
- CodeMage 17y ago
  You can always throw hardware at the performance problem. No, you can't. That's what scalability means. If you don't have scalability, then additional hardware will only take you so far before you begin wasting it.
  - justin_vanw 17y ago
    Well, you are both kindof taking the extreme view. If you build your app such that the webservers can act independently, then by using various methods of load balancing you can just throw hardware at the problem. However, this just usually leaves the database as the single point of contention among all webservers. There are various ways to reduce load on the database server by some constant factor (memcache, query caching), but in the end database load will be roughly linear with site load (requests/time). You can't just add SQL-based DB servers and get linear speedup like (properly thought out) webservers. If you think your site will get so big so fast you won't have time to hire engineers to figure out the scaling problems before they become unmanageable (for example, facebook got huge, but it took a few years, so they had time to raise money and adapt their stuff, although they were pretty slow for a long time), then use appengine datastore or simpledb or some other db that promises to scale really well (this is a really hard problem, which is why there aren't a lot of open source things that do this. Note: couchedb can't scale writes, so I don't count it). My personal thinking is that one big properly designed database can get you pretty far, and database clustering can get you far enough. If you find it pleasant, putting your app in appengine would make you pay the price of scalability a little at a time starting right away, instead of letting you push it off (but with a huge performance wall that you won't be able to get over without basically redesigning much of your apps internals).
goodkarma 17y ago
If you're going to write it in C, why not just write it in Java? You could use the Google Web Toolkit..
- jdbeast00 17y ago
  removed ... i'm embarrassed at the wrongness of what i typed
  - jimbokun 17y ago
    Kind of. Similar syntax and design patterns, but I don't think you can directly compile a Cocoa application to Cappucino, or vice versa.
- albertcardona 17y ago
  Rather, write in python, profile it, and replace all CPU-intensive functions by C code in a custom python module. Best of both worlds.
  - ubernostrum 17y ago
    Or write it in Python, then run it under Jython.
marcofloriano 17y ago
I think you don´t have to stick with C (or any another language ) for everything. Each language are good for something. Right now, for example, i´m working in a financial intelligent software analyzer. I wrote the web crawler in ruby (not rails) and now i´m planing to write the core of the system, the decision maker, at Lisp. I think a programmer should not be sticked with just one language, there´s a lot of cool things out of the C world. You dont have to write an entire C framework to build an web apps at C ... it´s just too troublesome. You have another challenges. But when it comes to process data very fast in your server, so maybe you should consider another language.
rythie 17y ago
Most sites aren't CPU or memory intensive. If you are lucky enough to have enough users for that to be a concern you can add more servers. Sites normally bottle neck around the database and writing front end code in C is distraction from fixing the real problem which should be scaling the database.
- worldhello 17y ago
  Why not use clearsilver(http://www.clearsilver.net/ http://www.clearsilver.net/) to wrote frontend code? They do have a few large projects using clearsilver.
maigret 17y ago
That is why there are things called "application servers". Java is not perfect but it has a fine feature called JIT (Just In Time compiling) that produces machine code whenever it makes sense. Raw compiled language goes against the current trend for virtualization, whose goal is to save energy too. So in my opinion JIT is a good solution.
axod 17y ago
It's a valid point. I wrote the Mibbit backend from scratch in Java for these reasons. I can only start to imagine the horror I would be enduring if I'd chosen a scripting language. Having said that, choose the right tool for the job. edit: Downmod me all you like. A scripted language wouldn't handle 2k req/sec on a couple of VPSs.
- jerryji 17y ago
  But as your web application database grows more complex and larger, how do you intend to make them keep up with the 2k req/sec load?
  - axod 17y ago
    Why would anything need to go to db? :/ Going to db should always be a last, final resort. People often seem to think a db is the only way to write any webapp, and that everything must depend on the db. That's bad architecture. In the case of Mibbit, db access is only done for writes, lazily, in the background. The bottlenecks for me, are CPU, network, and ram. And yes, you can throw servers at it, if you're frivolous and don't intend to make any money. I decided to go the other way and be profitable ;)
    - kingkongrevenge 17y ago
      The vast majority of web applications are straight-up CRUD. Not making that all about a normalized schema is the stupid mistake. As far as relational DBs being the problem, that's more a matter of the free ones not cutting the mustard. Oracle and DB2 can handle jaw dropping load in the hands of an expert.
      - greyboy 17y ago
        Is DB2 not free? I thought they had a free version? http://www-01.ibm.com/software/data/db2/express/about.html http://www-01.ibm.com/software/data/db2/express/about.html
ryah 17y ago
Web site performance problems usually don't have much to do with the raw executing speed of the language they're written in. The problems derive from poor understanding of how to handle concurrent connections. If your app is written in C, but is accessed through a CGI interface - starting a process for each request - then it's going to be slow. Similarly if you write a web server which makes blocking connections to a backend database, your server will be slow. If you use threads to handle concurrent connections, you're going to allocate 2mb stacks for each user - and your website is going to suck. This all has little to do with how fast a language can invert a matrix.
- warfangle 17y ago
  And then there's situations like porting a Rails app to Lift and seeing a huge improvement in performance without touching the database / storage IO: http://lambda-the-ultimate.org/node/2147 http://lambda-the-ultimate.org/node/2147 Granted, it's not from the most unbiased source, so take it with a grain ;)
  - ryah 17y ago
    That has to do a lot with Ruby's awful thread implementation. You could possibly port the app again to Ruby EventMachine and see even better performance. The point is - for 99% of people it's not the language, it's the I/O
petercooper 17y ago
I chose C because C is the dominant language right now Good bit of satire. I wouldn't call it a troll because it's funny and just unbelievable enough, rather than inflammatory and merely misguided.
- icefox 17y ago
  Indeed, I would have to say that Javascript is the dominant language right now.
grayhacker 17y ago
No. You really don't want to do this. Really. I have worked with a project for the past several years that, by necessity not choice, required a web application framework written in C (it's an embedded platform) and I can tell you it is pure hell. The most mundane and simple tasks, often trivial one-liners in scripting languages, require many lines of error-prone C code even with a fairly rich set of libraries available. Working in this environment, you'll quickly realize why the rest of the world doesn't do it this way. Thankfully, this project is finally moving away from this architecture and I couldn't be happier about it.
- silentbicycle 17y ago
  Would Lua have worked there? It's a ~200k library designed to provide an embedded scripting language to C projects. (It's very similar to Python, but a tenth the size, and with a bit more Scheme influence.) While it may be too big for some especially tight embedded platforms, if you could fit it in, it would have likely been substantially less painful. It's also a pretty good scripting language on its own merits, and has replaced Python as my default language. (Unlike Python, its design expects you to know at least a little C, but in exchange, it avoids cluttering the language with things that C already does well.)
  - gamache 17y ago
    Lua is meant for embedding in C programs; that is different from running on embdedded systems. The latter typically features drastically less RAM and CPU cycles, so most interpreted languages (which are not shy about trading away some performance) don't cut it. There are some exceptions; FORTH, for instance, can fit in about a kilobyte and its performance isn't miserable. But putting e.g. Lua in a confined space would not work out well.
    - silentbicycle 17y ago
      To my understanding "embedded systems" spans from something with 1k of memory to something like a cell phone or a router. Working with Lua is quite comfortable on the latter, hence my qualification. It's been ported to Lego Mindstorms (http://www.hempeldesigngroup.com/lego/pbLua/index.html http://www.hempeldesigngroup.com/lego/pbLua/index.html), for example, which is "a 32 bit ARM7 microcontroller with 256K of FLASH and 64K of RAM." It's not clear from the post which end of the spectrum he or she works with. (I don't work with embedded systems professionally, I've just tinkered with OpenWRT, cell phones, etc. as an enthusiastic amateur.) It would be usable in the same niches that SQLite is, for example.
laktek 17y ago
Actually the same people he bash, did it before him. Remember Campfire's poller was written in C? Only recently they decided to change it to a must robust Erlang based implementation - http://www.37signals.com/svn/posts/1728-nuts-bolts-campfire-loves-erlang http://www.37signals.com/svn/posts/1728-nuts-bolts-campfire-...
piramida 17y ago
Funny article, I hope the author was not being serious. C is everything when you need performance, but having something done quick and maintainable - in C - no sorry. If somebody would dare to actually create a rails or django level framework in C it would simply have no community - not because it won't be 'hip' - I'd use it - but because implementing the same app would take exponentially more time. And that's what matters in the webworld. No matter how many rps your app can serve, if there is no app you get no requests to serve...
mdasen 17y ago
The reason why people choose to go with languages like Ruby is because the trade-off on speed is worth it. Web front-ends scale very easily. You can just add more web heads and load balance between them. Databases are much harder to scale since you need to keep data consistency and can't just throw more boxes at the problem. So, you don't need to be computationally efficient. However, you do need to develop fast. You need to be able to create features before your competition. You need to be able to make your system more reliable and bug-free than your competition. And that's where Ruby (and similar languages) helps you. Sure, you and Linus have a point that selection of language can keep out the riff-raff (Linus Torvalds having a huge rant against C++ simply because of the programming community), but it also means that you're missing out on the good parts of the community. Ruby programmers tend to put a lot of thought into user experience. While you've ranted against testing, I don't think any IT manager would agree with you there. Testing substantially improves one's ability to create new features because you can easily spot anywhere you've broken something. And that leads to better quality applications too. There's a difference between speed and scaling and if something scales fine, that's ok. Look at it this way, array indexing in a slower way to go through an array in C than incrementing a pointer. And if you had a lot of code you could go through and change all instances. However, it wouldn't be worth your time. Such an improvement wouldn't net you any real benefit while you'd be neglecting improving your product. Your product is what matters.
- baguasquirrel 17y ago
  I think your point is exacerbated by the fact that it's hard to get web UIs "right". I was critical of languages like python and ruby until I had to do the frontend for some company code. Box looks like it needs to be shifted a few pixels right? Modify code, compile, check. Logo looks better with an offset? Modify code, compile, check. Writing in a scripting language makes it just Modify, check. You just can't do that in compiled languages, and the compiled language of choice for the web-- Java --isn't known for blazing compilation speed. You'd probably also have to jar it up and copy the damn thing over, whereas psps could be modified in-place. I think this is something that compiled folks like me simply failed to grasp: all the things about scripting languages that make them orders of magnitude faster for developing, especially for the web.
DannoHung 17y ago
If you're going to the trouble of compiling something, why the fuck are you serving web pages?
- prodigal_erik 17y ago
  If I only pay for the server hardware, I don't care how inefficient the client is unless it's completely unusable.
bensummers 17y ago
Aside from the fact it's an obvious troll... I had that basic idea when web app frameworks starting becoming popular. So I implemented a web framework which took a 'description' of the app written in perl, and generated C++ which compiled into a single exe file which served the app with a built in http server. Small bits of business logic were written in C++, but basically it was done by the perl. All templates, internationalisation, everything, compiled down to a few database queries, string concatenations and the odd if statement. I then build a couple of production sites in this, one on my own, and another with a few other developers. Conclusions from this: 1) It's really really fast and efficient, and the single exe model for deployment is lovely. 2) It's a pain to implement such a framework, and a pain to use it. 3) I'm never using perl again. 4) Life's too short for this kind of game. The code is here: http://www.boxbackup.org/trac/ticket/6 http://www.boxbackup.org/trac/ticket/6
- bad_user 17y ago
  I like Perl ... using modern Perl practices and CPAN modules. It's the best web development environment I worked with ... and I've worked on projects with PHP (my own framework :) + Symfony), Python/Django/web.py, ASP.NET, Java/Struts and Ruby/Rails. You should give it another try sometimes. Take a look at Catalyst (the web framework), DBIx::Class, Moose and POE.
  - bensummers 17y ago
    I think I just got a bit fed up of the crufty syntax for object-orientated code. Everything computer-related sucks, you just have to choose something which sucks the least where it matters for your project. And familiarity counts for a lot too.
nathanwdavis 17y ago
There are already a few options for a MVC web framework in compiled code. I'm working on ASP.NET MVC now. It's compiled, but development does not feel like that because of JIT compilation. Also, it will run in Mono on Linux if I want.
- vyrotek 17y ago
  I love Asp.net MVC :)
trickjarrett 17y ago
On the upside, it means web developers have another way to slack off: "But we can't work, the project is compiling!" As if web devs needed another way to burn our time.
cosmo7 17y ago
I agree that compiled statically typed code is more robust than scripts, but I'd choose a safer language like C# or Java over C.
utx00 17y ago
this was either written by someone with no experience in C, or a C uber expert.
edw519 17y ago
"I predict in the future all the good web engineers will be moving to compiled languages, and all the academic idiots programming social networking applications, ajax widget home pages, and projects to better improve our democracy will be staying behind coding in the latest and greatest slow language, going to circle jerk conferences to hear some scumbag just oozing hubris from every pore tell them to get in shape and learn to fly a kite." +1 for "academic idiots" +1 for "improve our democracy" +1 for "circle jerk conferences" +2 for "scumbag just oozing hubris" I just hope his c isn't as poetic as his prose.
st3fan 17y ago
I don't think the guy is troll. I think he simply doesn't know better. This is a classic case of micro-optimization. While he should look at the bigger picture. It is all about global architecture.
JulianMorrison 17y ago
Ruby vs C misses out the middle ground of SBCL, Java, Scala, Haskell.
Kalimotxo 17y ago
His point is valid, but the bottom line is that hardware resources are far cheaper than human resources today. Yes, many of us know C, but a lot of us would rather use the abstractions provided by scripting languages.
- alexgartrell 17y ago
  False. You only have to write ONE application, you have to buy N servers. It doesn't take very large N to overcome the price of a good programmer. Hardware is expensive when you have to buy _lots_ of it.
PhilChristensen 17y ago
Sweet merciful lord. Is this guy channelling Zed Shaw or what? Apart from all the hand-waving and generalizations, this guy doesn't sound like he's ever really a webapp under serious load. I'm not a Ruby guy, so I don't know how things fly with that, but I've never once had a problem with a webapp being slow because of the language it was written in. Bad database queries, unnecessary assets being loaded, definitely. But CPU-bound limitations caused purely because of the cost of interpretation of a scripting language? Not so much...
- dag 17y ago
  I'm quite sure that, if we had HN memes, your 2nd line would spawn another one. It's very HN-ish. Example usage: "Yes, he can write well, but has he ever really a webapp?"
- timr 17y ago
  I've worked on a webapp under serious load, and I think he's right. You're correct that database queries and resource bottlenecks are the usual problems for web application scaling, but even taking that into account, I've had more than one problem that was caused by the simple fact that Ruby is a dog of a language. Python is better, but only just so. Perl is faster than both, but still nowhere near as fast as a C++ program. But let's ignore execution speed, since one can make a reasonable argument that even the slowest scripting language can saturate the network I/O on modern hardware. I think I'd still consider using a compiled language, because the type-safety and compile-time guarantees of a statically typed language would go a long way toward eliminating a huge class of silly bugs that we deal with on a daily basis. That's developer time in the bank.
  - apgwoz 17y ago
    > I think I'd still consider using a compiled language, because the type-safety and compile-time guarantees of a statically typed language would go a long way toward eliminating a huge class of silly bugs that we deal with on a daily basis. Not all compiled languages are statically typed. > That's developer time in the bank. And the time spent in the edit, compile, test, run, cycle? I'd think there's more developer time in the bank if I can edit, test, run.
kingkongrevenge 17y ago
I don't see how it's possible to make a good framework in C. It lacks the necessary abstractions. It lacks even basic vital things like namespaces. Why on earth would someone attempt this in C rather than C++? You could come pretty close to simply rewriting a scripting framework in C++. I don't know what you can get done in C. It will be so dependent on programmer conventions it will be hideous. People actually have made some damn good C++ frameworks. See asio. What are the C ones? Any complex C system devolves into a mess of macros, casts, and naming conventions.
- huherto 17y ago
  Actually what I would most miss in C is really basic stuff like dynamic strings, dynamic arrays and hashes.
raganwald 17y ago
I will live to be a happy old man if I never read another blog post telling me in absolute terms what I must do and why I'm an idiot if I don't. I blame Joel Spolsky for this, his tone and style seems to have kicked off an entire sub-culture of blogging where the posts read like a lunatic standing on a street corner demanding that we repent before the end of the world and the coming of the messiah. Bloggers, please try a kinder, gentler tone, one that suggests you and I are colleagues. One that suggests you have discovered some neat thing and won't I have a look at it and isn't it interesting to play "what if" games with it and maybe, just maybe I might experiment with it. Looking back on my own posts, I would say the strongest ones are those where I found a more reasoned voice. An essay can be strongly opinionated without being imperative.
- axod 17y ago
  I agree, but TBH there have been a lot of ridiculously overhyped blog posts/articles telling us how totally awesome every scripting language is, and how it's completely a 'game changer' and how you can do completely revolutionary things in them really easily. I guess this is just a reaction to the froth+hype. Both sides need to step away from the keyboard, and calm down.
  - raganwald 17y ago
    If a blog post says "wonderful, amazing, fun, life-affirming," we can always respond with "oh? what about..." My thought is that there's no need for a post saying "You're gonna die if you try to build a social bookmarking site in Lisp" regardless of how much fun other people are having doing it. What have people got against enthusiasm, any ways? There's some kind of weird puritanical thing going around programming culture that seems to view youthful exuberance as some kind of a sin, like wearing buttons on a frock coat. Yeah, some twenty-somthing year-old has discovered something way-cool really neat amazing thing while hacking on a macbook in the café. Isn't that exactly the attitude you're supposed to have in your twenties? How would anything ever change if people didn't get super-excited beyond all rational limit? Can you imagine Wozniak and Jobs trying to blog about microcomputers these days? They'd get flamed as hippies fiddling with toys :-)
jerf 17y ago
Actually, the problem isn't compiled vs. non-compiled, the problem is C vs. languages that you can actually safely manipulate strings in without segfaults, buffer overflows, and other "own the box/own the webservice" flaws. Arguably, all the languages that show up down near C in the Shootout would be fine languages to write webservices in, since nearly all of them are as fast as C without the eXtreme danger. Some web services are "shovel strings from the DB out to the user", like CMSs, but for those that aren't, this isn't a terrible point. (It's easy to forget when you're the type of person who hangs out on HN, but for most people, compiled == C, or C++ if you're lucky.)
Ionic_Walrus 17y ago
the blog misses a central point - its not the choice of language thats a bottleneck. I'll trade performance to large number of users any day because I know I can solve the performance issue. Personally I'd go with perl - as thats the language Im most comfortable with.
e4m 17y ago
I have done this in c++... not write an entire web framework, just use compiled c++ code to do some heavy lifting on a shared web server. It worked great. Before, I was using python/django. c++/cgi did the same task and was about 30 times faster. I'm not sure I'd throw away the scripting languages entirely, but making it easy to integrate c or c++ into these languages in this manner is probably a good idea. It's not that hard to write very highly optimized c++ and it can have a huge impact on performance... at least that has been my experience. While the article was inflammatory, I think the guy has a valid point. He just needs better people skills ;)
snorkel 17y ago
If you must write web apps in C then consider writing it as an Apache module. But how much traffic would you need to justify this? Web app developers have an unhealthy obsession with performance and scalability that distracts them from building what really matters: features. Twitter proved you can be just as successful if you work on features now and scalability later.
- warfangle 17y ago
  "Twitter proved you can be just as successful if you work on a feature now and scalability later" fixed that for you ;)
loincloth 17y ago
Dick. USE IT. OR DON'T. NEXXXXTTTTT.
- loincloth 17y ago
  Heh.. the mood swings of HN users are just adorable. I got +13 for making the exact same remark re: jQuery recently. Either people are hypersensitive to "dick" or "C", either way.. very curious..
ynniv 17y ago
Why can't we downmod articles?
ckinnan 17y ago
Has this guy never heard of op-code cache? You can easily avoid a lot of script compiling on a production web server.
knowtheory 17y ago
Guys, his point isn't valid. If you want to write things in C, the current implementation of ruby LETS YOU. That's the whole point of C extensions. You can then ask, why bother writing in Ruby at all, and i think you'll find the answer to be, it's not anywhere near as much of a pain in the ass as writing C is. The elitism argument is bullshit. We don't need fewer people programming. We need better ways to tell if someone knows what the fuck they're doing. In my opinion the tools we use and develop should be as accessible as possible. Anyone should be able to pick them up and get what they need to do, done. Good luck doing that with C.
Flemlord 17y ago
Why write your own framework when you can use Silverlight?
sarvesh 17y ago
Isn't that's what CGI is for? If you want a full blown web application framework in C is going to be a lot of work. String manipulation, parsing HTML with standard C libraries is not going to be easy. Java, C# and Python have pretty decent frameworks to do this I don't see the point of writing one using C.
- duskwuff 17y ago
  CGI is an interface, not a library or a language.
- gdee 17y ago
  Why does the server side (whatever might live there) have to parse HTML?
zandorg 17y ago
Viaweb used C on the backend.
- pg 17y ago
  Not really. The shopping basket (this was before everyone settled on "cart") was written in C, but the shopping basket wasn't the back end of the rest of the system, just one of several components that ran in parallel.
  - zandorg 17y ago
    I stand corrected. I just remember reading about Viaweb using C on your website. But I was right in that the cart used it.
absconditus 17y ago
Investigating the many frameworks and libraries available for Java would probably be a better course of action. http://projects.apache.org/indexes/language.html#Java http://projects.apache.org/indexes/language.html#Java
Deadly_B 17y ago
I notice comments on the blog post are currently closed. I wonder why. ;) Although I understand the author's position, it is obvious this is a tech person and not a well-rounded business person. The thing about programming is it's not all about tech. A program typically serves one purpose: to make a company money. This requires more than just pristine tech. First and foremost it requires time to market so that a company can stay competitive. It also requires the ability for more than just a handful of people to be able to write it for expandability and, God forbid, staff changes. C is fast. But slow to market. And slow to pick up a program. And slow to test. That's why there is so much WYSIWYG. Don't get me wrong: there needs to be a lot more code behind and a lot less script out there, but in the end coding is a balance. Anytime anyone says it's all this or all that, you know the position is not sound. It's part speed, part usability, part scalability, part development speed, part readability, part expandability, part pretty pictures, etc. Balance in all things.
synnik 17y ago
I find it ironic that he mocks "the losers who don’t know how to code and instead just pontificate endlessly about the hippest new blog post that totally changed their way of thinking" Isn't that exactly who is writing to? Doesn't he WANT people to pontificate about his post and change our thinking? So why is he mocking his intended audience?
deleted 17y ago
[deleted]
tlrobinson 17y ago
No, the solution is not to write web application in C, it's to make faster interpreters for higher level languages. I like not having to worry about buffer overflows and memory management and such. That said, I'll be interested to see what he comes up with.
wglb 17y ago
Well, if I were forced to write in C these days, I would seriously write a C/C++ generator in Lisp to speed the time to market. But if I could do it where nobody was watching, I would use a different compiled language, Lisp (SBCL) that would get good enough performance and get to market before the manly C/C++ coder. So on a semi-serious note, why is (apparently) nobody going for the real performance kill, which is to write a framework in hand-coded assembler? Would it be twice as fast as C?
vlod 17y ago
The first thing that came to into my head was 'What problem is he trying to solve?' Does he have performance problems? Is it cost effective to solve those performance problems using C? What is the ROI? Has the performance problem been analyzed to a degree that its been identified that its the web framework? (Most of the time a decent database index will help) Go after the lower hanging fruit first and make decisions on quantitive data analysis.. not just your gut.
jonursenbach 17y ago
Sounds like this guy was fucked over by a contractor.
waratuman 17y ago
Na, why should the be compiled! Come on, do some ASIC for some real performance!
jonursenbach 17y ago
WE'LL DO IT LIVE. FUCK IT. I'LL WRITE IT. FUCKING RUBY SUCKS
Rob15283 17y ago
Wow, who peed in his oatmeal?
alexgartrell 17y ago
I would NOT trust a website with my private data if they wrote their app in C. Buffer overflow -> execute your own code -> write a function that pipes an entire database out to you. It really is a trivial problem given the buffer overflow, and programmers (myself included) generally suck at not putting buffered overflows into code. Plus there's the whole portability thing, which is entirely pissed away by C compilation (yes, arguably you can write generic C, but there are fundamental differences (file i/o, sockets, etc.) between different OS's, and restricting yourself is dumb) Pre-compilation of scripting languages isn't necessarily a bad thing though. And this guy is no C expert. He's just got a golden hammer. http://en.wikipedia.org/wiki/Golden_hammer http://en.wikipedia.org/wiki/Golden_hammer
c00p3r 17y ago
Google already trying to run native x86 code in browser, so, they probably will be compiled soon. =)
avibryant 17y ago
Has anyone else actually looked at this guy's code? http://github.com/joelmichael/memereap/tree/master http://github.com/joelmichael/memereap/tree/master Perhaps unsurprisingly, it shows no awareness of SQL injection, buffer overflows, or concurrency. These seem like things a web framework might need to deal with...
eli 17y ago
The thing is, most webapps are just database frontends.
pyman 17y ago
This site is becoming the next Reddit! Full of stupid comments. Stop wasting your time people, go and read a book or build something.

129 points by csbartus 17y ago

jimbokun 17y ago

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

nuclear_eclipse 17y ago
From 2008-09-28: The old blog software, Typo, is nowhere near as good as Wordpress. I only used it because it was written in Ruby on Rails and I am a Ruby on Rails coder. This is a very poor means of choosing software.
mildweed 17y ago
At least he's planning on putting his money where his mouth is. If he creates this framework, more power to him!
- stcredzero 17y ago
  The VisualWorks Smalltalk Server Pages framework already does this. SSP results in web pages as compiled machine language. The HTML file is translated into a new Smalltalk method, the tags become Smalltalk message sends, and the HTML between the dynamic tags just become accesses into an Array. Because Array access is optimized and JITed as machine code, the only message sends are due to the dynamic tags. When the webpage/method is JITed, you have a web page compiled into machine code.
  - mikeryan 17y ago
    I believe the framework discussion is of a compiled C "Rails" type MVC framework, I'm not familiar with Smalltalk Server Pages but from an initial google search it doesn't seem to be on par with what rails provides?
    - stcredzero 17y ago
      You're right that SSP is more like ASP/JSP, and not like Rails. But the same idea can be used with a more comprehensive web framework and with a language that has a really good JIT, like LuaJIT, or maybe IronPython/IronRuby.
  - fauigerzigerk 17y ago
    Sounds pretty much like JSP.
dryicerx 17y ago
I don't think it's a troll, but just someone who is really in to performance, like I do, and I agree with him on some points. But what I don't agree is using just C. C is too low level and is a horrific unfit task for web development. Instead C++ would be a good fit (and writing in C mixed in). The STL/Boost provide a wonderful abstraction layer that does pretty much anything you throw at it with ease, plus there are lot of other libraries for anything else you can ever think of. I've written several web applications in C++, and it was actually very much like writing in Python/PHP/Ruby and at time prefered writing it in C++ after writing a poc in a scripting language. They were just a little bit less readable but very clean, but the biggest plus the the multiple magnitude performance increase of the application it self with FastCGI. (all these applications were serious number crunchers and had lot of CPU and Memory Bound problems). tldr; C for web dev painful, C++ with STL/Boost good/easy/fast/clean. Also I've heard of wt, a C++ web framework although I've never used it http://www.webtoolkit.eu/wt http://www.webtoolkit.eu/wt
- grignr 17y ago
  I've been hacking C++ long enough to agree C++/STL/Boost is good and fast... but I can't remember the last time I heard anyone accuse C++ of being easy...
  - e4m 17y ago
    I find it easy. The bad thing about c++ is its size. It's large and that tends to make it complex. However, I find that I only use about 40 to 60 percent of what c++ can actually do. Focus on the parts that you use and you'll find a lot of the complexity goes away.
    - silentbicycle 17y ago
      One problem is that if you work with other people in c++, the 40 to 60 percent they use won't necessarily overlap with yours.
      - fauigerzigerk 17y ago
bena 17y ago
It made me laugh. I liked the part about the "hippy shit".
timr 17y ago
Your comment adds less to an intelligent discussion than does the article you're calling a troll. First, this isn't a troll. The guy posted a blog post on his own blog. He didn't post off-topic content to a thread and didn't try to provoke an argument in an otherwise civil conversation. The only possible way that you can characterize this as a troll is that he uses some crude language, and says some things that are unpopular on HN. But say what you will about the content, he didn't try to make you read it. Second, the guy has a point. I've had a rant like this building in my craw for a long time, and this guy nailed nearly every point I've wanted to make. From a software engineering perspective, web development is in the dark ages. What's worse, it's a luddite process -- a totally self-made exile from the benefits of 50 years of progress: Type safety is shunned. Language efficiency is ignored. Data structures beyond the hash table are exotic and rare (and worse, I've met more than one "professional" web developer who couldn't tell me the difference between open and closed hashing!) I understand very well that programmer time is more valuable than computer hardware, and that the speed/development time trade-off is often biased toward development time. But if you ask me, what was once an intelligent guideline is now becoming a cult. It is possible to do rapid development in a compiled language, and there are some really good reasons -- beyond execution speed -- to revisit the idea.
- rbanffy 17y ago
  "Your comment adds less to an intelligent discussion than does the article you're calling a troll." Sometimes the truth is very simple. It can be considered a troll because it is in the tone "if you don't do as I say you are an idiot, like everyone else". Second: not all scripting languages are interpreted on the fly. In fact, many of the most popular frameworks load objects once and keep their compiled forms in memory. Even for languages that run under VMs, some of them run under JIT that, in the end, results in machine-language-like times. Third: I have profiled a lot of web applications and most of the time they are either waiting for the pipe to deliver a request or waiting for the database to deliver the data. Very few web applications I know of do heavy processing. For those, I agree compiled code may help. and, finally, by the time the guy finishes his C code, an equivalent competing application that uses Rails will be approaching the millionth registered user.

jerryji 17y ago

> So this is why I’m writing a web framework in C. Why C, why not assembly? In fact, you know what real programmers use? -- http://xkcd.com/378/ http://xkcd.com/378/ > Grow the fuck up... > finding Rails developers is fucking impossible... You grow up > ediblepet.net is proudly powered by WordPress When will you release your compiled blog platform?

burke 17y ago
Oh, you haven't heard? He ported WordPress to C. I was pretty impressed.
- petercooper 17y ago
  Did he outsource it to Tim Ferriss or something?! I thought he was busy finishing off Duke Nukem Forever.
  - burke 17y ago
    Yeah, I heard it only took him four hours, too.
chanux 17y ago
Maybe he has saved time for the real work with wordpress.

trjordan 17y ago

Ranting aside, this seems like a valid complaint. Scaling and performance seem to be reasonably important in web applications, so why not write them in C? If the only complaint is the lack of good tools, why not build those tools? Disclaimer: I don't actually work on web apps, and therefore have no experience with these things.

burke 17y ago
The increased productivity of writing in a scripting language typically outweighs the cost of extra servers. Whereas with a desktop application, you only have X resources to allocate to a task, you can always "just throw more servers at" a web application to some degree. It is done occasionally though; last I heard, large portions of Amazon.com were written in C.
sounddust 17y ago
If your site starts to take a performance hit in rendering pages, you can simply write a module in C to handle the part of the script that's using an excessive amount of CPU time, and keep the rest in script. But for most web apps, rendering HTML pages from script is not the bottleneck, it's the interaction with the database, and the solution is intelligent caching to reduce load on the database. The tools to mitigate these problems are already written in C (memcached, etc).
- zepolen 17y ago
  Reread what you wrote :) Once you lower the the db io issues, rendering does become the bottleneck. Luckily rendering scales just by adding more servers. Rewriting templating code in C though rarely adds more speed, most dynamic languages tune their string handling as much as possible. Also, utilizing http caching mechanisms are a (quite underused) great solution for lowering load.
  - bad_user 17y ago
    > Once you lower the the db io issues ... It is highly unlikely that happens. Once you lower your DB issues, if the application is responsive enough you start working on other features. By the time you're done the application got new users and the DB is a problem again ... it's a cycle :) Fortunately HTTP servers do scale by caching and load-balancing. The author of the post probably never worked in real-world conditions. You first have to have users and real needs for scaling, and that doesn't happen unless you deliver a useful application first, and you also have to deliver it pretty fast, otherwise you might lose to a competitor with the same idea.

wooby 17y ago

I wrote the upload and download handlers for droplink.me in C as FastCGIs, anticipating performance problems. I built it; but they never really came. It was a fun exercise, but if I wasn't interested in having fun with C, I would have written it in a dynamic language. I think the reason there isn't a "C web development community" is that programmers are more than willing to trade time for performance. Safe, readable code can be written in high level languages in a snap. You can see your ideas happen very quickly. If you run into performance problems (which I think is safe to say is a fairly rare occurrence for the average web developer who produces decent code, in any language), you can a) refactor or streamline what you already have or b) start fresh, lessons learned, in something lower level. An aside: the site http://halfbakery.com http://halfbakery.com is implemented entirely as an Apache module.

sounddust 17y ago

It's been done. http://advogato.org/proj/mod_virgule/ http://advogato.org/proj/mod_virgule/

niyazpk 17y ago

In web the model is different: You develop an app, push it live and find out what works and what does not, change and iterate. This means that doing the iterations with minimum time and effort are important than worrying about scalability and performance. You can always throw hardware at the perfortmace problem. If you get enough traffic to become worried about performace, that itself is the mark of success. But to become successful, first you must build the app and get it live somehow instead of worrying about performace issues or wasting months coding in some very low level language!

CodeMage 17y ago
You can always throw hardware at the performance problem. No, you can't. That's what scalability means. If you don't have scalability, then additional hardware will only take you so far before you begin wasting it.
- justin_vanw 17y ago
  Well, you are both kindof taking the extreme view. If you build your app such that the webservers can act independently, then by using various methods of load balancing you can just throw hardware at the problem. However, this just usually leaves the database as the single point of contention among all webservers. There are various ways to reduce load on the database server by some constant factor (memcache, query caching), but in the end database load will be roughly linear with site load (requests/time). You can't just add SQL-based DB servers and get linear speedup like (properly thought out) webservers. If you think your site will get so big so fast you won't have time to hire engineers to figure out the scaling problems before they become unmanageable (for example, facebook got huge, but it took a few years, so they had time to raise money and adapt their stuff, although they were pretty slow for a long time), then use appengine datastore or simpledb or some other db that promises to scale really well (this is a really hard problem, which is why there aren't a lot of open source things that do this. Note: couchedb can't scale writes, so I don't count it). My personal thinking is that one big properly designed database can get you pretty far, and database clustering can get you far enough. If you find it pleasant, putting your app in appengine would make you pay the price of scalability a little at a time starting right away, instead of letting you push it off (but with a huge performance wall that you won't be able to get over without basically redesigning much of your apps internals).

goodkarma 17y ago

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

jdbeast00 17y ago
removed ... i'm embarrassed at the wrongness of what i typed
- jimbokun 17y ago
  Kind of. Similar syntax and design patterns, but I don't think you can directly compile a Cocoa application to Cappucino, or vice versa.
albertcardona 17y ago
Rather, write in python, profile it, and replace all CPU-intensive functions by C code in a custom python module. Best of both worlds.
- ubernostrum 17y ago
  Or write it in Python, then run it under Jython.

marcofloriano 17y ago

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

rythie 17y ago

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

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

maigret 17y ago

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

axod 17y ago

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

jerryji 17y ago
But as your web application database grows more complex and larger, how do you intend to make them keep up with the 2k req/sec load?
- axod 17y ago
  Why would anything need to go to db? :/ Going to db should always be a last, final resort. People often seem to think a db is the only way to write any webapp, and that everything must depend on the db. That's bad architecture. In the case of Mibbit, db access is only done for writes, lazily, in the background. The bottlenecks for me, are CPU, network, and ram. And yes, you can throw servers at it, if you're frivolous and don't intend to make any money. I decided to go the other way and be profitable ;)
  - kingkongrevenge 17y ago
    The vast majority of web applications are straight-up CRUD. Not making that all about a normalized schema is the stupid mistake. As far as relational DBs being the problem, that's more a matter of the free ones not cutting the mustard. Oracle and DB2 can handle jaw dropping load in the hands of an expert.
    - greyboy 17y ago
      Is DB2 not free? I thought they had a free version? http://www-01.ibm.com/software/data/db2/express/about.html http://www-01.ibm.com/software/data/db2/express/about.html

ryah 17y ago

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

warfangle 17y ago
And then there's situations like porting a Rails app to Lift and seeing a huge improvement in performance without touching the database / storage IO: http://lambda-the-ultimate.org/node/2147 http://lambda-the-ultimate.org/node/2147 Granted, it's not from the most unbiased source, so take it with a grain ;)
- ryah 17y ago
  That has to do a lot with Ruby's awful thread implementation. You could possibly port the app again to Ruby EventMachine and see even better performance. The point is - for 99% of people it's not the language, it's the I/O

petercooper 17y ago

I chose C because C is the dominant language right now Good bit of satire. I wouldn't call it a troll because it's funny and just unbelievable enough, rather than inflammatory and merely misguided.

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

grayhacker 17y ago

No. You really don't want to do this. Really. I have worked with a project for the past several years that, by necessity not choice, required a web application framework written in C (it's an embedded platform) and I can tell you it is pure hell. The most mundane and simple tasks, often trivial one-liners in scripting languages, require many lines of error-prone C code even with a fairly rich set of libraries available. Working in this environment, you'll quickly realize why the rest of the world doesn't do it this way. Thankfully, this project is finally moving away from this architecture and I couldn't be happier about it.

silentbicycle 17y ago
Would Lua have worked there? It's a ~200k library designed to provide an embedded scripting language to C projects. (It's very similar to Python, but a tenth the size, and with a bit more Scheme influence.) While it may be too big for some especially tight embedded platforms, if you could fit it in, it would have likely been substantially less painful. It's also a pretty good scripting language on its own merits, and has replaced Python as my default language. (Unlike Python, its design expects you to know at least a little C, but in exchange, it avoids cluttering the language with things that C already does well.)
- gamache 17y ago
  Lua is meant for embedding in C programs; that is different from running on embdedded systems. The latter typically features drastically less RAM and CPU cycles, so most interpreted languages (which are not shy about trading away some performance) don't cut it. There are some exceptions; FORTH, for instance, can fit in about a kilobyte and its performance isn't miserable. But putting e.g. Lua in a confined space would not work out well.
  - silentbicycle 17y ago
    To my understanding "embedded systems" spans from something with 1k of memory to something like a cell phone or a router. Working with Lua is quite comfortable on the latter, hence my qualification. It's been ported to Lego Mindstorms (http://www.hempeldesigngroup.com/lego/pbLua/index.html http://www.hempeldesigngroup.com/lego/pbLua/index.html), for example, which is "a 32 bit ARM7 microcontroller with 256K of FLASH and 64K of RAM." It's not clear from the post which end of the spectrum he or she works with. (I don't work with embedded systems professionally, I've just tinkered with OpenWRT, cell phones, etc. as an enthusiastic amateur.) It would be usable in the same niches that SQLite is, for example.

laktek 17y ago

Actually the same people he bash, did it before him. Remember Campfire's poller was written in C? Only recently they decided to change it to a must robust Erlang based implementation - http://www.37signals.com/svn/posts/1728-nuts-bolts-campfire-loves-erlang http://www.37signals.com/svn/posts/1728-nuts-bolts-campfire-...

piramida 17y ago

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

mdasen 17y ago

The reason why people choose to go with languages like Ruby is because the trade-off on speed is worth it. Web front-ends scale very easily. You can just add more web heads and load balance between them. Databases are much harder to scale since you need to keep data consistency and can't just throw more boxes at the problem. So, you don't need to be computationally efficient. However, you do need to develop fast. You need to be able to create features before your competition. You need to be able to make your system more reliable and bug-free than your competition. And that's where Ruby (and similar languages) helps you. Sure, you and Linus have a point that selection of language can keep out the riff-raff (Linus Torvalds having a huge rant against C++ simply because of the programming community), but it also means that you're missing out on the good parts of the community. Ruby programmers tend to put a lot of thought into user experience. While you've ranted against testing, I don't think any IT manager would agree with you there. Testing substantially improves one's ability to create new features because you can easily spot anywhere you've broken something. And that leads to better quality applications too. There's a difference between speed and scaling and if something scales fine, that's ok. Look at it this way, array indexing in a slower way to go through an array in C than incrementing a pointer. And if you had a lot of code you could go through and change all instances. However, it wouldn't be worth your time. Such an improvement wouldn't net you any real benefit while you'd be neglecting improving your product. Your product is what matters.

baguasquirrel 17y ago
I think your point is exacerbated by the fact that it's hard to get web UIs "right". I was critical of languages like python and ruby until I had to do the frontend for some company code. Box looks like it needs to be shifted a few pixels right? Modify code, compile, check. Logo looks better with an offset? Modify code, compile, check. Writing in a scripting language makes it just Modify, check. You just can't do that in compiled languages, and the compiled language of choice for the web-- Java --isn't known for blazing compilation speed. You'd probably also have to jar it up and copy the damn thing over, whereas psps could be modified in-place. I think this is something that compiled folks like me simply failed to grasp: all the things about scripting languages that make them orders of magnitude faster for developing, especially for the web.

DannoHung 17y ago

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

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

bensummers 17y ago

Aside from the fact it's an obvious troll... I had that basic idea when web app frameworks starting becoming popular. So I implemented a web framework which took a 'description' of the app written in perl, and generated C++ which compiled into a single exe file which served the app with a built in http server. Small bits of business logic were written in C++, but basically it was done by the perl. All templates, internationalisation, everything, compiled down to a few database queries, string concatenations and the odd if statement. I then build a couple of production sites in this, one on my own, and another with a few other developers. Conclusions from this: 1) It's really really fast and efficient, and the single exe model for deployment is lovely. 2) It's a pain to implement such a framework, and a pain to use it. 3) I'm never using perl again. 4) Life's too short for this kind of game. The code is here: http://www.boxbackup.org/trac/ticket/6 http://www.boxbackup.org/trac/ticket/6

bad_user 17y ago
I like Perl ... using modern Perl practices and CPAN modules. It's the best web development environment I worked with ... and I've worked on projects with PHP (my own framework :) + Symfony), Python/Django/web.py, ASP.NET, Java/Struts and Ruby/Rails. You should give it another try sometimes. Take a look at Catalyst (the web framework), DBIx::Class, Moose and POE.
- bensummers 17y ago
  I think I just got a bit fed up of the crufty syntax for object-orientated code. Everything computer-related sucks, you just have to choose something which sucks the least where it matters for your project. And familiarity counts for a lot too.

nathanwdavis 17y ago

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

vyrotek 17y ago
I love Asp.net MVC :)

trickjarrett 17y ago

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

cosmo7 17y ago

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

utx00 17y ago

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

edw519 17y ago

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

st3fan 17y ago

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

JulianMorrison 17y ago

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

Kalimotxo 17y ago

His point is valid, but the bottom line is that hardware resources are far cheaper than human resources today. Yes, many of us know C, but a lot of us would rather use the abstractions provided by scripting languages.

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

PhilChristensen 17y ago

Sweet merciful lord. Is this guy channelling Zed Shaw or what? Apart from all the hand-waving and generalizations, this guy doesn't sound like he's ever really a webapp under serious load. I'm not a Ruby guy, so I don't know how things fly with that, but I've never once had a problem with a webapp being slow because of the language it was written in. Bad database queries, unnecessary assets being loaded, definitely. But CPU-bound limitations caused purely because of the cost of interpretation of a scripting language? Not so much...

dag 17y ago
I'm quite sure that, if we had HN memes, your 2nd line would spawn another one. It's very HN-ish. Example usage: "Yes, he can write well, but has he ever really a webapp?"
timr 17y ago
I've worked on a webapp under serious load, and I think he's right. You're correct that database queries and resource bottlenecks are the usual problems for web application scaling, but even taking that into account, I've had more than one problem that was caused by the simple fact that Ruby is a dog of a language. Python is better, but only just so. Perl is faster than both, but still nowhere near as fast as a C++ program. But let's ignore execution speed, since one can make a reasonable argument that even the slowest scripting language can saturate the network I/O on modern hardware. I think I'd still consider using a compiled language, because the type-safety and compile-time guarantees of a statically typed language would go a long way toward eliminating a huge class of silly bugs that we deal with on a daily basis. That's developer time in the bank.
- apgwoz 17y ago
  > I think I'd still consider using a compiled language, because the type-safety and compile-time guarantees of a statically typed language would go a long way toward eliminating a huge class of silly bugs that we deal with on a daily basis. Not all compiled languages are statically typed. > That's developer time in the bank. And the time spent in the edit, compile, test, run, cycle? I'd think there's more developer time in the bank if I can edit, test, run.

kingkongrevenge 17y ago

I don't see how it's possible to make a good framework in C. It lacks the necessary abstractions. It lacks even basic vital things like namespaces. Why on earth would someone attempt this in C rather than C++? You could come pretty close to simply rewriting a scripting framework in C++. I don't know what you can get done in C. It will be so dependent on programmer conventions it will be hideous. People actually have made some damn good C++ frameworks. See asio. What are the C ones? Any complex C system devolves into a mess of macros, casts, and naming conventions.

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

raganwald 17y ago

I will live to be a happy old man if I never read another blog post telling me in absolute terms what I must do and why I'm an idiot if I don't. I blame Joel Spolsky for this, his tone and style seems to have kicked off an entire sub-culture of blogging where the posts read like a lunatic standing on a street corner demanding that we repent before the end of the world and the coming of the messiah. Bloggers, please try a kinder, gentler tone, one that suggests you and I are colleagues. One that suggests you have discovered some neat thing and won't I have a look at it and isn't it interesting to play "what if" games with it and maybe, just maybe I might experiment with it. Looking back on my own posts, I would say the strongest ones are those where I found a more reasoned voice. An essay can be strongly opinionated without being imperative.

axod 17y ago
I agree, but TBH there have been a lot of ridiculously overhyped blog posts/articles telling us how totally awesome every scripting language is, and how it's completely a 'game changer' and how you can do completely revolutionary things in them really easily. I guess this is just a reaction to the froth+hype. Both sides need to step away from the keyboard, and calm down.
- raganwald 17y ago
  If a blog post says "wonderful, amazing, fun, life-affirming," we can always respond with "oh? what about..." My thought is that there's no need for a post saying "You're gonna die if you try to build a social bookmarking site in Lisp" regardless of how much fun other people are having doing it. What have people got against enthusiasm, any ways? There's some kind of weird puritanical thing going around programming culture that seems to view youthful exuberance as some kind of a sin, like wearing buttons on a frock coat. Yeah, some twenty-somthing year-old has discovered something way-cool really neat amazing thing while hacking on a macbook in the café. Isn't that exactly the attitude you're supposed to have in your twenties? How would anything ever change if people didn't get super-excited beyond all rational limit? Can you imagine Wozniak and Jobs trying to blog about microcomputers these days? They'd get flamed as hippies fiddling with toys :-)

jerf 17y ago

Actually, the problem isn't compiled vs. non-compiled, the problem is C vs. languages that you can actually safely manipulate strings in without segfaults, buffer overflows, and other "own the box/own the webservice" flaws. Arguably, all the languages that show up down near C in the Shootout would be fine languages to write webservices in, since nearly all of them are as fast as C without the eXtreme danger. Some web services are "shovel strings from the DB out to the user", like CMSs, but for those that aren't, this isn't a terrible point. (It's easy to forget when you're the type of person who hangs out on HN, but for most people, compiled == C, or C++ if you're lucky.)

Ionic_Walrus 17y ago

the blog misses a central point - its not the choice of language thats a bottleneck. I'll trade performance to large number of users any day because I know I can solve the performance issue. Personally I'd go with perl - as thats the language Im most comfortable with.

e4m 17y ago

I have done this in c++... not write an entire web framework, just use compiled c++ code to do some heavy lifting on a shared web server. It worked great. Before, I was using python/django. c++/cgi did the same task and was about 30 times faster. I'm not sure I'd throw away the scripting languages entirely, but making it easy to integrate c or c++ into these languages in this manner is probably a good idea. It's not that hard to write very highly optimized c++ and it can have a huge impact on performance... at least that has been my experience. While the article was inflammatory, I think the guy has a valid point. He just needs better people skills ;)

snorkel 17y ago

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

warfangle 17y ago
"Twitter proved you can be just as successful if you work on a feature now and scalability later" fixed that for you ;)

loincloth 17y ago

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

loincloth 17y ago
Heh.. the mood swings of HN users are just adorable. I got +13 for making the exact same remark re: jQuery recently. Either people are hypersensitive to "dick" or "C", either way.. very curious..

ynniv 17y ago

Why can't we downmod articles?

ckinnan 17y ago

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

knowtheory 17y ago

Guys, his point isn't valid. If you want to write things in C, the current implementation of ruby LETS YOU. That's the whole point of C extensions. You can then ask, why bother writing in Ruby at all, and i think you'll find the answer to be, it's not anywhere near as much of a pain in the ass as writing C is. The elitism argument is bullshit. We don't need fewer people programming. We need better ways to tell if someone knows what the fuck they're doing. In my opinion the tools we use and develop should be as accessible as possible. Anyone should be able to pick them up and get what they need to do, done. Good luck doing that with C.

Flemlord 17y ago

Why write your own framework when you can use Silverlight?

sarvesh 17y ago

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

duskwuff 17y ago
CGI is an interface, not a library or a language.
gdee 17y ago
Why does the server side (whatever might live there) have to parse HTML?

zandorg 17y ago

Viaweb used C on the backend.

pg 17y ago
Not really. The shopping basket (this was before everyone settled on "cart") was written in C, but the shopping basket wasn't the back end of the rest of the system, just one of several components that ran in parallel.
- zandorg 17y ago
  I stand corrected. I just remember reading about Viaweb using C on your website. But I was right in that the cart used it.

absconditus 17y ago

Investigating the many frameworks and libraries available for Java would probably be a better course of action. http://projects.apache.org/indexes/language.html#Java http://projects.apache.org/indexes/language.html#Java

Deadly_B 17y ago

I notice comments on the blog post are currently closed. I wonder why. ;) Although I understand the author's position, it is obvious this is a tech person and not a well-rounded business person. The thing about programming is it's not all about tech. A program typically serves one purpose: to make a company money. This requires more than just pristine tech. First and foremost it requires time to market so that a company can stay competitive. It also requires the ability for more than just a handful of people to be able to write it for expandability and, God forbid, staff changes. C is fast. But slow to market. And slow to pick up a program. And slow to test. That's why there is so much WYSIWYG. Don't get me wrong: there needs to be a lot more code behind and a lot less script out there, but in the end coding is a balance. Anytime anyone says it's all this or all that, you know the position is not sound. It's part speed, part usability, part scalability, part development speed, part readability, part expandability, part pretty pictures, etc. Balance in all things.

synnik 17y ago

I find it ironic that he mocks "the losers who don’t know how to code and instead just pontificate endlessly about the hippest new blog post that totally changed their way of thinking" Isn't that exactly who is writing to? Doesn't he WANT people to pontificate about his post and change our thinking? So why is he mocking his intended audience?

deleted 17y ago

[deleted]

tlrobinson 17y ago

No, the solution is not to write web application in C, it's to make faster interpreters for higher level languages. I like not having to worry about buffer overflows and memory management and such. That said, I'll be interested to see what he comes up with.

wglb 17y ago

Well, if I were forced to write in C these days, I would seriously write a C/C++ generator in Lisp to speed the time to market. But if I could do it where nobody was watching, I would use a different compiled language, Lisp (SBCL) that would get good enough performance and get to market before the manly C/C++ coder. So on a semi-serious note, why is (apparently) nobody going for the real performance kill, which is to write a framework in hand-coded assembler? Would it be twice as fast as C?

vlod 17y ago

The first thing that came to into my head was 'What problem is he trying to solve?' Does he have performance problems? Is it cost effective to solve those performance problems using C? What is the ROI? Has the performance problem been analyzed to a degree that its been identified that its the web framework? (Most of the time a decent database index will help) Go after the lower hanging fruit first and make decisions on quantitive data analysis.. not just your gut.

jonursenbach 17y ago

Sounds like this guy was fucked over by a contractor.

waratuman 17y ago

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

jonursenbach 17y ago

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

Rob15283 17y ago

Wow, who peed in his oatmeal?

alexgartrell 17y ago

I would NOT trust a website with my private data if they wrote their app in C. Buffer overflow -> execute your own code -> write a function that pipes an entire database out to you. It really is a trivial problem given the buffer overflow, and programmers (myself included) generally suck at not putting buffered overflows into code. Plus there's the whole portability thing, which is entirely pissed away by C compilation (yes, arguably you can write generic C, but there are fundamental differences (file i/o, sockets, etc.) between different OS's, and restricting yourself is dumb) Pre-compilation of scripting languages isn't necessarily a bad thing though. And this guy is no C expert. He's just got a golden hammer. http://en.wikipedia.org/wiki/Golden_hammer http://en.wikipedia.org/wiki/Golden_hammer

c00p3r 17y ago

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

avibryant 17y ago

Has anyone else actually looked at this guy's code? http://github.com/joelmichael/memereap/tree/master http://github.com/joelmichael/memereap/tree/master Perhaps unsurprisingly, it shows no awareness of SQL injection, buffer overflows, or concurrency. These seem like things a web framework might need to deal with...

eli 17y ago

The thing is, most webapps are just database frontends.

pyman 17y ago

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