
Woo: Fast HTTP Server in Common Lisp - momo-reina
https://github.com/fukamachi/woo
======
dschiptsov
What is interesting here is to compare this one man's effort with "ancient
tools" well-researched by two generations of old-school programmers with that
amateurish hype and nonsense about node (author publicly stated in his blog
that he has no experience with server side development on a POSIX system) and
golang - a minimalist approach, carefully crafted by a rigorously trained
"professionals". It is not just about KBs and milliseconds.

Btw, this "Hello world" example tells a little, basically, how efficiently
memory allocation, and IO layer are implemented (that's why no one still could
beat nginx).

Much more interesting comparison would be of some "real-world scenario", say,
"implement an http look up for some public data-set, imported into a
_persistent_ local storage, say, Postgresql" and then compare not just
throughput rates, but also resource usage.

~~~
coldtea
> _Btw, this "Hello world" example tells a little, basically, how efficiently
> memory allocation, and IO layer are implemented (that's why no one still
> could beat nginx)._

Actually at least on other guy just beat nginx just other day -- don't
remember the name, it was some Japanese made server.

~~~
lomnakkus
I think you might be thinking about Kazu Yamamoto and Mighttpd2? (Written in
Haskell, incidentally.) I think this was the web server that beat out nginx on
a largish number of cores (42?). For the life of me I can't find the original
paper with the comparison graph, otherwise I'd link to it...

Anyway, a lot of the performance work which went into mighttpd2 is
automatically shared by all Haskell applications. (Most of it went to
optimizing the GHC VM I/O Manager which handles I/O in the Haskell runtime.
It's sort of like libev/libuv only at the VM level instead of as a library.)

~~~
voxic11
[https://github.com/h2o/h2o](https://github.com/h2o/h2o)

~~~
lomnakkus
I don't think that was the "Hey, look! Haskell beats nginx!" one, but very
interesting nonetheless! :)

------
kjksf
It's not really written in Common Lisp.

"built on top of libev"

The lisp part is a thin ffi wrapper on top of lots of C code.

Not than an ffi wrapper around C code isn't useful, but it's C code that does
all the heavy lifting there.

~~~
sanxiyn
Indeed, Node.js is a thin FFI wrapper on top of lots of C (and C++) code that
does all the heavy lifting, but it is still useful. I think Woo is useful the
same way.

~~~
aikah
the title implies "the heavy lifting" is written in LISP.

Every node user knows the net lib nodejs uses isnt written in javascript.And
most also know that in order for node to be useful,scripts should do as little
as possible and delegate any serious operation to C/C++.

~~~
eudox
>the title implies "the heavy lifting" is written in LISP.

Woo uses fast-http[0], quri[1], and http-body[2], all written in pure Common
Lisp and very, very fast.

[0]: [https://github.com/fukamachi/fast-
http](https://github.com/fukamachi/fast-http)

[1]: [https://github.com/fukamachi/quri](https://github.com/fukamachi/quri)

[2]: [https://github.com/fukamachi/http-
body](https://github.com/fukamachi/http-body)

------
gaigepr
It makes me really happy to see projects like this for common lisp. I still
relatively new to the lisp world but I have fallen in love with the language
and development process.

------
joosters
I see so many 'blazing fast' HTTP servers, in every language imaginable. Does
anyone write a slow HTTP server any more?

The real challenge is in writing a useful, useable server which still stays
fast under load. In contrast, you have to be writing terrible coding horrors
for your home-grown static file web server _NOT_ to be wire-speed :)

(No offence to the writers of this particular server, I haven't looked at the
code)

~~~
how_gauche
The reason people care about speed here is the reason people care about speed
in all infrastructure projects: every millisecond of the timeslice spent doing
work inside the transport is a millisecond you're not accomplishing
application logic. Efficient http code lowers distributed system latency and
saves power.

------
hedwall
When I see someone doing benchmarks like this against localhost i get
skeptical. Race conditions might very well be present.

------
bayesianhorse
Lately I began to study information security in more detail. Isn't the "code
is data" philosophy of common lisp a nightmare for a web server?

~~~
hga
Classically, "code is data" is used upfront, in creating macros that
manipulate Lisp code as data, before sending the result to the interpreter or
compiler like normal functions and data. Ideally you develop your own Domain
Specific Language that provides power in expression and execution for what
you're trying to do.

As implied in other answers in the subthread, nowhere in this paradigm does
random input data get treated as something that can safely be executed. READ
in Lisp Machines is mentioned because reader macros like #. allow data in the
form being read to be evaluated, which in this domain is an obvious big no-no.

As early as 1983, I think earlier, it was recognized that things like eval
servers were a bad idea if accessible by the outside world.

~~~
bayesianhorse
So, I am really just a beginner. To me it seems to be the case that attackers
may find a way to break out of a particular data processing instruction and
execute arbitrary lisp code.

If you say, this can't be so, you may well be right...

~~~
hga
As I understand it, unless you're using a Lisp with an reader macro that calls
eval, or your code calls eval, _and_ you allow arbitrary input into that code
while running vs. loading/compiling, it's just not going to happen.

------
dom96
How did you generate those pretty graphs?

------
aikah
When doing a speed benchmark,I consider the memory profile to be as relevant
as the number of requests per second.

------
bodokaiser
Why not use libuv right away?

~~~
orthecreedence
See
[https://github.com/orthecreedence/wookie](https://github.com/orthecreedence/wookie),
a fast app server that uses libuv (very much in the same vein as Woo).

------
Immortalin
One of the greatest barriers to lisp for me is the lack of free IDEs and
better tooling. Having cut my teeth in programming using VB, I generally find
any language that doesn't come with a GUI builder and a half-decent IDE with
intellisense out of the box to be dismal.(Scripting languages is the
exception) I really hope someone will improve on the tooling of lisp. I
strongly believe in the mantra that you should not do something that the
computer the computer can do better, I believe a smart intellisense
autocompletion is much better than having to figure out the intricacies of
emacs/vim/<insert your favourite editor here>. I really like the syntax of
lisp, it would be really sad if I can't be productive with it. :(

~~~
gte525u
Yes, there are a lack of non-commercial IDEs for Lisp that are purpose-built
and give a great "Out of the Box Experience".

However, don't dismiss SLIME due to emacs. It contains all the nice IDE
functions - symbol completion, attaching (and editing!) long running
processes, function tracing, stack tracing, find references etc.

Access to a REPL in a running system image is an amazing and productive
experience.

