Hacker News new | ask | show | jobs
by maddening 2587 days ago
They removed the FAQ as it didn't fit they newer site.

You can find it at the old site version: https://prev.rust-lang.org/en-US/faq.html

5 comments

I'm confused as to why they redesigned the website but removed prior functionality.

A few weeks ago people pointed out that the internationalization also suffered due to this. Edit: by suffered, I mean "was removed entirely". I just checked and couldn't find a way to change the locale, nor could I manually set it e.g. by appending /de-DE, etc.

If the new design requires a link to the old design to access removed functionality, is it really ready to launch?

---

edit; these were the languages offered: Deutsch, English, Español, Français, Bahasa Indonesia, Italiano, 日本語, 한국어, Polski, Português, Русский, Svenska, Tiếng việt, 简体中文

Now if I want to refer to someone about Rust in Korean I have to link to prev.rust-lang.org, which is weird.

It's the "redesign culture" in a nutshell. Change things (expending effort) for no discernible reason, break familiarity, arrive at subjectively worse appearance, and at objectively worse functionality. It's hair-pullingly frustrating.
It's a cargo cult. For any technology, there is a period of time when it improves more or less monotonically, and so most new things are cool. Some people over-extrapolate this and conclude that new things are always cool, and so is born the cult-of-the-latest-thing, which persists long after actual improvements stop.
Holy shit the new site is awful on desktop. The font size is huge on a desktop monitor so you have to scroll a lot to see anything. (hint: what do programmers usually access the web with).
The site were redesign using Tachyons CSS and it seems probably not finalise yet.

https://tachyons.io

That's a very dumb reason to ditch i18n. Waiting before it finalized wasn't an option?
As far as I can make out, the new website was considered a key part of the "Rust 2018" project, and so the maintainers chose to launch it before it was really finished (and without the planned period for user feedback), at the same time as the Rust 2018 release.

Evidently it wasn't quite such a key part of the project that they could consider delaying the new Rust edition until the website was ready.

In hindsight tying the website update to the new edition was quite possibly a mistake. The Rust core team has asked people to hold off on discussing the process or proposing major changes until they've published a retrospective on what happened (that was five months ago, and the retrospective is now "mostly finished").

Thank you for explaining it. I now finally understand why it was deployed with removed functionality.

That said, that is a completely idiotic reason to remove something like i18n. Unbelievable.

I wish I could say I don't understand how this got approved by multiple people, but the sad reality is that nobody makes internationalization a priority. It's completely normal to not have the other languages I use to not be supported, but I guess it stings to actively have it be removed.

Instead of yelling at people who weren't involved with the decisions and are only providing context, maybe go write a calm series of bug tickets explaining your concern, or better offer to and follow up on helping with i8n support?
So raising a point on a random internet post is now considered "yelling"? Interesting. Also, I called "that reason" dumb. Perhaps you're personally involved with the project, but please try to read things as they are instead of taking offense unnecessarily.

Counterargument: How about one doesn't remove stuff like i18n in updates? Or what about simply delaying the deployment until the i18n and other features are done? Or is removing support for other languages considered acceptable if the new, English only, website looks very pretty? [tone is of light sarcasm]

Counterargument #2: just because something is open source doesn't mean you can go "well, just open a ticket or do it yourself". No, how about people in general update things properly (or at the very least, don't remove translations)? I'm perfectly allowed to criticize removing important functionality like i18n. It was there, now it isn't, and I didn't make the choice to remove it. It's not my job to do other people's jobs for them just because I exercised my ability to criticize something. Otherwise I would be working on GUIs/UX for open source linux projects until I die. [tone is of exasperation in open source software development]

You might have misunderstood the sentence's tone.
Does the new design require a link to the old design? By your opinion sure, but they don't think that do they?

Which is to say, if you own a site and decide to cut a feature, isn't that okay? It may or may not be a feature users want.. but that's another story entirely, no?

The new site has a link to the old one at the bottom. My opinion isn't factoring into it.

However, losing i18n is pretty bad. These are the old languages that were offered:

> Deutsch, English, Español, Français, Bahasa Indonesia, Italiano, 日本語, 한국어, Polski, Português, Русский, Svenska, Tiếng việt, 简体中文

However, as someone who regularly studies and works with a non-English language I can tell you i18n is pretty darn important. More important than a very pretty site that people can't read.

Per my own opinion, a FAQ is also a great idea. Especially for a new language that's trying to gain more adoption. Entirely removing it instead of reworking it into the new design before deploying mystifies me.

Nobody was happy with losing i18n, and it's on its way back, there were just some delays.
That's not really the truth though, is it? If nobody was happy, then the new site wouldn't have been deployed. Or by "nobody was happy", did you mean "nobody really cared, because English is their primary language, thus they aren't affected at all"?

The new website is very pretty. I don't understand why the deployment could not have waited until the translations were completed. Even just translating 4-5 widely used languages would've sufficed, although still not ideal compared to the old website.

Even if people wanted to visit the old website, it's buried at the bottom of the new one, practically invisible.

> If nobody was happy, then the new site wouldn't have been deployed.

This is an incredibly simplistic view of how projects work. On any large project, there are a number of objectives, with different priorities. And there are a number of factors, some public, some private, as to why projects end up the way that they do.

I am the person who implemented the original i18n support. It took me a year of effort to get it shipped. I do care about this. That's not incompatible with what's occurred.

> "nobody really cared, because English is their primary language, thus they aren't affected at all"?

Even if English is a primary language, that doesn't mean we aren't affected. For example, not shipping it means that I have to be embarrassed and apologize when people on the internet point out this shortcoming. Not shipping it can limit growth, as you point out. There are tons of ways.

> I don't understand why the deployment could not have waited until the translations were completed.

The original way of doing i18n was completely untenable. Doing it a better way takes time and effort. That's before the translations are actually made. That work has been ongoing since December of last year. It's getting pretty close now, with a lot of movement recently.

> That's a lie. If nobody was happy, then the new site wouldn't have been deployed.

You're losing your cool just because you have different ideas of the perfect trade-offs to make while having zero, and I mean zero, skin in the game.

It's not as impressive nor noble of a position as you seem to think it is.

I don't know what wasn't fucked up by the redesign, so I don't have such confusion. I just assume it was done to make the site intentionally less useful for the glory of satan, of course, so it seems fitting.
Who cares about i18n? Both the language itself and all* libraries are in English anyway. You won't get far relying only on translated material.

(English is not my native language. I started out learning from Swedish resources, and generally consider that to have been a big mistake.)

The code itself and libraries being English is not a new concept.

Materials and knowledge about the language leads to more people potentially discovering it. I can far more easily persuade someone to use Rust, if I share the website with them in their native language.

Consider the reality that not every nation is advanced in English like Sweden or other European nations.

Anyway, the old site did have i18n, meaning that they did care about it. Not only did they care about i18n, they also had more niche languages, which is quite rare for an open source project. The alternative is basically saying "just learn English in order to read about Rust and why you may or may not want to use it". I find this unacceptable.

So it's very puzzling to me that the new website entirely ditched i18n–it's incongruous to what I perceive the quality of the rust team is capable of.

> Materials and knowledge about the language leads to more people potentially discovering it. I can far more easily persuade someone to use Rust, if I share the website with them in their native language.

That works for more 'end-user' facing projects, (GIMP, Mastodon...), but for programming languages not that much. As someone who speaks 3 languages, (including English), let me assure you that (most) non-English programming materials use a very tortured vocabulary in the target language, which actually makes it considerably harder to learn.

Also, prior to me learning English, I've always found it extremely disappointing when the main website of a project was in my language, but then you click on any important link, (like a guide), and it's English only. It was a bigger let down that if a site was English only from the get go and I knew every link it's going to be English. I actually learned English because of this.

As for general info about a new language etc. there are usually dedicated "IT/programmer" community portals with news and some basic tutorials for the new hotness in the target language, which is usually how non-English speakers learn about new tech, not really from the project website, at least in my experience.

I miss the old site :( It's so simple and beautiful..
Design choices shouldn't be a reason to not include the FAQ
Design had nothing to do with not including the FAQ.

The FAQ was often out of date, hard to maintain. It was super long. It's not clear how often it was actually used.

Was there a reason why the runnable code example (plus a link to more examples "Rust by Example") that was front & center of the old homepage was removed?

I found it difficult to find any code examples on the new site.

There's been a years-long discussion about how to get a good code sample, and we've never found anything satisfactory. Short examples don't show anything interesting, and interesting examples are too long. Nobody was happy with the old code sample, and nobody was happy with all of the suggested alternatives.
Every time a new language is posted on HN I spend ~15 seconds looking for code and, if I can not find it, I close the tab.

I can't imagine that isn't the case for many others.

I think Go nails this with the multiple code samples.

edit: In retrospect, I'm sure this is beating a dead horse and you're all well aware of this. I wonder, instead, what the approach is to fixing these problems when they reach a standstill? It sounds like no one could agree, so progress halted.

Everyone's experiences are different. Many languages don't even have a centralized web presence, and many don't have code snippets on the home page. Just as you'd absolutely expect it, I would equally never expect it.

You can see some code in less than fifteen seconds by clicking the big yellow "get started" button.

You are coming from the perspective of somebody with deep knowledge of the language. For somebody that never saw it, a short code sample say a lot.

I know this because the first Rust code I've seen was that short sample. But then, I completely understand if you desire to focus the site on people with experience on Rust.

I may have experience, but it wasn't me that decided this. It was also from talking to a lot of new people, and their reactions to various code samples.

> I completely understand if you desire to focus the site on people with experience on Rust.

It's not, actually! It's the opposite. However, the audience is not just pure programmers either, it's also people like CTOs, etc.

golangs multiple options (via dropdown) always seemed the best to me https://golang.org/

Nim's line length one is okay https://nim-lang.org/

Although I'm sure you guys debated it to death already I still find it unusual to not be able to find a any example of actual within a few clicks. Committee-driven design is always difficult.

Go's page is for programmers; Rust's new page is for non-programmers. I think it's a mistake that you have to click "Get Started", then read through installation instructions, to finally see what Rust code looks like. It's all backwards. A short snippet (or two) should be front and center.

Crystal lang is another very good example: https://crystal-lang.org/.

Something similar to how Crystal approaches it could perhaps work, giving a whole bunch of different small examples (including compilation errors) with corresponding entrances to documentation.
Their new website is more marketing oriented. They tried to look for a "good" example and didn't find it. So basically they saw that the language looked ugly and didn't want to show it, which is in my opinion very dishonest. I remember voicing my dissatisfaction on this change. A snippet code should show what the language looks like, not mislead the reader.
Seems like there should be two sites; one for people they want to "market" to, and one for developers.
Nonetheless, it feels like there should still be an FAQ for actual FAQs. It's harder to maintain than other documentation?
We've empirically found it harder. It's completely disconnected from everything else, and covers a wide range of things, and so it's very easy to get lost in the shuffle.
So assign the job to people who can focus on just that; community volunteers can often do a better job than the core team for an FAQ, because they are more in touch with people new to the language are confused about than core developers with deep knowledge of everything. It will be dynamic and questions/answers will become obsolete, so that has to be handled.

(I was the G++ FAQ maintainer back in the 1990s; yes, I'm old).

> So assign the job to people who can focus on just that

This requires having a person who can. We never had one.

> community volunteers can often do a better job than the core team for an FAQ

Absolutely! The original version was written by the community. After such a heroic effort, they couldn't maintain it. I believe it was a lack of time, not desire, but regardless, that's just how it goes.

> It's not clear how often it was actually used.

"Frequently"

Ha!
It is if you are standardizing documentation. I don’t expect FAQs in the main website.

https://doc.rust-lang.org/1.0.0/complement-lang-faq.html

Given that a lot of these questions seem relevant for people considering to try rust for the first time, including some sort of link on the main website might be helpful.
A redirect would be helpful so the old links still work.
We generally tried to have redirects, but we are humans and therefore fallible. Please file bugs!
I would, but then the linked FAQ is outdated (in fact, the 1.20 version[0] indicates it moved to the website), and I don't think having a redirect that points to the prev website would work. According to [1], the presence of an FAQ on the website is an unresolved question.

[0]: https://doc.rust-lang.org/1.20.0/complement-lang-faq.html

[1]: https://github.com/rust-lang/www.rust-lang.org/issues/445

Ah, I thought you could redirect to prev. Sorry about that!
Heh. "Currently, Rust is still pre-1.0" doesn't seem to agree with the URL. ;-)
Just another demonstration of how easy it is to let this kind of thing get out of date.
Your nickname perfectly fits my opinion on the newer site, BTW.
That... Seems bad. Sorry to jab but is optics also why they decided on confusing non-standard async syntax?

I always thought that for open source software, the more terrible the website the better it was. A site too slick may ruin Rust's reputation

People that appreciate Rust's features can and do also appreciate a nice site - they're not mutually exclusive.

There is no such thing as "standard" async syntax unfortunately. The Rust language team is trying to find the optimal blend of ergonomics and consistency when there isn't a clear winner. It feels like pointless bike shedding to many, but a decision like how to handle strings has bifurcated the Python community for years.

This implies the old site wasn't nice. Which is not true. The old site isn't as pretty as the new one for sure, but it wasn't a bad site. It was straightforward.

Personally I don't like that the new website doesn't even display rust's syntax (what it looks like) on the homepage anymore.

> The old site isn't as pretty Wasn't it? It was clear, clean, had nice typography, didn't cause epileptic seizures when you scroll it. That's a way more than I can say about the new one.