Hacker News Reader

Comment by kibwen | Hacker News Reader

I'm pleasantly surprised! They took the route of "promising but underdeveloped technology" rather than settling for a well-developed solution that compromises their principles (which, frankly, I wouldn't have faulted them for; at the end of the day you still have to get work done). With luck maybe we'll see Mozilla contribute to Matrix? There is, after all, an implementation written in Rust: https://github.com/ruma

View on HN

The last ruma commit was in August, which was after a long period where nothing happened at all. Is the project dead?

The latest status seems to be https://github.com/ruma/ruma/issues/189#issuecomment-5539555... from a month ago. It looks like he is working on the client while he waits for Rust web server frameworks to adopt the recently-released async-await language features.

edit: https://www.ruma.io/status/ is a better overview

The author says they’re waiting on Rust and Matrix features/documentation. There’s an open issue with more details

https://github.com/ruma/ruma/issues/189

I actually interviewed the author in August for our Rust podcast, on which he says he's waiting for async to mature before progressing further: https://rustacean-station.org/episode/001-ruma/

I love the name of your podcast.

Thanks! Also, while we're here, let me advertise that this is not just "my" podcast, it's a community-based podcast that accepts audio files from anyone who wants to make any Rust-related podcast content but who doesn't want to go through the trouble of setting up a website, file hosting solution, podcast index integration, and so on. Contributions accepted. :) https://github.com/rustacean-station/rustacean-station.org/

What a cool concept. Have you had many episodes contributed so far?

Of our seven episodes only one hasn't been a product of me or Jon: an interview with Armin Ronacher about using Rust in production (https://rustacean-station.org/episode/004-rust-in-production...). Though we're about to publish our second externally-produced episode tonight, an interview with the creator of static site generator named Zola (née Gutenberg).

Plenty of people say tell us they're going to contribute, but you know how life gets in the way. :) We're not bothered by having a low-volume or irregular release schedule, this is just a fun side project for us.

They just put up a blog post going over their progress https://www.ruma.io/news/these-weeks-in-ruma-2019-12-14/

No, the last commit was two days ago: https://github.com/ruma/ruma-events/commit/c7d7212b000e324b9...

It is a bit hard to follow their project since they have split it up in so many tiny repos. I personally prefer when a set of closely related crates are developed in one mono repo.

For rust it's sometimes useful to split it like that, because it makes it easy to publish small subsets of your project on cargo. Say you develop a custom datastructure, or an extension on Streams.

The same applies to other languages to some degree, but crates/cargo just makes it very painless to grab crates that are on a seperate git.

But Cargo supports having multiple crates in the same git repo. Many projects do this like regex (regex and regex-syntax are in the same repo) and openssl (openssl, openssl-sys, openssl-errors). Maybe I am missing something but it seems very easy to handle multiple closely related crates in the same repo.

What makes this possible is Cargo's "workspace" feature, which is relatively new enough that it's not hard to imagine that some older projects may simply predate it.

Would something like git subtree help here? Allow people to continue working with their individual repos but present a unified view for outsiders to follow along? We could automate this, right?

Hm, I have been doing this just fine without using the workspaces. What am I missing?

Cargo workspaces are more of an optimization in that they let all the crates in your project share the same output directory[0], so built dependencies can be shared among every crate, as opposed to each crate needing to (re)build all of its dependencies independently.

This helps to reduce compile times when working on projects where you frequently switch between crates.

[0] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html

Oh indeed, thanks for pointing out! Wishing them luck then.

Reply on news.ycombinator.com