Fresh Varnish: Varnish Cache, a popular HTTP reverse proxy, has had version 4.0 released – version 3.0 came out two and a half years ago. The new version can now cache streamed objects, refetch expired objects in the background and security has been hardened up. There’s also a new query language to help dig through Varnish’s extensive logs.
Erlang Enhanced: Version 17.0 of Erlang/OTP has been published – The new version of the languag –, renown for its support for concurrency, high availability and scalability – and its middleware libraries (the OTP) now runs on OSE, a POSIX compliant multicore real-time and fault tolerant operating system. Other changes include an experimental Maps dictionary data type, more “natural mappings” for ASN.1, new options for sockets and many enhancements to the run-time system.
Rails Renewed: The release of Rails 4.1.0 brings a new preloader, variant templates, enums for status (rather than multiple booleans) and mailer previews to the Rails framework. There’s also a useful enhancement to security in that passwords and the like are being moved out to secrets.yml. A run through of the 4.1 features give more info.
Scientific Linux 6.5: Scientific Linux has announced an update to version 6.5. SL, as it is also known, is a Linux distro based on the sources distributed by Red Hat for their Red Hat Enterprise Linux produced at Fermilab and CERN. With CentOS being brought closer into Red Hat’s ecosystem, SL may be the new barometer for the health of the Red Hat code outside the company. Anyway, the release notes mostly point you to a copy of the “Upstream Vendors” version 6.5 notes, though they aren’t on the SL servers yet. (The original notes are here).
Bootstrap 3.1: Bootstrap, the responsive mobile-first framework which also makes it easier to get a site or web application up and running, has celebrated the release of version 3.1. It comes with new documentation, an official SASS port (in a separate package), new examples and everything now under an MIT licence.
All your base methods belong to Base: It’s a sick and twisted world out there and Base is my kind of sick and twisted: there’s lots of great Ruby base classes so Base.rb includes all their methods. The best part is the license – “Distributed under the union of the terms specified by all current OSI-approved licenses. In the event of a conflict, a die is to be rolled.”
Ruby 2.1 has been released on Christmas day and is billed as offering “speedup without severe incompatibilities”. The performance boost is down to a new method cache in the VM and a new generational garbage collection system. The old method cache was cleared eacg time a new method was defined but now only that cache damage has been tracked down and reduced and a future of a more optimal larger cache has been opened up.
The generational GC was added as part of an optimisation of Ruby’s object management which also adds hooks for allocation and deallocation – there’s a deeper look into these changes in Koichi Sasada’s presentation(PDF) from RubyConf 2013. The GNU Multiple Precision Arithmetic Library is also now used to accelerate Bignum calculations.
Beyond the runtime changes, there are some language changes such as a new method for Array – to_h – to turn key/value pairs into a hash, a new syntax for rational numbers so that 1//2 is the same as Rational(1,2) and the addition of an explaining cause to Exceptions, but they seem to be few and far between. A full list is in the NEWS file which also notes any compatibility issues. Source for Ruby 2.1 is available now for download and will most probably be appearing in various binary forms over the coming weeks.
The performance improvements, although useful, will not help the perception that, outside of the CRUD web applications where Ruby and Rails made their mark, the native form of the language benchmarks as one of the slower languages out there. They will at least though help Ruby when it comes to a developer deciding which tradeoffs they want to make.
It seems to be all going on with the developers of Rubinus, the LLVM JIT-powered Ruby implementation which recently hit version 2.0.0. First came the news that Engine Yard had ended their sponsorship for the project saying that “we no longer feel like the project needs any help from us to accelerate” – the ending of sponsorship will, they say, let them invest more in other emerging projects.
With that announcement made, Rubinus lead Brian Shirai said “I have been working to simplify and focus the project”; funding changes do tend to allow projects to step back and look at their goals. In this case, the results of that work turned up in an announcement of Rubinus X.
Rubinus X is billed as an experiment in modernising Ruby, which the project’s home page declares as no longer relevant to modern computing. The plan appears to be a major reworking of Ruby – concurrency with Promises and non-blocking I/O, persistent data structures, object composition, code loading as an API, consistency through composing operations from system primitives, immutable strings and a more explicit OO model. There is also a clean up of the language planned with a single encoding used within running programs, the removal of position-significant arguments in API calls, a defined numeric tower and the purging of Perl-inspired features and global variables.
Shirai declared “Ruby is a dying language” which triggered much discussion over on sites like Hacker News about whether Ruby was dying or not and whether Node.js was the new Ruby/Rails but very little conversation on the merits of the Rubinus X plan. More details on how the Rubinus X project will develop will be disclosed in the coming days via the mailing list (which has already got 570 signups). Rubinus X does seem to have some ambitious goals and with the development taking place outside the mainstream of Ruby, it shouldn’t have an impact on Ruby development at least until it has proven itself. What affect it will have on Rubinus development is unclear though; with no one paid to develop it, resources will be tight. Definitely one to keep an eye on.
Although Ruby 2.1 hasn’t been released yet, the just release Rubinus Ruby runtime’s version 2.0 is aiming towards being Ruby 2.1 compatible. Rubinus, for those who don’t know of it, is an implementation of Ruby which uses an LLVM JIT compiler, generational garbage collector and native threads to give a Ruby runtime that can run efficiently on all CPU cores of a modern platform. The developers are also maintainers of RubySpec, a 20,000 plus strong library of specifications which map MRI (Matz’s Ruby Implementation), created to assist maintain compatibility with the ‘reference’ Ruby implementation; RubySpec is now used by many other Ruby implementations to ensure compatibility.
As the developers explain while the Ruby 2.1 MRI runtime hasn’t been released yet, they are aiming to improve compatibility with the leading edge of Ruby. This comes with a sacrifice though; historically the Rubinus developers have tried to support multiple Ruby versions and all the oddness that happens in any system where the specification is the implementation. The developers hope that this change, along with a focus on creating concurrent distributed applications, will make “Ruby competitive with Go, Erlang, Clojure, Scala and Node” in that domain. This means, they say, performance and stability of that kind of application will be prioritised over supporting some legacy Ruby code or “quirky Ruby feature”. In preparation for a more componentised Ruby, Rubinus 2.0 has isolated the standard library into a Ruby gem. There’s also a new release system for the Rubunius platform with a new versioning scheme being introduced in the transition between 2.0 and 3.0.
The developers also outline their own future thoughts and plans for Rubinus, including better (and less) concurrency coordination, less finely grained locks replacing the Ruby GIL, a more concurrent and parallel garbage collector and a more Ruby semantics informed JIT. The plans set out are focussed on making sure Ruby isn’t left behind in the new slew of languages and as the Rubinus team say “developers who are happy writing Ruby shouldn’t be forced to leave it because of technical limitations” – limitations they are setting out to remove.