12 ms·

I'm surprised that he's doing this... after so much vitriol about the Ruby (and Rails) community and being "ripped off" with Mongrel, I would have expected him

I'm surprised that he's doing this... after so much vitriol about the Ruby (and Rails) community and being "ripped off" with Mongrel, I would have expected him to never touch it again. Granted, it's written in C, but I'd expect it to be heavily used with Rails. That said, its good that he is writing it. The more software is written, the higher the likelihood that _something_ will be great, and when Zed Shaw's writing it, it's probably pretty good.

chuhnk 16y ago
His primary use case is different for mongrel2 compared to mongrel however its based off the same HTTP parser and is a webserver so I guess the continuation seemed appropriate. Being completely written in C its going to be blindingly fast. I have a feeling it'll surge past unicorn, thin, passenger and everything else out there once its refactored and past beta.
- icey 16y ago
  Don't you think AGPL licensing will slow adoption? Nobody seems to be able to clearly define what you have to open source if you use AGPL'ed code.
  - mark_l_watson 16y ago
    I think that you simply need to buy an alternative license. This is also the way neo4j is monetized.
  - stesch 16y ago
    AFIK you just have to publish the source to the changes you made to mongrel2 itself if your server is public. And mongrel2 is not embedded. You connect to it. No linking. It's a server.
- cmelbye 16y ago
  Unicorn, Thin, and Passenger are all mainly written with C/C++ as far as I know.
  - chuhnk 16y ago
    Unicorn and thin are both written in ruby with the core being the ragel HTTP parser which was first implemented in mongrel. Thin took that ragel parser and added eventmachine to the mix which made it much faster the mongrel. Unicorn went a step further by leveraging the kernel in such a way that things got even faster. Macournoyer, creator of thin was working on thin-turbo, a rewrite of the thin backend in C but stopped a while back. Passenger I guess because its nginx or apache module has to be C but their focus was never performance, more ease of deployment. Passenger 3 will have performance improvements and they've got benchmarks here http://blog.phusion.nl/2010/06/10/the-road-to-passenger-3-technology-preview-1-performance-2/ http://blog.phusion.nl/2010/06/10/the-road-to-passenger-3-te... but I'm thinking mongrel2 will one up it.
- davidw 16y ago
  The advantage of Passenger is that it takes care of dynamically allocating instances of your app, adding them and removing them as needs be. I don't think Mongrel ever did this: you had to guess at how many instances you might need and hope for the best. (At least afaik - no one has ever corrected me when I've said that in the past).
  - uxp 16y ago
    You're correct, Mongrel had predetermined number of instances.
  - zedshaw 16y ago
    I actually wouldn't compete with those servers, because they are very language specific. I'm aiming for Mongrel2 to unify all the languages in the network architecture so that you can do what companies actually do: use what works. I could easily see Passenger or others providing a 0mq connector that Mongrel2 can talk to. Passenger is bad ass at running Ruby, so no point in trying to do that better.
  - jfager 16y ago
    I'm not a Ruby guy, so this might be a stupid question, but: why would you need to run more than a single instance of an app on a given server?
    - grandalf 16y ago
      That just refers to running multiple processes instead of multiple threads. Rails wasn't thread safe until recently and many ruby libraries still aren't (including the mysql driver). So it's common practice to run a "pack of mongrels" (a few processes simultaneously) and then load balance between them in case a long request ties one up for a while. Mongrel2 will let you effectively design part of your app to benefit from Rails (for example) and part to use 0mq and do a more evented style of design. All within one configuration / approach.
    - sandofsky 16y ago
      Ruby 1.8 uses green threads, so running multiple processes lets you use all your cores. As mentioned in another post, Rails used to not be thread safe. Right now I'm running a Rails site in production with multithreading enabled, but I'm sure many libraries in Ruby are not thread safe.
KERMIT 16y ago
He exaggerates. That's just his style. We accept it, and we generally ignore what he says. Mongrel is nothing but hype most of the time. It doesn't offer particularly advanced features that even nginx and lighttpd offer. It suffers from poor performance. It's only marginally useful if you're using Ruby on Rails. As it stands, Mongrel2 is basically vaporware at this point.
mark_l_watson 16y ago
Also: notice the AGPL license. If mongrel2 hits a sweet spot for the targeted types of web apps, Zed has a good chance of monetizing this project. I appreciate Zed's writing and work - so good luck to him. The use of AGPL has some interesting ramifications. For example, I still don't understand why AGPL projects like MongoDB can be used as part of large networked systems and this not be a violation of the AGPL if the entire system's source is not released under AGPL also. AGPL is "networked viral."
- acangiano 16y ago
  Straight from the horse's mouth (http://blog.mongodb.org/post/103832439/the-agpl http://blog.mongodb.org/post/103832439/the-agpl): "To say this another way: if you modify the core database source code, the goal is that you have to contribute those modifications back to the community. Note however that it is NOT required that applications using mongo be published. The copyleft applies only to the mongod and mongos database programs. This is why Mongo DB drivers are all licensed under an Apache license. You application, even though it talks to the database, is a separate program and “work”."
  - mark_l_watson 16y ago
    Thanks. I had read that also a while back, so this sounds like the MongoDB developers offer a sort of waiver to the straight-up AGPL, effectively making it the GPL. In any case, kudos to the MongoDB developers; I have used it on almost every project I have done this year.
    - psadauskas 16y ago
      Its a little different than the GPL. If you modify some GPL server code, and open that server up to "public" connections, you don't have to contribute back your changes, as long as you don't distribute the server itself. With the AGPL, however, you do. Some people, though, interpret that to also mean that any of your code that connects to an AGPL server must also be open-sourced; eg, you web app, if it connects to mongodb, you must provide the source. As far as I know, there's been no legal opinion if thats the case, and the mongodb devs have stated thats not how they read it, and thats not what they intend.
grandalf 16y ago
This is a very cool idea. I think it's actually more along the lines of nanite or fuzed (ironically) than mongrel1. I think Zed's approach is clever... to create a middleware layer that can intelligently (and without adding tons of config complexity) let people build fast, complex apps that fulfill requests using a variety of backends.
- stesch 16y ago
  From the description ("… designed for web applications over serving files") it seems that you still need a web server as proxy in front of it for mid-sized projects; to serve static files. (Bigger projects use a server/CDN just for static files.)
  - zedshaw 16y ago
    It'd be able to serve files just like normal, but at large scales smart companies use a big CDN and don't do their own file serving. The economies of scale are just not there to do it yourself. Mongrel2's advantage is its focus on apps. Combining HTTP, jssocket, and websockets seamlessly on one port means you can get the best of req/response and async operations in your GUIs.
iamwil 16y ago
He's been an advocate of building stuff over being a language snob. I remember reading in his book teaching programming to beginners that the important thing is to build stuff, not to nerd out about language features.
- zedshaw 16y ago
  That's because I find programming languages are marketed similar to religions and work more like Ponzi Schemes. My goal is to change the culture so that programmers start to think this "community/religion" attitude is weird. Basically, I'm a linguistic secularist. :-)
zedshaw 16y ago
Mongrel2 will be very language agnostic, in the same way that Mongrel was very "Ruby Framwork Agnostic". My experience there was that making the server fairly implemented for all created a boom in server frameworks. I'm looking for the same result with Mongrel2, but with many different languages.

chuhnk 16y ago

His primary use case is different for mongrel2 compared to mongrel however its based off the same HTTP parser and is a webserver so I guess the continuation seemed appropriate. Being completely written in C its going to be blindingly fast. I have a feeling it'll surge past unicorn, thin, passenger and everything else out there once its refactored and past beta.

icey 16y ago
Don't you think AGPL licensing will slow adoption? Nobody seems to be able to clearly define what you have to open source if you use AGPL'ed code.
- mark_l_watson 16y ago
  I think that you simply need to buy an alternative license. This is also the way neo4j is monetized.
- stesch 16y ago
  AFIK you just have to publish the source to the changes you made to mongrel2 itself if your server is public. And mongrel2 is not embedded. You connect to it. No linking. It's a server.
cmelbye 16y ago
Unicorn, Thin, and Passenger are all mainly written with C/C++ as far as I know.
- chuhnk 16y ago
  Unicorn and thin are both written in ruby with the core being the ragel HTTP parser which was first implemented in mongrel. Thin took that ragel parser and added eventmachine to the mix which made it much faster the mongrel. Unicorn went a step further by leveraging the kernel in such a way that things got even faster. Macournoyer, creator of thin was working on thin-turbo, a rewrite of the thin backend in C but stopped a while back. Passenger I guess because its nginx or apache module has to be C but their focus was never performance, more ease of deployment. Passenger 3 will have performance improvements and they've got benchmarks here http://blog.phusion.nl/2010/06/10/the-road-to-passenger-3-technology-preview-1-performance-2/ http://blog.phusion.nl/2010/06/10/the-road-to-passenger-3-te... but I'm thinking mongrel2 will one up it.
davidw 16y ago
The advantage of Passenger is that it takes care of dynamically allocating instances of your app, adding them and removing them as needs be. I don't think Mongrel ever did this: you had to guess at how many instances you might need and hope for the best. (At least afaik - no one has ever corrected me when I've said that in the past).
- uxp 16y ago
  You're correct, Mongrel had predetermined number of instances.
- zedshaw 16y ago
  I actually wouldn't compete with those servers, because they are very language specific. I'm aiming for Mongrel2 to unify all the languages in the network architecture so that you can do what companies actually do: use what works. I could easily see Passenger or others providing a 0mq connector that Mongrel2 can talk to. Passenger is bad ass at running Ruby, so no point in trying to do that better.
- jfager 16y ago
  I'm not a Ruby guy, so this might be a stupid question, but: why would you need to run more than a single instance of an app on a given server?
  - grandalf 16y ago
    That just refers to running multiple processes instead of multiple threads. Rails wasn't thread safe until recently and many ruby libraries still aren't (including the mysql driver). So it's common practice to run a "pack of mongrels" (a few processes simultaneously) and then load balance between them in case a long request ties one up for a while. Mongrel2 will let you effectively design part of your app to benefit from Rails (for example) and part to use 0mq and do a more evented style of design. All within one configuration / approach.
  - sandofsky 16y ago
    Ruby 1.8 uses green threads, so running multiple processes lets you use all your cores. As mentioned in another post, Rails used to not be thread safe. Right now I'm running a Rails site in production with multithreading enabled, but I'm sure many libraries in Ruby are not thread safe.

KERMIT 16y ago

He exaggerates. That's just his style. We accept it, and we generally ignore what he says. Mongrel is nothing but hype most of the time. It doesn't offer particularly advanced features that even nginx and lighttpd offer. It suffers from poor performance. It's only marginally useful if you're using Ruby on Rails. As it stands, Mongrel2 is basically vaporware at this point.

mark_l_watson 16y ago

Also: notice the AGPL license. If mongrel2 hits a sweet spot for the targeted types of web apps, Zed has a good chance of monetizing this project. I appreciate Zed's writing and work - so good luck to him. The use of AGPL has some interesting ramifications. For example, I still don't understand why AGPL projects like MongoDB can be used as part of large networked systems and this not be a violation of the AGPL if the entire system's source is not released under AGPL also. AGPL is "networked viral."

acangiano 16y ago
Straight from the horse's mouth (http://blog.mongodb.org/post/103832439/the-agpl http://blog.mongodb.org/post/103832439/the-agpl): "To say this another way: if you modify the core database source code, the goal is that you have to contribute those modifications back to the community. Note however that it is NOT required that applications using mongo be published. The copyleft applies only to the mongod and mongos database programs. This is why Mongo DB drivers are all licensed under an Apache license. You application, even though it talks to the database, is a separate program and “work”."
- mark_l_watson 16y ago
  Thanks. I had read that also a while back, so this sounds like the MongoDB developers offer a sort of waiver to the straight-up AGPL, effectively making it the GPL. In any case, kudos to the MongoDB developers; I have used it on almost every project I have done this year.
  - psadauskas 16y ago
    Its a little different than the GPL. If you modify some GPL server code, and open that server up to "public" connections, you don't have to contribute back your changes, as long as you don't distribute the server itself. With the AGPL, however, you do. Some people, though, interpret that to also mean that any of your code that connects to an AGPL server must also be open-sourced; eg, you web app, if it connects to mongodb, you must provide the source. As far as I know, there's been no legal opinion if thats the case, and the mongodb devs have stated thats not how they read it, and thats not what they intend.

grandalf 16y ago

This is a very cool idea. I think it's actually more along the lines of nanite or fuzed (ironically) than mongrel1. I think Zed's approach is clever... to create a middleware layer that can intelligently (and without adding tons of config complexity) let people build fast, complex apps that fulfill requests using a variety of backends.

stesch 16y ago
From the description ("… designed for web applications over serving files") it seems that you still need a web server as proxy in front of it for mid-sized projects; to serve static files. (Bigger projects use a server/CDN just for static files.)
- zedshaw 16y ago
  It'd be able to serve files just like normal, but at large scales smart companies use a big CDN and don't do their own file serving. The economies of scale are just not there to do it yourself. Mongrel2's advantage is its focus on apps. Combining HTTP, jssocket, and websockets seamlessly on one port means you can get the best of req/response and async operations in your GUIs.

iamwil 16y ago

He's been an advocate of building stuff over being a language snob. I remember reading in his book teaching programming to beginners that the important thing is to build stuff, not to nerd out about language features.

zedshaw 16y ago
That's because I find programming languages are marketed similar to religions and work more like Ponzi Schemes. My goal is to change the culture so that programmers start to think this "community/religion" attitude is weird. Basically, I'm a linguistic secularist. :-)

zedshaw 16y ago

Mongrel2 will be very language agnostic, in the same way that Mongrel was very "Ruby Framwork Agnostic". My experience there was that making the server fairly implemented for all created a boom in server frameworks. I'm looking for the same result with Mongrel2, but with many different languages.