Since I’m co-organizing the Rhein-Main Rust meetup (and am probably the main driving force behind it), I tought, it might be useful to share a few ideas we have that we have either already done, or plan doing – perhaps other meetup organizers can benefit from this. Note that our meetups usually run 2-4 hours, but some attendees may have to join late or leave early so the format has to take this into account.
Initiatives in the Rust community.
I’m at a fork again: my FOSS project responsibilities have grown so much that they encroach on other parts of my life. This includes time I should spend with company, clients and personal live. It leaves me with two options: shed many of my projects (as mxsash does) or find ways of making this more sustainable. Retreating would also mean that on the surviving projects, others would have to cover the resulting gap, often with less skills or experience.
I wanted to take a very quick peak at Rust. It's very different from our previous cases, no application or frameworks in the traditional sense but a language. It seems very popular toward developers using it, I'm personally interested in it hence why it is in that post.
This year's class of Increasing Rust's Reach participants span 9 timezones and 11 countries. 64% are non-native English speakers, and the group, as a whole, represents fluency in 14+ languages. We're super excited to welcome them to the Rust community!
In this this post in the listening and trust series, I’m going to talk through one of the most intense discussions the Rust community has had: the module system changes that were part of last year’s ergonomics initiative.
There were some heated discussions in Rust community as of late. During that discussions, I argued that some best practices for RFC authors would improve both on the results as well as the discussions and I promised to give it a try.
This page is a first attempt at facilitating sponsorship. This is not an officially endorsed list, but it is a list of Rustaceans that I have personally vetted and sponsored, and encourage you to support. Each of them has a long, public history of impactful work in the community.
In the previous post in this series, I recounted an early lesson for the Rust Core Team about working in the open. In this post, I want to talk about the delicate interplay between listening and trust when doing design in the open.
With #RustReach starting soon I have ran into a few "My Rust Story" posts. My path to Rust certainly is not typical (I studied HR Management in undergrad…).
The journey really started for me back in middle/high school as I was very interested in video games, computers, and how things worked. So with a few friends started a computer repair "business" that serviced the local (Western Pennsylvania) area. By the time my sophomore year of highschool rolled around we had lined up a few of the parents who owned local businesses/churches and were doing some pretty serious consulting/maintenance for our ages (also installing Halo and Half-life 2: Deathmatch on the school's servers...).
For me, most weeks working on Rust are fun — exhilarating, even. But, just like with anything else, some weeks are hard.
As this week draws to a close, I feel troubled. On the one hand, things are looking strong for the 2018 Edition (which I want to write more about soon). But on the other hand, this week I locked two RFC threads, flagged a bunch of comments for moderation, and generally absorbed a lot of emotion from a lot of different quarters of the community. There’s a sense of simmering distrust.
Ownership is a fundamental piece of Rust’s story. It amounts to a tight set of rules about who owns a value in a program, how that value can be aliased and mutated, and when that value is dropped. It prevents shared mutable state, which is the root cause of major bugs in software written without the same guarantees.
In this post I’d like to talk about a different kind ownership in though. I’d like to talk about ownership of libraries in the Rust ecosystem and the problem of sustainable maintainership.
There’s currently a campaign around the #RustReach program where it’s people post their, uh, Rust “origin stories”, so to say. Mine is not nearly as long as some other peoples’, but I thought I’d try my hand at this regardless.
The #rustreach project is apparently asking people how they got into Rust, and though I wasn’t asked in person, I thought it may be useful to write down my personal Rust story. Here goes nothing.
I first heard about Outreachy from my coach last year when I was applying for Rails Girls Summer of Code (RGSoC). Although we didn’t make through RGSoC at that time, I learned a lot about how Open Source works; whether it was about learning intricacies of Git, building patience to figure out a bug among thousands of lines of code, or becoming a programmer with better problem-solving and communication skills.
The “Increasing Rust’s Reach” projects are kicking off! With it, the Community Team is asking for people to describe how they contribute to Rust, to demonstrate the breadth of talent and perspective in the community. So here’s my personal Rust story!
I have the great pleasure and privilege this year to be one of the mentors for Increasing Rust's Reach. I'll be working with Sarah and nano on WebAssembly and I'm really excited to see what we accomplish over the next few months. Even after our first meeting I just know they're gonna do some great things. Over the coming months I'll be documenting their progress, but to kick things off the Rust Community team is asking people to describe their story and how they contribute to Rust, to show off the variety and breadth of our experiences and talent in a wide variety of areas. This is my story.
Well in Rust, there are certain safety guarantees… yes, you know, the typical spiel. That may have been enough to interest me in rust, but it was not the reason I decided to stick with it — ultimately what drew me in was the community.
Hacking on gnome-class continues apace! Philippe updated our dependencies. Alberto made the syntax for per-instance private structsmore ergonomic, and then made that code nice and compact. Martin improved our conversion from CamelCase to snake_case for code generation. Daniel added initial support for GObject properties. This is not finished...;
Last week was the third edition of the Rust+GNOME hackfest. What about talking a bit about what we achieved? The goals of this edition were: Improve gnome-class, improve gtk-rs continuous integration process, improve gtk-rs crates bindings. I'm happy to say that we were able to achieve all of these goals!
I'm in Madrid since Monday, at the third GNOME+Rust hackfest! The OpenShine folks are kindly letting us use their offices, on the seventh floor of a building by the Cuatro Caminos roundabout.
I am very, very thankful that this time everyone seems to be working on developing gnome-class. It's a difficult project for me, and more brainpower is definitely welcome — all the indirection, type conversion, GObject obscurity, and procedural macro shenanigans definitely take a toll on oneself.
The Rust team is happy to announce that we’re running our Increasing Rust’s Reach program again this year. Increasing Rust’s Reach is one of several programs run by the project to grow Rust’s community of project collaborators and leaders.