I think there is a need for a place to discuss beta.rust-lang.org that is not its issue tracker.
Please let us try not to be aggressive and to not assume we know better than the others what their impressions are. Let us also not discuss specific issues, because here is not the right place for it, and we will be able to discuss them again once the issue tracker will be open to discussion again. Let us only discuss facts.
Facts:
I discovered the existence of beta.rust-lang.org earlier today. Most of the IRC channel where I heard about it was agreeing that there were big issues with the style of it.
An alternative design has been put up at issue 468. It has been closed with the point that the overall idea of the design was fixed.
The overall idea of the design has been fixed without any community consultation. This completely makes sense for when interface designers design a website. However, the current beta.rust-lang.org has several usability issues, despite being a work of art from a pretti-ness side: it's really hard to read the text from it.
Seeing this, and reacting to it, I opened issue 478, with two small actionable ideas. @lbolla has been nice enough to provide two other actionable ideas. This issue has been closed ~3 hours after, saying to give small actionable ideas. Well, what can be smaller and more actionable than “increase the font size of the main text”?
Recently, on another IRC channel, I was pointed to pull request 484. Which made me notice that IRC had been removed from the list of channels without any kind of community consultation. And that a PR sent to re-add it had been closed and discussion on it had been blocked within ~30 minutes. While the choice to make Discord the primary channel may make sense, removing any mention of channels where more than 1000 rustaceans are can easily be felt as betrayal by these 1000 rustaceans.
As a consequence of points 1-4, it is easy to get the feeling that no style changes will be accepted. As a consequence of point 5, it is easy to get the feeling that no contents changes will be accepted.
As a consequence of point 6, it is easy to feel that the issues tracker of the beta.rust-lang.org repository is useless, and that community is totally disregarded in this process.
My personal opinion is that this is, at least, a huge public relations issue for Rust, which had managed to more or less avoid them up to now.
I would like to suggest that all operations on beta.rust-lang.org be freezed for long enough to figure out a good path forward that includes the community in at least feeling that they have a voice in the matter. I personally think this would be going through one or many RFCs to decide on matters, as at least the RFC process is tried-and-tested, contrarily to the issues repository of beta.rust-lang.org.
Let us try to have a civilized conversation here, however we internally feel. I have tried to do it myself, and hope my internal feelings didn't leak here. Feel free to contact me off-band (in PM here or preferably ekleog on IRC) if you see a point I could tone down some more!
While I agree that that PR was needlessly aggressive, I find the way that that discussion was closed to be concerning. It wasn't "re-litigating" anything, because, as it pointed out, despite promises of a "community discussion" there hasn't been one that reached any sort of conclusion. The issue was closed as if this decision is a done deal, despite no communication from any core team that this is the case.
Not to mention what people new to the community will be missing out on by potentially not having access to these 1000 Rustaceans.
I have to admit that the IRC link PR getting closed that abruptly was concerning. Especially, when you’re part of a leadership that leads a community, a group of people or whatever position gives you responsibilities towards a group of folks and its decisions, you cannot discard a member of the community having a clearly emotive reaction or weird reaction – the plot idea, which is extreme, but is clearly an emotive reaction. Instead, you need to open the discussion and try to get what went wrong with people yelling / having emotive reactions – this is a very basic skill that any manager must master. Especially in the case of a pretty legitimate reaction – IRC counts among of thousands of people; I know #rust, #rust-fr, #rust-offtopic, #rustc, #rust-beginners, #rust-… and the channels are very active. Leaving IRC as secondary communication channel is not hard to do and would help not discard thousands of people who use it on a daily basis – I think I don’t know any Rustacean that is not on IRC.
I’m on Discord on a few channels and servers and I don’t really like the app – for other reasons that were discussed already – but this is not of a matter. Most programmers I know (experienced and advanced programmers or newcomers) tend to go more easily to IRC. You don’t need an account and web-based IRC clients can have you jump in within seconds, while it’s not the case with Discord. On IRC, there are a lot of people that join a channel just to ask something, get an answer and leave – they somehow use IRC as they’d use Stack Overflow, and IRC is perfect for that.
From what I see from issues opened by nice folks here, they got closed and disregarded. This worries me. Isn’t Rust supposed to be a warm and welcoming community? What would it cost to leave the issues open to be discussed?
I get that the leadership has to make decisions and make cuts, but this has been a little extreme to my humble opinion, especially because people – we, members – are very invested in the Rust ecosystem. Those people who spend hours of their spare time trying to make Rust a better place day after day by providing ideas, issues, PRs and implementations deserve better than what I’ve been witnessing so far – getting your issue closed 30 minutes after opening it without place for discussion, for instance. Again, I don’t believe in plots, but I believe communication can – must? – be enhanced and improved so that people not feel frustrated nor muted.
As @Ekleog framed it, let try to have a civilized discussion and peace out!
To clarify: the PR for IRC was closed not because we're unwilling to mention IRC -- that's being addressed as we speak! -- but because the PR description itself was highly aggressive and conspiratorial.
The current plan is to add a button for taking people to the #rust IRC channel as well.
The current plan is to add a button for taking people to the #rust IRC channel as well.
This is a very good news!
To clarify: the PR for IRC was closed not because we’re unwilling to mention IRC – that’s being addressed as we speak! – but because the PR description itself was highly aggressive and conspiratorial.
I get why you closed it, but this is not justified to me. If someone in your group of friends have a highly extreme reaction, will you just tell them to hush and prevent them from talking again? My concern here is that you – or any people in the leadership – should have tried to calm down the situation.
I'm in agreement that the beta website has a very bad design.
Design issues
The colors chosen for the color scheme clash badly with each other. They're very inconsistent, dissonant choices.
There are 6 different colors in use on each page, which is an incredibly risky design choice that has never panned out well in practice. Designers should limit themselves to 3 primary color choices per page. The nim-language website is a great example of following this design rule. The rocket.rs is another good example. To no surprise, most professional websites, posters, even national flags adhere to this rule.
Never overlap three different colors with text. This makes the headers very hard to read, especially if you have any kind of reading disability, or color blindness.
The font for the headers are too large, too bold, too wide. The kerning also seems to be way off on the font choice. This actually makes them harder to read, and consumes space that could otherwise be spent on fitting more critical content on the screen.
Excessive padding between elements, which leads to an increased need to scroll. This increases the likelihood of visitors leaving the page, because the website is communicating style more than content.
Due to the padding and excessive font sizes, the website is effectively unusable on mobile devices.
Never use yellow text on black. It doesn't work well at all. This doesn't work well unless the text is larger, with a medium to bold font size, and the website is dedicated to that as the color scheme.
Content issues
The wording is sensationalistic in various parts, which makes the website seem oriented more towards a corporate-speak audience, rather than the technical one that is the actual target. This can actually turn a lot of technically-minded folks away.
The lack of source code on the front page is... concerning. A simple generic example that demonstrates many of Rust's more interesting syntax futures goes a long way in enticing a deeper look into the language.
Studies show that most programmers learn best when they have examples to learn from. By not including source code on the front page, programmers will no longer get an insight as to why Rust's syntax is a better choice over another language from a first perspective. This is why it's important that every crate displays examples within their README.md and crate documentation.
I'm baffled at why some of the most important content has been relegated to tiny links in the footer.
The testimonials are out of place, and to be perfectly honest, increases the-shady-as-hell marketing by a magnitude. They don't add any value to the pitch for Rust.
The front page could use some content to better explain why Rust should be chosen over another language. Why is it performant? Why is it reliable? Why is it productive? Why does this make Rust a better choice? What does it offer than we can't already do?
It describes some things that you can do in Rust, but truth be told, these things apply to most other popular programming languages as well, so I don't feel that this truly communicates anything unique about Rust. This merely describes that Rust can be used for the same tasks that other languages are capable of.
Perhaps the best feature that Rust has for CLI applications is the Clap crate, but the CLI page does nothing to demonstrate how powerful Rust can be with a CLI built around it.
Networking makes no mention of the Actix web framework, which is built on top of tokio, and thus async I/O. Rocket does not support async I/O and is much slower as a result. Furthermore, Rocket does not build on a stable compiler, so it's very misleading to showcase it.
Personal nitpicks
When I first visited the original Rust website, the code example is the first thing that stood out, enticing me to give it a deeper look. With the beta, very little stands out to me, personally, to give Rust a try. It looks like an ad for hyped Node.js web framework.
The lack of a Documentation link is a bad thing. Learning and documentation are two entirely different things. Documentation is what an already-learned person refers to when they need to reference some specific details.
The Learn and Documentation should be split into two separate pages. Learn should be dedicated to books and tutorials.
I feel like there's a lot of wasted potential here. There's a lot of great resources in the Rust community that should be displayed front and center, but they get zero mentions on the website, or even the front page. The official book, Docs.rs, Crates.io, etc. These should be on the front page.
As it is now, the current website is superior to the beta website.
Moderation note: Let's please not litigate this in this thread. The PR description is unnecessarily aggressive and hostile. That type of behavior is not welcome. If you'd like to discuss this issue in more detail, then please contact the Rust moderators: rust-mods@rust-lang.org.
The Rust community follows a code of conduct, and accusatory issues like that will absolutely be closed and locked.
Open source can be high stakes at times and feelings may run high, so having a reaction is understandable. However, while the moderation team does try and deescalate situations, leadership in general isn't expected to deal with strong accusatory reactions like the one in that IRC issue. That's a good recipe for burnout.
Feel free to contact the mods directly if you have further questions about this policy, it's off topic for this thread.
First, we've been getting a lot of feedback in quite a short time. 108 hacker news comments, 286 on /r/rust, 144 on /r/programming. It's a lot.
In order to handle this kind of feedback, we need to set guidelines for how it can be triaged and responded to. A lot of that work by me yesterday was to get people to file issues on the tracker. Because we can't track random internet comments. That's step 1.
This was not an issue; it was a PR. The PR could not be accepted in its current form, and so it was closed. That doesn't mean discussion can't happen. It does mean that it needs to happen in an issue, where the details can be hashed out before a PR is opened.
It is obvious a 7 day notice before live is only for reporting broken links.
Have never been a fan of up front list of features so good to see that gone.
It screams bad engineering, all expense spent on fluffy visuals. On mobile "GET STARTED" is first thing shouted to you. The given completely useless for mobile page.
In end don't care so much as wanting NLL and other features coming to stable. (Web is minor distraction from code, this forum and playground.)
"The vast majority of Rust teams have chosen to move their official chat spaces to Discord, and in most cases have de-voiced the old IRC channels." didn't exactly help with not giving that impression, either. I'm struggling to understand why that would have been said that if the plan had always been to re-add IRC. (Not to mention why, in that case, IRC was removed at all.)
I ask this not to be confrontational, but because I think that as the discussion stands, it still reflects poorly on how Rust operates, and because I think that addressing this would help to resolve that.
Every public thread on this is nearly unanimous on one point: a programming language needs code samples front and center. However, when I checked the issues for the beta site, the many that have been opened about this are closed with variations of “this has already been decided and is closed for even discussion”.
I couldn’t find that discussion, though. Could someone link to it? I’m really curious how it went down. I’m aware that the summary is “it’s too hard to find a representative snippet”, but that rings hollow to me: every language has this problem, but the vast majority provide snippets anyway.
As an extremely good example, check Dart. Note how they use clickable “footnotes” to explain the syntax and call out language features. This would be especially helpful for snippets of relatively symbol-heavy Rust.
It might be worth noting, since I just realized it myself: I have no idea what the Dart snippet actually does. I scanned it looking only at the syntax, clicking when curious, and being exposed to language features as a result. I’m looking at the “forest” of the language, not the “trees” of what the actual snippet is doing.
I suspect chasing a “perfect snippet” is what doomed this, which is a shame. That’s not the point!
At the very least, it shouldn't be difficult to have a competition to create a succinct generic snippet, or a collection of snippets, that best demonstrates Rust's features.
You lost me here. There are absolutely some valid use cases where Rust fits that almost no other language does. IoT is one such case (your only other realistic options are C, C++, and assembly).
Otherwise, your post is spot-on, and I agree with everything else stated. Well said.
There are embedded and IoT platforms that support Java, and even JavaScript, as the preferred languages for development. Many embedded / IoT devices today now carry decent processors with gigabytes of memory, making garbage-collected languages a possible optional. Older embedded equipment may still require a language as low level as C/Rust/Assembly.
Modern low-cost microcontrollers are not going to be running Java or JavaScript. "IoT" doesn't fit into the subset of 64-bit ARM platforms from the post-RaspberryPi world. But your point is still heard; IoT is a vast area of increasingly complex technological advancements.
That's a bit odd, and not at all how the standard GitHub / GitLab workflow functions. When a PR can't be accepted in its current form, it's typical to have discussions on the PR, then waiting for the PR to resolve those discussions. Closing a PR signals that the discussion is over.
