Helix: Rust and Ruby, Without the Glue (opens in new tab)

There's a _lot_ of stuff in this space: mrusty, ruru, Helix. It's exciting stuff.

If Ruby is anything like Python, nonlocal name lookups in loops can indeed be performance bottlenecks.

Ruby’s set class is implemented in Ruby wrapping a Hash (`{ key => true }`), not in C (or Java or…). It’s fairly good when you’re testing for containment, but the implementation is probably going to be as bad or worse for the #fully_contains behaviour…except the requirement that Zesty’s arrays be sorted.

Conceptually, a Set will do much better even with this sort of optimization.

The Rust version does a type coercion from Ruby VALUE to Rust String. The type coercions are defined generically using Rust traits (see the Helix README) so once somebody defines RubyString -> String once everyone benefits.

In this case, the coercion needs to ask Ruby for the encoding tag and ask Ruby to validate the encoding (which is does often enough that it's often cached) but after that we can safely coerce directly into a UTF8 string.

If we wanted to support other encodings, we could fall back to using Ruby's transcoding support (string.encode("UTF8")) and again, once someone does the work once it'll work for all helix users.

Akira Matsuda actually suggested at RailsConf that maybe Rails handling non-UTF-8 encodings was not necessary, and maybe phasing it out was a good idea.

I wasn't present for the talk, just saw his slides.

The Rust version works on strings not on bytes. Strings don't have encodings.

I think this is a GREAT thing for other implementations like JRuby. Rusty Ruby would be able to learn from some of the implementation tricks that impls like Jruby and rbx have learned along the way, and maybe those guys will learn something from the Rusty Ruby crew along the way also.

Rust as far I know (not at all, honestly) doesn't interface with Java that well, so for JVM projects, it's nice to have a familiar language like Ruby that can tie in and make prototyping way easier.

I think people misunderstand how awesome Jruby is, because Ruby has never performed that well and Jruby has performed very well. Performance is not the only reason to both implementing a language. There's also the issue of mindshare, where a large group of people might already know Ruby, and it'd be easier in those scenarios to just give them Jruby and let them go to town than try and drag them through learning Java.

Rusty Ruby will do the same thing for Rust, I think. Rust is a very intricate, well-thought-out language, and I think it would benefit a lot from playing off the shared knowledge of thousands of Ruby users.

I am not super specifically knowledgeable about these details, but Rubygems lets you upload binaries to make this not needed generaly.

The amount of name reuse in software in recent years really frustrates. It makes it so much harder to find the information you are looking for.

Besides that I really don't get why perforce are renaming their version control system yo Helix. Perforce is a well-known name, it seems weird to just drop a strong brand.

For something that is in memory and throw-away, why go through a DB?

:) I wish I understood this jab. Can you explain me.

I like apples. Oranges look weird.

Ruby is phenomenally easy to write. This post essentially describes a way to make Ruby less slow, which would reduce the incentive to leave the language.

Once they port all Rails libraries to Rust, you can still use the extremely-ergonomic Ruby programming language, but it won't be "slow as hell" anymore. And ruby performance is "tolerable in most circumstances" as-is.

I certainly agree that it could be awesome to have Rust on Rails for those who would find even Rails on Rust performance intolerable, and Iron's abstractions inadequate.

I find a great answer in this area is Crystal. I consider it 'go in ruby clothing'. Like go, Crystal is a typed language and outputs binary executables. They kept the beautiful ruby syntax and made better internals. http://crystal-lang.org/

Plenty of gems use native C to provide best possible performance. This doesn't mean everyone is planning to rewrite their Ruby applications in C.

Rust provides a safer option - which is worthwhile. There have been several examples of gems with memory issues. It doesn't change anything, unless this is a general "Ruby is too slow" sort of rant.

It does no such thing as make me wonder why I'm using Ruby. I can and do write Rust, and I enjoy doing so. But I write Ruby more quickly and can more effectively build tools for both my own consumption and that of others, using techniques that I can't use in Rust. Being able to use Rust or something that isn't an unpleasant minefield (lookin' at you, C) where I need it for performance is extremely valuable, but there's no reason to throw out the beneficial, powerful aspects of Ruby to do it.

How many platforms and frameworks have been completely ported over to a better language? There are many languages that have arguably succeeded PHP, and yet WordPress and Facebook remain on PHP, which would belie your assumption that "it may not take that much effort to [re]create [some framework] and get rid of [that framework's original language]"