
Mongrel2 Almost Valgrind Pure, Bstring Happy - FraaJad
http://sheddingbikes.com/posts/1277863730.html
======
ihodes
Before we go too deep into Zed-hating, I’ve got to say I am _psyched_ for
Mongrel2, and I don't even have a particular use in mind for it.

Aside from the fact that it'll undoubtedly be a great piece of software, it's
informative and interesting to follow along with his progress on his blog and
on his fossil repo.

And if what he promises in terms if features and performance comes to
fruition, it'll be a fscking awesome server/gift to hack on and hack with.

Cheers, Zed. Keep it up!

~~~
zedshaw
Thanks man. I'm pretty stoked about it too. It's shaping up nicely and is tons
of fun, not to mention I really think it's got potential.

I just hope it honestly puts an end to this insistence on "one language to
rule them all".

~~~
demallien
Zed, do you think you could have written Mongrel2 in C, whilst doing a good
job, without having already had the experience with Mongrel v1? What I'm
trying to get at is our we just seeing another example of scripting languages
being good for prototyping, but getting better raw performance(memory
footprint,/speed/disk usage) from a lower level language? Or do you think you
could have ended up with a decent architecture on a first go?

~~~
jonhohle
I'm not Zed, but I have taken this approach several times (Primarily
Ruby->Objective-C, but also Ruby->C). I often find it helpful to validate an
idea in code quickly, and rewrite for speed/scalabilty/platform
integration/etc once I'm happy with a design.

------
modeless
"Despite all the evidence that C is quite alright for many applications, and
that no, the world doesn't end because of its use"

The world only doesn't end because people are so used to the terrible security
record of C apps that they don't even blink when new remote code execution
vulnerabilities are found daily. Perhaps someday we'll realize it doesn't have
to be this way.

Also, _of course_ the Boehm GC isn't very good. It's ancient and in no way
representative of the latest technology in garbage collection. GC can only
really be good when it's integrated with the language. A precise generational
collector would perform far better but wouldn't be so easy to drop into a C
codebase.

~~~
zedshaw
Boehm's a very good garbage collector, given this:

> A precise generational collector would perform far better but wouldn't be so
> easy to drop into a C codebase.

It's that last part that's key. Without language support at even the basic
level, you won't get much better.

As for this "precise generational collector", I doubt it. Like everything,
saying you need a GC all the time to be safe is just more boogey man fear
mongering. You don't need a GC. They're nice yeah. But if you know the
application very well then memory management isn't too big a deal.

~~~
modeless
GC isn't required to be safe, and it doesn't guarantee safety, but it _does_
makes safety a whole lot more likely.

Boehm is the best garbage collector given its constraints, but that doesn't
make it a good garbage collector overall, or even one worth using. I agree
that good GC requires language support; what I disagree with is the attitude
that people should use C anyway and forget GC because Boehm isn't good.

~~~
zedshaw
You know, you bring up another point: Memory leaks are not a "safety" problem
in a web server. Just look at Rails. <rimshot>

------
johkra
I had to smile, when I read the head line and later the article. During my
first year of university, I wrote a verb conjugation engine and a very simple
webserver for the UI (I wanted cross-plattform compatibility and it was easier
than learning GTK+).

I, too, choose bstring for strings and used valgrind a lot. It's nice to see
I'm not the only one writing C code this way. (Although I don't write much C
anymore.)

------
bnoordhuis
> stupid J2ME clients that send chunked-encoding when they aren't supposed to
> (it's for servers morons).

Sorry, Mr. Shaw, but you are wrong (but I still like you and I'm looking
forward to Mongrel2).

RFC 2616 is careful to say 'server' when it means servers and 'client' when it
means clients. Section 3.6.1 specifically states that HTTP/1.1 _applications_
(so both clients and servers!) MUST support chunked encoding.

The developers of that Java HTTP client (Jakarta?) seem to have read the spec
more thoroughly than you did. :-)

~~~
xal
Furthermore, Chunked to the client is having a renaissance at the moment
thanks to the BigPipe ideas coming out of Facebook. Speaking of which,
Mongrel2 will be a tremendous server for apps that need this optimization.

~~~
zedshaw
No, this is chunked _from_ the client, not to the client. To the client is
quite alright and works great. From the client is absolutely retarded and
total abuse of the protocol.

Which brings up another point: HTTP is like the old testament. Wanna kill your
brother? Probably find something to support it. Wanna sacrifice a goat? Yep,
you could do that. Don't want people to sacrifice goats? Sure, rock on. Want
adultery? You could probably find that too. It's got everything depending on
what you read, where you read, and what context you take it in.

The HTTP RFC is like that. Want to send chunked encoding mixed inside a keep-
alive with request pipelining when you don't really need to? Rock on. Want
google web accelerator to hit links without you asking it to (in clear
violation of every other part of the browser standard)? Go for it. Don't want
people to do that? Cool there's another part.

After a while, you have to go with what's most probable, and just be explicit
in your own design about the rest.

------
jkmcf
The moral of these threads: don't argue with Zed. He'll out-point you! Don't
hate the coder, love the code.

------
danieldk
"Memory is predictable, and with Valgrind not a danger."

I find that statement a tad too optimistic. If you use Valgrind continually
(and people really should), you do catch memory misuse in normal situations.
It does not say much about how well programs function with 'abnormal' inputs
(accidents, exploits).

Given that bugs do happen, even to the best of programmers, would you rather
have a buffer overflow or an exception? It depends on the application and
context, but it is harder to answer (and get it right) than the author
pretends.

~~~
zedshaw
Well, your logic applies to every language, no matter what, always. The only
difference is the types of errors it can't handle and what tools you need to
avoid them.

I think of valgrind as a GC compiler.

~~~
danieldk
Of course, except that many runtimes/libraries handle tripping over array
boundaries gracefully, rather than overwriting memory. And some languages
avoid null/wild pointers completely.

Your programs will still be suspectible to buffer overflows, invalid
dereferencing, etc. While, say, Haskell programmers do not have the same
problems. Valgrind is no substitute to runtime checks and a proper type
system.

~~~
zedshaw
Your runtime checks and proper type system and at dynamic linking. That means
you don't have them, and they aren't a complete total truth of any kind at
all. They're just a highly probable enhancement.

------
JabavuAdams
_Switching stacks on the GC was like setting its house on fire and then
shooting it as it ran out the front door in its lingerie._

That's bad, right? I'm still giggling.

------
pfrtgi
A library for handling strings ? LMAO.

