Artichoke is a Ruby made with Rust that compiles to WebAssembly | Hacker News Reader

Artichoke is a Ruby made with Rust that compiles to WebAssembly

github.com

327 pointsibraheemdev49 comments

Hi folks, Artichoke author here. I mostly post project updates on Twitter. Here's a selection of some cool things I've been working on recently:

- https://twitter.com/artichokeruby/status/1339581223119679493

- https://twitter.com/artichokeruby/status/1339578582222266368

- https://twitter.com/artichokeruby/status/1332772105126105089

- https://twitter.com/artichokeruby/status/1332880679655247872

It's a great project thanks for working on it and sharing!

Thanks all for working on alternative Ruby Implementation, both Artichoke and TruffleRuby. (Edit: And also JRuby )

just curious -- is this project part of your role at stripe or just a (highly polished) side project? I know that Stripe has been investing heavily in better Ruby tooling, e.g., sorbet.

This is so awesome!

I can’t wait to try it out!

I saw it’s experimental currently, but are you planning on putting a lot of effort into it over the long haul? (I’m unsure whether I should look into it as a viable base for development.)

All the correct keywords used in the post to make it to the front page of HN.

Just missing blockchain (but in a negative light, these days).

They are the correct keywords because HN users are interested in these technologies. I don't see anything wrong with that.

Yeah, I came here thinking the same. Looks like someone made use of that HN title A/B tester posted a few weeks back, maybe. https://www.hacker-ai.com/

Nope. The title is just an accurate description of what Artichoke is. Artichoke is an implementation of Ruby made with Rust that compiles to WebAssembly.

https://prnt.sc/weiprx

All of the correct keywords and 3900 of the correct commits to ago along with them

It's almost as if a lot of HN readers are interested in Ruby, Rust, and WebAssembly...

It was a clever trick, though, to start a project using these technologies and work on it for a year, all so that somebody else could post it on HN and get those sweet sweet internet points.

There was a time when a socialite at a party, knowing their audience well, could bring a story of news having just the right delivery to engage most of the others while elevating their own status within the group.

Nothing wrong with it, really, and modern times aren't so different.

I used to think like you too, but then I looked at the Best of HN for 2020 post https://hn.algolia.com/?dateEnd=1609415804&dateRange=custom&... and I realized there was no Rust or Webassembly or even Ruby or artichokes mentioned there.

I for one am tired of HN constantly upvoting vegetable related posts. Give it a rest folks.

Imagine 100 years ago on a forum on stage coaches, and automobiles keep getting posted. Yes Rust is the cool new thing, but I don’t see it as a fad. In fact, I see Rust turning into a best practice for our industry unless something like it but easier takes its place

I see managed languages adopting linear and affine types for certain types of high performance workflows.

Already visible in Swift, Haskell, Chapel, ParaSail, D.

Likewise I see Microsoft and Google, will keep their lifetimes efforts going until it offers a good enough experience, even if not perfect, in spite of their ramping up use of Rust.

A good example of this is the Azure Sphere, which inspite of the security marketing story the team tells everywhere with the 7 levels and such, it uses a C based SDK.

Bingo, sir. https://dilbert.com/strip/1994-02-22

The use of traits here is really cool. It looks like the entire language implementation is defined as a trait, which allows for language backends to be swapped out while maintaining the same outward API.

Thanks for catching this. That is spot on. These APIs in the `Symbol` backend [0] show this concept off really well I think.

The `Symbol` data structure knows how to, e.g. render its `Symbol#inspect` implementation [1]. To extract the underlying bytes associated with the `Symbol`, however, it needs an interpreter. But not a whole interpreter or any particular interpreter, just one that implements `Intern` [2].

All of these generics get monomorphized so there are no vtables or other indirection. Because it's unlikely you'll have more than one interpreter implementation in your program, there is no code bloat either.

[0]: https://github.com/artichoke/artichoke/blob/2d67d8537c1340f1...

[1]: https://artichoke.github.io/artichoke/spinoso_symbol/struct....

[2]: https://artichoke.github.io/artichoke/artichoke_core/intern/...

What makes Artichoke more suitable than MRI for compilation to WebAssembly (and for embedding, and for single-binary distribution [0])?

Is it just that Artichoke is written in Rust? Or does it make different trade-offs in its design?

[0] https://github.com/artichoke/artichoke/blob/2d67d8537c1340f1...

This is awesome! When the WASM effort was first announced many years ago I happened to be steeped in a ton of ruby work (the ruby/coffeescript era) and had fantasized about the far future when something like this might be a reality... and here it is!

These days I don't use ruby much at all, and I use groovy where I might have used ruby (because static types), but I still love the language and admire this effort. Awesome!

Artichoke is interesting, but it's still really young and doesn't have a lot of compatibility with MRuby yet: https://eregon.me/blog/2020/06/27/ruby-spec-compatibility-re... I don't know of any reason it can't grow to be much more compatible.

There's a 2019 video about Artichoke: https://www.youtube.com/watch?v=QMni48MBqFw

Vision document here that outlines objectives in detail.

https://github.com/artichoke/artichoke/blob/trunk/VISION.md

Here's a permalink: https://github.com/artichoke/artichoke/blob/939fffc015255736...

Is there a timeline as to when artichoke will be stable enough to say... run a Rails app? Or is that not a goal of this project?

Same question here.

Out of curiosity, why would you want to do that? Rails just doesn't seem like it makes much sense in the context of WASM. I know you can run WASM outside of the browser but you can run any other ruby outside of the browser, so you wouldn't need artichoke.

I think it's more of a question of how far along is the project, and is bug-for-bug compatibility a goal or not.

There are probably a lot of benefits to be gained from Rails on Wasm. For example, Shopify recently posted an article about how they use Wasm outside of the browser to execute untrusted code (user scripts) [0]. It is also worth mentioning that although Artichoke supports WebAssembly as a build target, compiling to Wasm is not the only way to execute an Artichoke program.

0: https://shopify.engineering/shopify-webassembly

You might be interested in this early work to build a Sinatra echo server [0] with Artichoke (called ferrocarril back then). `hubris` used a custom Rack-compatible web server called `nemesis` [1] based on Rocket [2], a Rust Flask-like web framework.

[0]: https://github.com/artichoke/artichoke/tree/97ba69d31154be45...

[1]: https://github.com/artichoke/artichoke/tree/97ba69d31154be45...

[2]: https://rocket.rs/

Are there any performance benefits over MRI?

The talk at rubyconf mentioned that `string.scan` was 100% faster due to specialized string implementations in the Rust backend. I wonder if there are any performance gains from the actual runtime rather than from std optimizations?

100% faster? Does that mean twice as fast or is string.scan now take 0 time?

100% faster means speed is increased by 100%, i.e. double the speed or half the time.

MRI took 89ms/iter to scan for a regex pattern over 6.8MB of text, while Artichoke took 48ms/iter [0]

0: https://youtu.be/QMni48MBqFw?t=1378

That is misleading, in my opinion. "100% faster" implies that runtime for a given workload is reduced by 100%, taking zero time. I think what you mean to say is either that it's 50% faster or that throughput is increased by 100%.

Surely faster means higher speed, and speed is something per time unit, e.g. miles per hour, or number of scans per second.

At least for me 100% faster does not mean the same as 100% less time was needed.

I don't think it runs Optcarrot (the current most prominent Ruby benchmark) otherwise it'd be listed here https://github.com/mame/optcarrot. It doesn't have a lot of compatibility with standard Ruby yet according to https://eregon.me/blog/2020/06/27/ruby-spec-compatibility-re... which could be why it doesn't run it. But it's a really exciting project!

Not sure how far off this is, practically speaking, but "true parallelism with no GIL" would be a pretty damn significant perf achievement.

This is amazing! I'd love to see some benchmarks of Artichoke vs Ruby for macOS Homebrew workloads (its mostly the only time the Ruby executable is invoked on my system).

I’m trying to learn more about “artichoke” from their website but the hamburger menu won’t work on my iPhone safari. Pls fix!

Fixed [0]. Thanks for the report. The navbar could still use a bit of love though :(.

[0]: https://github.com/artichoke/www.artichokeruby.org/pull/171

Thank you!

Peak HN

JavaScript developers seek their Scala and Kotlin, I suppose. Trying to stop this is like trying to stop your young son/daughter from finding romance.

It’s gonna happen one way or another. I just want everyone to be happy and healthy.

Reply on news.ycombinator.com