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.
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").
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.
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]
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?
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.
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.
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 why waiting is also an option. Feel free to excuse it however, but removing i18n here was a pretty big mistake on the rust team's part. For what? Rust 2018? I didn't contribute to the website, but I also didn't force anyone to change it either.
> There are a lot of people willing to get extremely mad about the website online
I'm not mad, I'm just disappointed. It's rare to see actual i18n for open source projects, and it's absurd to see it get removed arbitrarily when it does exist. I believe the Rust team is capable of delivering much better quality updates, hence my writing here. I'm also sick and tired of i18n being considered an afterthought by people who do have the resources to accomplish it to at least a basic degree.
Also, just because something is open source doesn't mean "well why don't you just go do it then" is a valid argument. It isn't.
Regardless of you, it's true in general. There has been a lot of heat, and it's damaged the ability to actually improve the site.
> Also, just because something is open source doesn't mean "well why don't you just go do it then" is a valid argument. It isn't.
It's not an argument. It's a description of reality.
It's not a matter of care; it's a matter of time and stuff to do. There are a lot of people willing to get extremely mad about the website online, but few people who are actually willing to step up and do work. That's the limiting factor on getting stuff done.
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.
My "different idea" is keeping the ability of non-English speakers to use the website and learn about Rust. I (and most people, I think) would not prefer a prettier site to one that has support for 10+ languages. Do you not agree?
My "position" is one of someone that heavily uses a language other than English. I very much enjoyed the old Rust site, because it meant I could actually show it to people around me, because their native language was supported. This isn't a tradeoff so much as a dealbreaker. What tradeoff was there for pushing the new website deployment too early?
I think it's perfectly reasonable to criticize an update that made the website prettier but removed i18n for no reason. Why? Was there a fiscal incentive to immediately replace the website before any translations could be done?
So instead of making personal attacks for no reason, how about we criticize bad, unnecessary software updates together?
Making as assertion about someone telling a lie comes across as that, if you're given the benefit of a doubt and assumed to not be someone that calls people out as liars with little evidence unless you get carried away.
But perhaps calling people liars is a normal mode of communication for you, and you didn't lose your cool at al. That's definitely one way to interpret the comments so far, given how you equate "criticizing" to how you've presented your position so far.
I think you had good points initially. I also think that when presented with facts about this specific situation you've allowed you argument to devolve into a stubborn stand based on technicalities while belittling others.
> So instead of making personal attacks for no reason, how about we criticize bad, unnecessary software updates together?
Indeed.
If nobody was happy about it, why was it deployed? That brings us to even more questions. Nothing presented thus far portrayed the decision to update in a better light, in fact it's only made my opinion of it worse.
I am used to websites having little to no i18n, but it's a complete mistake to actively remove existing i18n. For what? Rust 2018? A better looking landing page? Honestly now I'm just skeptical about the organizational structures that lead to this decision being approved.
I think you've confused "nobody was happy" with "nobody thought it needed to be done". The world is rife with actions that nobody is happy with, but most or many agree is the best of the bad options available. Just because you think there doesn't exist or can't imagine a situation in which it was better for them to do what they did than the alternative doesn't mean that's the case. There's already been an admission that the situation was bad, the result is a mistake. Whether that mistake was at the point of making the choice on dropping internationalization or at a point, possibly many months earlier, which hemmed them in and didn't allow them a good choice beyond "don't update and deal with the major problems that causes or update and deal with the major problems lack of internationalization causes" is unknown, assuming one over the other and calling people liars based on your assumption isn't very responsible.
> Calling it a "lie" is perhaps too strong, but that's essentially what it is, intentional or not.
I don't think "perhaps" is even in question. You didn't have the information to make that assertion definitively, as there are plenty of very possible and likely scenarios where it's not a lie. Do do so against a person who does know the specifics as they were involved, and without first digging deeper as to those specifics, is something I view as irresponsible.
(English is not my native language. I started out learning from Swedish resources, and generally consider that to have been a big mistake.)
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.
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.
The FAQ was often out of date, hard to maintain. It was super long. It's not clear how often it was actually used.
I found it difficult to find any code examples on the new site.
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.
You can see some code in less than fifteen seconds by clicking the big yellow "get started" button.
Did you agree with their feedback? Disagree? State it plainly, no one is going to sue you for it. :)
Many people who frequent HN are quite busy professionals. I too quickly close web pages that show zero code, or motivation for creating the language, or brief install instructions. To me it means that the creators can't present well and that leads me to assume that their programming language is bad at expressing intent as well (and thus verbose or confusing). Is this a wrong assumption? Very likely, but the first 10-30 seconds of percepting something new are not rational. That's a widely accepted psychological premise in marketing.
You might disagree and that's okay. Marketing however isn't at all about what you like but what your average site visitor likes.
So, finally, what was wrong with the code samples? They might have been too simple to be useful but they still did send the right signal to your busy programmer visitor -- IMO.
> Marketing however isn't at all about what you like but what your average site visitor likes.
I agree 100%. But anecdotes, mine, yours or anyone else's, aren't data.
I wasn’t looking to “Get Started” but why I might want to use it. Install instructions plus a basic example is all 90% of people want from a programming website.
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 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.
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.
Crystal lang is another very good example: https://crystal-lang.org/.
(I was the G++ FAQ maintainer back in the 1990s; yes, I'm old).
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.
"Frequently"
[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
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
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.
Personally I don't like that the new website doesn't even display rust's syntax (what it looks like) on the homepage anymore.
You can find it at the old site version: https://prev.rust-lang.org/en-US/faq.html