Rust has no its ecosystem, just pyramid selling. Swift will beat it!
Helix: Rust and Ruby, Without the Glue
51–60 of 69 posts
Re: Helix: Rust and Ruby, Without the Glue
#52Rust has no its ecosystem, just pyramid selling. Swift will beat it!
:) I wish I understood this jab. Can you explain me.
Re: Helix: Rust and Ruby, Without the Glue
#53So it is Rusted Rails? XD
Anyway I think the same could be applied to Ruby Core as well. As I have been calling a Rusted Ruby for a long time.
Though I am not sure if this is a good thing for other Ruby implementation like JRuby.
Re: Helix: Rust and Ruby, Without the Glue
#54Earlier quoted context omitted.
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 inte…
Well, it's hard to say, really. It depends on what you're doing. The benefit of converting to UTF-8 when making a string from bytes is that string operations have predictable performance, and strings have predictable memory-usage. But of course, you then have to pay the cost of converting to UTF-8.
On the other hand, if you just track the encoding in your string type, then you don't have to pay a conversion cost at the boundary, but each encoding will have different memory-usage and performance characteristics.
Re: Helix: Rust and Ruby, Without the Glue
#55So it is Rusted Rails? XD Anyway I think the same could be applied to Ruby Core as well. As I have been calling a Rusted Ruby for a long time. Though I am not sure if this is a good thing for other Ruby implementation like JRuby.
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.
Re: Helix: Rust and Ruby, Without the Glue
#56Hmm. 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.
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.
Re: Helix: Rust and Ruby, Without the Glue
#57Very excited to see the development of the Ruby/Rust space. The two languages together would seem a joy of a workflow from concept through to maintenance, and the wealth of important Ruby personalities currently involved in Rust (as well as others) encourages that that this will be a well trodden and well documented workflow sooner rather than later. I think this could help Ruby regain some of its early excitement, a…
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 holding my breath for it.
Re: Helix: Rust and Ruby, Without the Glue
#58Earlier quoted context omitted.
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.
He was talking about the view layer, that's true. Even then though, your source is likely to be in UTF-8, and Rails' form helpers add
Re: Helix: Rust and Ruby, Without the Glue
#59Earlier quoted context omitted.
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.
Exactly, I dont mean to beat a dead horse, but most bog standard web apps have the quoted items in a db anyway, and these are very common problems.
For example if we have a few tables we can determine which menu items a user could eat:
users
user_ingredient_exclusions
ingredients
menu_ingredients
menu
-- items a user can eat based on not having any items in the excluded list
select distinct m.*
from menu m
inner join menu_ingredients mi on m.id = mi.menu_id
left join user_ingredient_exclusions e on e.ingredient_id = mi.ingredient_id
inner join user u on u.id = e.user_id
where e.id is null
and u.id = @idRe: Helix: Rust and Ruby, Without the Glue
#60This is fucking cool. You have convinced me to pick up Rust.