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

61–69 of 69 posts

Re: Helix: Rust and Ruby, Without the Glue

#61

Post by x5n1 »

aidenn0 wrote: post #20
MichaelGG wrote: post #16

Earlier quoted context omitted.

Right, so how do you get from Ruby strings (various encodings) to a Rust string? The sample code just calls std::str::from_utf8_unchecked(s) which is obviously not dealing with Ruby encodings.

Yeah, that's a clear bug. I was not aware that Ruby strings had encodings.

All strings have encodings. It is not possible to represent a string which is a series of bytes except with encodings. I guess you probably mean default encoding or no encoding support... which implies ASCII, better known as US-ASCII.

Re: Helix: Rust and Ruby, Without the Glue

#62

Post by poizan42 »

solipsism wrote: post #36

Helix is the name Perforce is using to rebrand their set of tools. Just an FYI, I'm not saying that means this should not be called Helix.

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.

Re: Helix: Rust and Ruby, Without the Glue

#63

Post by xuejie »

eropple wrote: post #57
steveklabnik wrote: post #33

Earlier quoted context omitted.

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

mrusty is super cool . My only beefs with it are around the difficulties of mruby (package availability, 1.9.3 limitations, generally being "off the beaten path"), not of mrusty itself, but it's such a fantastic way to quickly build a scripting layer that I fell in love with it almost immediately. I would pay a decent chunk of money for a cleanly integrated MRI implementation inside of Rust, but I also will not be ho…

Just out of curiosity: what limitations of Ruby 1.9.3 is critical in your case?

Not to start a flame war, but according to my experience, Ruby 1.9 is already quite good, later versions of Ruby only introduce minor syntax & semantic changes, which is trivial to work around. This is nothing like the big differences between 1.8 and 1.9

I agree with package availability problem of mruby, tho.

Re: Helix: Rust and Ruby, Without the Glue

#64

Post by tmikaeld »

tmikaeld wrote: post #41
donpdonp wrote: post #35

Earlier quoted context omitted.

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.

Why downvote this and not comment as to why?

It's their own words.

Re: Helix: Rust and Ruby, Without the Glue

#65

Post by placeybordeaux »

drewbug wrote: post #42
placeybordeaux wrote: post #40

Earlier quoted context omitted.

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

Sometimes, it'll be faster.

Unless you specify some asymmetry it will always be faster to do it locally.

Re: Helix: Rust and Ruby, Without the Glue

#66

Post by aidenn0 »

x5n1 wrote: post #61
aidenn0 wrote: post #20

Earlier quoted context omitted.

Yeah, that's a clear bug. I was not aware that Ruby strings had encodings.

All strings have encodings. It is not possible to represent a string which is a series of bytes except with encodings. I guess you probably mean default encoding or no encoding support... which implies ASCII, better known as US-ASCII.

In the high-level language I am most familiar with (Common Lisp), strings do not have encodings because they are vectors of characters, not vectors of bytes. How the string is actually stored in memory is an implementation detail.

Encoding is purely an artifact of I/O if your language has a character type that can represent all possible characters you might want read or write.

Rust's strings are almost this; if there were no way to get a string's raw representation, nor perform bytewise slices, then how the string was stored in RAM would be an implementation detail rather than part of the public API. Rust, being a systems language, probably does need to specify this so that it doesn't incur encode/decode overhead when dealing with foreign code that can understand utf-8.

Re: Helix: Rust and Ruby, Without the Glue

#67

Post by eropple »

xuejie wrote: post #63
eropple wrote: post #57

Earlier quoted context omitted.

mrusty is super cool . My only beefs with it are around the difficulties of mruby (package availability, 1.9.3 limitations, generally being "off the beaten path"), not of mrusty itself, but it's such a fantastic way to quickly build a scripting layer that I fell in love with it almost immediately. I would pay a decent chunk of money for a cleanly integrated MRI implementation inside of Rust, but I also will not be ho…

Just out of curiosity: what limitations of Ruby 1.9.3 is critical in your case? Not to start a flame war, but according to my experience, Ruby 1.9 is already quite good, later versions of Ruby only introduce minor syntax & semantic changes, which is trivial to work around. This is nothing like the big differences between 1.8 and 1.9 I agree with package availability problem of mruby, tho.

Nothing is critical, I'm just so used to writing Ruby 2.3 at this point that 1.9 isn't as enjoyable. I wish it were better, I'm not saying it's bad.

Re: Helix: Rust and Ruby, Without the Glue

#69

Post by steveklabnik »

carlosft wrote: post #68

What are the dependencies for installing the gem? I assume the machine will need rustc/cargo to compile the gem.

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