Replacing small C programs with Haskell

http://blog.ezyang.com/2010/03/replacing-small-c-programs-with-haskell/

by chalst • 15 years ago

65 19 15 years ago

blog.ezyang.com

darklajid2• 15 years ago

I'd like to understand a little more about the technical requirements here. 'Running with different credentials than the webserver' sure could've been solved with a fastcgi/wsgi setup and a decent way for expiration/monitoring of these processes (which the author admits failing to get his head around at the time of the implementation/writing of the blog post).

As soon as you remove the startup time from the equation (by stopping to spawn a tool per request) the result is really just IO (writing a couple headers, serving a file) which _should_ perform quite similar in most applicable languages.

While I'd like to see more (practical) Haskell content, this seems to be a lot of reinvention (see for example the mime-table commits). Whatever the language ended up being, was there no way to solve that issue more easily (and arguably, cleaner)?

chalst3• 15 years ago

The code is pretty basic, and one can guess many of the requirements from it:

http://andersk.mit.edu/gitweb/scripts-static-cat.git/blob_pl...

The alternative to reinvention is usually borrowing other people's code, and it's often not clear that this will increase confidence in the correctness of the code.

What I take from this post is a reminder that efficiency worries need not deter one from using languages like Haskell for this kind of task, despite the widespread belief that "CGI programs have to be small". The example would be that bit more compelling if the authors had used Quick Check to partly specify the code.

ezyang• 15 years ago

We understand the tuning parameters for these processes a bit more since this post was written a year and a half ago (We hit a magic phase shift for our other FastCGI processes, at which point our servers started falling over from 4000 users worth of FastCGIs. "Good thing we didn't listen to Geoffrey when he suggested we run an Apache for each user.")

FastCGI static-cat should work (indeed, one of the original design intents was making this switch easy, if we decided to do it). But I disagree that language becomes irrelevant in this case: you still care about memory usage (since this will influence how many users you can support) and loading an entire interpreter can be pretty costly. I do agree that IO should be essentially comparable.

As for the reinvention, all of these features are what you would normally find in Apache. But Apache is a large, complicated piece of software, and we don't want it to have access to arbitrary user files if it is compromised.

darklajid2• 15 years ago

Thanks a lot. Of course you'll have done your homework, I just had the immediate 'Hmm.. Most of this exists already' reaction.

Interpreter: Sure. I've no clue how many concurrent users you have (or is that the 4000 above?) - at some point that becomes a good point again.

Anyway: Thanks a lot, appreciated the feedback directly from the source. :)

zem• 15 years ago

did you ever figure out why upx had such a large performance penalty?

Craiggybear• 15 years ago

Same here. I must be missing something big here because none of this makes sense. Its reinvention for the sake of it.

sciurus• 15 years ago

There's more information at http://scripts.mit.edu/wiki/Technical_overview_of_scripts.mi...

mark_l_watson• 15 years ago

Several years ago I started doing the same thing except that I used Gambit/C Scheme: small fast executables written in a convenient to use programming language.

I have been programming since the mid-1960s and in retrospect the only C/C++ code I have written that really needed to be written in C/C++ were games for Nintendo and for the PC.

joeyh2• 15 years ago

I'm doing this too.. The multimegabyte size of the haskell executables is the only drawback.

Well, and some portability issues if you want your code to be usable everywhere, since ghc is not bootstrapped on every artchitecture.

dons• 15 years ago

Use dynamic linking and object stripping, if space is a concern. You'll have tiny objects then.

http://stackoverflow.com/questions/6115459/small-haskell-pro...

ldesegur• 15 years ago

I tried Haskell but it doesn't cut it for me. So I switched to Go and have been very happy so far. I dig channels and co-routines. Type inference is great. I still wish some generics would happen in 2012. The lib is great for doing what C libs do in a more readable way.

joeyh2• 15 years ago

Debian (and thus Ubuntu I assume) still uses static linking of haskell. I hope this will change though. I think the issue is finding a way to avoid breaking binaries when haskell libraries are upgraded, since they don't have sonames like regular libraries do.

dextorious• 15 years ago

LOL comment in the article thread by (of course) "Anonymous":

should have done it in asm. time coding is greater but time savings in performance of program over long term makes up for it. but i guess asm is too difficult for you. visual basic is good for programmers who like “easy” job.

arctangent• 15 years ago

Another good replacement for C might be the D programming language:

http://en.wikipedia.org/wiki/D_(programming_language)

anon_d3• 15 years ago

As such, it's critically important that the program is concise and well-defined; both properties that are quite hard to get in C code.

This is baseless FUD.

chalst3• 15 years ago

I do think that it is easier to acquire confidence that well-written Haskell is correct than well-written C, and there is some evidence supporting this belief. There's room to argue this, but it is very far from baseless FUD.

For an example of the kind of techniques available to Haskell but not to C, check out:

http://www.andres-loeh.de/Contracts.html

Some correctness infrastructure, such as Quick Check, have proven themselves to be eminently practicable.

It is perhaps also true that it is easier to write Haskell well than to write C well: certainly there is no shortage of awful C coding out there.

anon_d3• 15 years ago

I love me some ML/Haskell, but the article is about small C programs. Small utility programs is the domain where C shines. C is dead-simple, ubiquitous, and fast. Just the tool-complexity of Haskell alone makes C the better choice for these kinds of programs.

Over the last several years, I've experimented with rewriting some of my small C programs in Haskell or ML, and vis-versa. Amazingly, the C programs often end up being shorter, simpler, and significantly less headache (for these small programs). I am very comfortable coding in all three languages, so I think I'm pretty unbiased.

Reading the code from the article, the Haskell code is much better written than the C code. I think the author is making a mistake in thinking the better code is a result of the merits of Haskell w.r.t C instead of just the result of the clean rewrite plus being more experienced with Haskell.

Replacing small C programs with Haskell

Related Stories