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?
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%.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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!
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).
52 comments
[ 2.5 ms ] story [ 53.7 ms ] threadMRI 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
At least for me 100% faster does not mean the same as 100% less time was needed.
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/...
There's a 2019 video about Artichoke: https://www.youtube.com/watch?v=QMni48MBqFw
Nothing wrong with it, really, and modern times aren't so different.
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.
- https://twitter.com/artichokeruby/status/1339581223119679493
- https://twitter.com/artichokeruby/status/1339578582222266368
- https://twitter.com/artichokeruby/status/1332772105126105089
- https://twitter.com/artichokeruby/status/1332880679655247872
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.)
0: https://shopify.engineering/shopify-webassembly
[0]: https://github.com/artichoke/artichoke/tree/97ba69d31154be45...
[1]: https://github.com/artichoke/artichoke/tree/97ba69d31154be45...
[2]: https://rocket.rs/
[0]: https://github.com/artichoke/www.artichokeruby.org/pull/171
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!
It’s gonna happen one way or another. I just want everyone to be happy and healthy.
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...
https://github.com/artichoke/artichoke/blob/trunk/VISION.md