User:QEDK/GSoC 2020/An overview and an addendum on Rust

So let’s walk you through what my project is about and on the outset, it’s pretty intuitive. At the time of application, the feature list was tightly-focused and was a solid start for implementation: "Welcome new members and share with them kick-start resources related to Wikimedia Outreach projects. Provide help around FAQs (for example by using the following syntax: +search-faqs: ), so we don’t wait for a human (waste of time) and also avoid repeating answers. Direct channel members to the relevant members and/or relevant streams/topics. Bridge communication between a Zulip stream, say ‘Technical Support’ and the IRC channel #wikimedia-tech."

A segue on Discord
If you’ve stumbled across a popular server in Discord (ever!), you’ve definitely encountered very featureful bots, some might even say too many features. So, you already have a good idea in your head what the bot is supposed to do — welcome people, give them resources, point them to places and maybe even play a game of tic-tac-toe (on that note: there’s a great fishing bot).

The case for Zulip
Discord has been around for a while and despite being proprietary, their API has matured over time. Working with Zulip meant dealing with a fairly nascent API but given the fact that everything is open-source, I can tailor what I create instead of simply being dependent on an opaque API. To drop a hint, since I know that the zulip package is going to use configparser to parse the configuration files, I can include other configurations into the same file to save setup time and effort, I let the package deal with the portion of the file they require and I can deal with the configuration I need as well. Being open-source has a distinct advantage in that I don’t have to be sure that the docs are up-to-date, I can see the behaviours of the current production API as they are meant to be given, absolute clarity regarding input and output and that’s crucial when developing any new application. That’s enough with me talking about open-source, let’s circle back to the project I am working on and the current feature list as it stands, heavily truncated for ease of reading — ''Always listening

This means that the bot can be summoned from anywhere with any message we want to summon it with.

Welcoming

The #announce stream announces all new signups, each signup will trigger a bot action from goodbot on the #general stream (Getting started topic)…

Replying and error control

If summoning the bot, the bot will helpfully give a list of commands and expect you to answer them…

Organization-level assistance

The bot will seek to assist applicants about respective project ideas, guide them to instructions and org-admins…

Project-level assistance

The bot will seek to assist them with specific projects by directing them to respective mentors, Phab tasks, and instructions about that particular project by dynamically accessing continually-updated resources…

Technical assistance

The bot will direct participants to technical IRC channels such as #wikimedia-tech, #pywikibot, and other technical channels (with configurable options) when requested…

Zulip-IRC bridgebot

The bot will also sync messages across a specific stream such as #technical-support stream on Zulipchat and Wikimedia technical IRC channels such as #wikimedia-tech to ensure proper and quick resolution of queries…

Summoning user-groups

The bot will maintain its own database of user_groups, such as mentors for specific projects, GSoC/GSoD/Outreachy org-admins. The bot will provide resources to contact these user-groups as well as the ability to send pings via Zulipchat itself…

CI/CD

We will use Travis CI for continuous integration, build verification and continuous deployment…

Toolforge deployment and integration

The entire pipeline of integration and deployment to Toolforge will be triggered by an event (either through Travis CI or GitHub Actions) carried out after the commit is pushed to production and results in a successful build…

Searching Wikipedia and StackOverflow

Both sites have strong, mature APIs and will be a very useful resource without needing to leave Zulipchat, also helpful in answering queries by mentors on why certain errors are occurring…

Code quality

Extension documentation is always a prerequisite for maintaining code quality presently and in the future. Hence, I have provided ample time for documentation purposes, which we can host on GitHub wiki itself. Another aspect of maintaining code quality is to enforce a consistent style guide and ensure the absence of logical and syntactical errors in our project using a linter — preferably such as flake8, primarily for its speed and the lack of false-positives. Linting will be automatically enforced in continuous integration via Travis-CI…'' This should establish an opening idea into what I’ll be working on this summer, and finally, some proof of the pudding — A simple demo of our Zulip-IRC bridgebot // Standard YouTube License © Ankit Maity I’ll be talking more about what we’re working on over the summers in the coming posts (including one more demo video) but that’s it for today. Now, let’s talk about — and you guessed it, Rust.

The addendum on Rust
StackOverflow has been a better part of my college years and maybe for some of you too, with that you probably come across the StackOverflow Developer Survey and if you’ve kept track of the results, there’s one interesting fact that stands out — Rust has been the most-loved language for five years straight. Five years, in an ever-changing and continuously innovating developer community, seems novel to me. In fact, when most of the languages we use today are decades old, it seems that Rust has made a solid foothold in the community.

And the obvious question is — why?

How does this code look to you? Pretty and elegant, or completely unreadable? Depending on the answer, you might like or not like Rust, and in this one line, we see how iterators (a primary Rust abstraction) can be used to create a vector containing the first ten square numbers.

To quote Jake Goulding of Integer32 (you can read his full blog here)— Rust’s static typing does its best to get out of the programmer’s way while encouraging long-term maintainability. Some statically-typed languages place a large burden on the programmer, requiring them to repeat the type of a variable multiple times, which hinders readability and refactoring. Other statically-typed languages allow whole-program type inference. While convenient during initial development, this reduces the ability of the compiler to provide useful error information when types no longer match.

As someone who has started learning Rust, I can clearly attest, the learning curve is quite off-putting; but unexpectedly, it is the fresh breath of air I seem to have been waiting for. I still love Python and C++ (do take a guess which one is objectively better) from the bottom of my heart — but Rust offers an opportunity at something much better and that’s to become a language that you want to write code in — and one I certainly hope Rust achieves.

That’s all, folks! Drop by in the comments if you have anything to add. Next time, more about our project and more about Rust. 😊
 * Want to be a new developer? See https://www.mediawiki.org/wiki/New_Developers
 * Want to learn more about Google Season of Docs 2020? See https://developers.google.com/season-of-docs
 * Want to interact with people of the Wikimedia Outreach community? Come visit us at Zulipchat.
 * Want to begin learning Rust? Read The Book.


 * Set up Toolforge.
 * Migrate CI/CD and dependency management back to Python 3.7.3.
 * Document the lack of runtime support and solutions in GitHub docs.
 * Set up Kubernetes pods.
 * Format everything and switch to f-strings for maintainability and speed.
 * Separate testing and production accounts on freenode.
 * Monitor build in production.