We're looking for a C-hacker with experience in just-in-time compilers, virtual machines, runtime optimizations, etc to work with the Ruby core team on performance.
We primarily use Ruby / Ruby on Rails on the back end side. Ruby is a great language, but a slow one. We'd like to help make it faster. So we've teamed up with the Ruby creator Yukihiro "Matz" Matsumoto on the Ruby 3x3 effort (http://engineering.appfolio.com/appfolio-engineering/2015/11...).
About AppFolio: We create easy-to-use, cloud-based software that helps small and mid-sized businesses more effectively market, manage and grow their business. Today, our products serve the legal and property management industries.
This is definitely a nice improvement which can lead to Ruby performance improvements.
It's also worth noting that Ruby 3 in general will have a focus on performance. Matz talked about performance and the Ruby 3x3 effort during his RubyKaigi keynote. The goal of Ruby 3x3 is to make Ruby 3 be 3 times faster than Ruby 2.
Full disclosure: I work for AppFolio which is helping to sponsor the Ruby 3x3 effort.
Do you know if it has been decided where AppFolio is going to direct its generous support yet? Are you hiring anyone?
I think the most realistic option is the idea of putting the LLVM bitcode of MRI's functions into the MRI binary so that an LLVM JIT could optimise through the core library. Evan Phoenix talked about this idea at Ruby Kaigi.
Yes, we are going to hire someone. We now have the position open and are looking for candidates. We already have a couple of folks interested and we'd like to get a few more so that we can find the best fit.
Images are fun. But I'd like to see a demo showing how http/2 can affect asset managers / web development. Perhaps show a site with 1-5 bundled css / js vs 100-500 individual css / js.
Different beasts. A direct comparison is unfair to either of them.
Uglify does minification and dead code removal. That's really it.
Closure does a lot of type checking, code rewriting, and has a very specific subset of JS that you'll have to use if you really want to get the best performance out of it... and does minification and dead code removal.
If you just want minification/dead code removal then Uglify is waaay faster, javascript native, and almost as small (105-120% of the size of Closure compressed code, depending on the code). It also doesn't use the JVM so that can make dep management/ops simpler if you don't already have java in your stack. YMMV.
If the advanced stuff sounds like something you'd want/need (if you have a large project and don't mind writing to the Closure optimizations) then Closure is certainly worth looking at. It's very good at what it does.
Beats the pants of it - if you can live with the limitations.
It doesn't change string access, but it does rewrite dot access so you have to use dot access except when dealing with e.g json.
It doesn't work with the with statement, or code that is run with eval. You have to specifically export functions that should be used outside the code, otherwise they may be inlined, renamed or deleted.
Finally to get the most out of it, you have to write jsdocs for its types (at which point it can now do things like inlining functions).
There hasn't been any activity on the upstream proposal for almost a year. Has the core team rejected the idea or is there still hope it will make it into a future version?
The pipeline features of gocd seems very nice. However, last time I looked at gocd it did not support feature branches. As far as I could tell, it was not due to technical reasons but rather due to the whole feature branch vs continuous integration philosophy differences.
Any idea whether feature branch support will be added in the future?
