Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Helix: Rust and Ruby, Without the Glue

blog.skylight.io

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Helix: Rust and Ruby, Without the Glue

#41

Post by tmikaeld »

donpdonp wrote: post #35
pzh wrote: post #19

Hmm. Kind of makes you wonder why you're using Ruby at all, which is slow as hell. It appears that once they port all Rails libraries to Rust, it may not take that much effort to create Rust on Rails and get rid of Ruby.

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/

I believe it is weakly typed, so type-checked on compile time.

Re: Helix: Rust and Ruby, Without the Glue

#42

Post by drewbug »

placeybordeaux wrote: post #40
hobs wrote: post #24

Earlier quoted context omitted.

I was taking the point of "Why is the problem taking so long when it seems like a simple thing to calculate?" which was a little orthonogal from theme of the total post, so I can see why there would be some confusion. The article talked about 30 minutes to run through a "is this set of items in this other set of a bunch of items". While it would probably make sense to do this efficiently in memory the reality is the…

Why hit the network/a central resource when you could just do it locally?

Sometimes, it'll be faster.

Re: Helix: Rust and Ruby, Without the Glue

#44

Post by twelvechairs »

kibwen wrote: post #37
twelvechairs wrote: post #29

Earlier quoted context omitted.

Its a better way of doing things - you can handle things in their native format rather than have to arbitrarily convert to UTF8 (which is an 'encoding' itself). [edit] I remember a talk where Matz was asked this specific question and tried to explain it clearly but seemed confused as to how the questioner could have such a poor grasp of unicode (the difference between monolingual americans and japanese i guess)

String is just a typedef for Vec with some extra convenience functions for working with UTF-8. There's nothing stopping anyone from just using Vec to handle non-UTF-8 data in their native format, nor stopping anyone from writing convenience types like String for other encodings.

Yeah right so Ruby effectively has just made a bunch of these (and done the hard work for you of defining how to convert between them and work with them all in similar ways), and the higher-level class which includes UTF8 and a whole bunch of others is called 'String'. Its really what you want from a high-level language - to just work with different encodings out of the box, but not have to convert to a standard interal type (like UTF8) to do so.

Re: Helix: Rust and Ruby, Without the Glue

#45

Post by GolDDranks »

aidenn0 wrote: post #27
MichaelGG wrote: post #21

Earlier quoted context omitted.

Ruby's Japanese heritage is probably why it handles encodings like that - I think there were multiple encs it had to deal with at once or something. Also Unicode doesn't completely handle all kanji in that there's some that have an old style not available in Unicode. But maybe that's not relevant.

Unicode now handles all the Kanji in JIS. I wouldn't be surprised if Ruby predated that. It almost certainly predates good library support for all the Kanji in JIS.

I think the problem isn't whether it handles all the Kanji in JIS – it does. But the problem is that JIS at the time was so common that it didn't necessarily make sense to settle exclusively for then-less-used UTF-8. That would make re-encodings necessary at interfaces and on IO.

Re: Helix: Rust and Ruby, Without the Glue

#46

Post by fouc »

Great blog post.. First time I've been sold on Rust, sounds like it's got some great features. Maybe I just had to hear about it from a Ruby dev. :)

Typos in the article: "slimed down", "you code could"

Is "needle_length = needle.length" actually necessary? I thought repeated calls would be zero cost, but I'm guessing I'm wrong.

Re: Helix: Rust and Ruby, Without the Glue

#47

Post by fouc »

placeybordeaux wrote: post #40
hobs wrote: post #24

Earlier quoted context omitted.

I was taking the point of "Why is the problem taking so long when it seems like a simple thing to calculate?" which was a little orthonogal from theme of the total post, so I can see why there would be some confusion. The article talked about 30 minutes to run through a "is this set of items in this other set of a bunch of items". While it would probably make sense to do this efficiently in memory the reality is the…

Why hit the network/a central resource when you could just do it locally?

It's a webapp, they're likely already querying all the meal information from a mysql or postgresql db. Chances are they could have made a change to their db models and written some sql to handle food requirements checking instead of handling it after the query. But that could've been premature optimization ultimately, and to speed it up now, it's probably easier to optimize the slow ruby code with some rust instead.

Re: Helix: Rust and Ruby, Without the Glue

#48

Post by brightball »

rattray wrote: post #23
pzh wrote: post #19

Hmm. Kind of makes you wonder why you're using Ruby at all, which is slow as hell. It appears that once they port all Rails libraries to Rust, it may not take that much effort to create Rust on Rails and get rid of Ruby.

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 ha…

This is the exact reason I'm headlong into Elixir and Phoenix right now. It's like the best of both worlds.

Re: Helix: Rust and Ruby, Without the Glue

#49

Post by kibwen »

fouc wrote: post #46

Great blog post.. First time I've been sold on Rust, sounds like it's got some great features. Maybe I just had to hear about it from a Ruby dev. :) Typos in the article: "slimed down", "you code could" Is "needle_length = needle.length" actually necessary? I thought repeated calls would be zero cost, but I'm guessing I'm wrong.

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

Re: Helix: Rust and Ruby, Without the Glue

#50

Post by nateberkopec »

steveklabnik wrote: post #34
MichaelGG wrote: post #4

But the Rust version of the blank check doesn't handle any encoding but UTF-8. Helix could wrap up a char iterator for it I suppose, one that calls rb_enc_codepoint_len? And isn't there some common C lib that exposes Unicode functions like is_whitespace? Granted, using a cargo crate is easier than finding and adding a .h, and far easier than getting and linking another lib.

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.

Akira was talking about a specific context - view rendering. Which makes sense, who the hell ever renders a view in anything other than UTF-8?

Checking input, however, is a whole 'nother ballgame.

Post reply on HN