pkieltyka

I prefer twirp's model of no http2 requirement and supports JSON. https://github.com/twitchtv/twirp

I do think twirp code could be refactored and made a lot better though.

Hi all, I'm one of the designers of the sup project.

Interestingly, we only looked at Ansible, or later heard of salt, after we already wrote the first version of sup. Later our friends told us it reminded them of Ansible. We believe sup is much simpler, because its more DIY from the perspective of the user.

It's written in Go and currently the master cloc's in at 890 lines of code. Sup is just a small utility and personally I view it as complete, other than any refinements that come through its life. Thanks to Go, it's also pretty nice that the sup binary doesn't require the install of any external runtime.

When designing it, our high-level goals were to have a very fast and simple deployment tool that anyone on our development team (including frontend devs), could deploy their applications to our network. It's been working really well for us for over a year now.

To be honest, I've still never tried Ansible or salt, and I'm sure there is a lot of capabilities they have, but, whatever they are, we've been fine without them. For example, sup doesn't have 1000s of community playbooks, but you can reference local programs/scripts that are piped and executed remotely on a network - we use this often for deploying docker containers.

Finally here's something I love, and maybe possible with Ansible (I don't see why not):

https://gist.github.com/pkieltyka/4ab679a692db47e0b410f66b3a...

then run.. `sup staging tail-logs` to tail live server output. Or even filter it with, `sup staging tail-logs | grep WARN`.

I hope AngularJS implements a virtual DOM, but I'm keen to transition to reactjs anyways, as I prefer assembling a program from many libraries instead of a monolithic framework

thats interesting! since Consul / Serf are written in Go.. have you considered using boltdb? https://github.com/boltdb/bolt it's an LMDB implementation in Go, really clean code.

Cool addition to vagrant. It reminds me a lot of another useful tunneling utility written in Go: https://ngrok.com. Maybe an inspiration for it? And also, an interesting related deck: https://speakerdeck.com/inconshreveable/gosf-decentralizing-...

shabam! well put.

This would be even cooler if it implemented the S3 REST protocol so that people could use existing S3 clients.

Could be useful for testing or home-grown S3 network. Ie. put that in front of a bunch of Riak-backed servers.

IMO, its a step in the right direction to build threaded concurrency into the foundation of a Ruby web server. Events can be layered within those threads. Then you can even have a nice mix of sync / async code on a single web server running harmoniously. Also, if running just a single thread, we're in the same place as most other Ruby web server, but for those VMs that can take advantage of it, and for those stacks that can benefit, its awesome.

I hear you guys in the comments saying events is the way to go for concurrency in Ruby, especially with MRI. As many also know, GIL-less threads are available in modern Ruby VMs like Rubinius and JRuby.

I haven't tried puma yet, but I do believe in evanphx's work.

Also, for those interested in concurrency with Ruby, also check out: https://github.com/tarcieri/celluloid and https://github.com/tarcieri/nio4r .. looks like Tony even has a fork of puma in there too.

+1 :)