Rust 2020: Growth

I don't get why you're explicitly arguing against postfix await. If you're worried about language complexity, then any form of async/await at all is going to be about equally complex. I can't see the postfix-await kvetching as anything other than pure bikeshed painting; it made lots of noise because it's a surface-level discussion that anyone can form an opinion on.

The endless proposals for control-flow operators, implicit conversions, delegation, and inheritance are leaving me a bit concerned, though. Rust can't do all of them, so no matter what the core team does, most of them are going to leave disappointed. Disappointed community members aren't fun to be around.

No... I already said why curl | sh was a bad way to install things:

  • There's no good way to inventory all of the software installed on the machine. Configuration management systems want to inventory the installed software so that they detect whether a to-be-installed package is already installed or not.

  • There's no good standard way to operate a local package cache. The advantage of having this when you want to provision a couple dozen CI build servers should be so obvious that I refuse to bother writing it.

  • There's no good standard way to attribute files to the application that provided them. I, for one, prefer to be able to understand why files exist on my computer.

  • There's no good standard way to lock the version. I would like to be able to recreate a fresh system with a setup that used to be in play a few months ago, to be able to bisect issues and figure out which change introduced them.

Now, to the credit of the Rust release team, rustc is not that hard to package. The Rust compiler doesn't need to run any system services, and it automatically discovers all of its paths relative to the rustc executable. You basically just unpack the tarball, move all the files into place, and add rust's bin folder to your PATH.


Postfix await is merely an example of a feature that was rushed to stabilization despite widespread controversy.

A couple of observations:

  1. Given the exponential growth of pretty much everything worthwhile, and in this case hopefully Rust adoption, it is inevitable that most readers and users of the code are always new to the language.

Ergo, keeping it simple for them is a good idea.

  1. Introducing new operators and such sounds like it will include a lot more weird use of odd symbols in odd combinations to do so. This kind of thing (from post above):
fn split_text<T: FromStr>(s: &str) -> impl Iterator<Item = Result<T, T::Err>> + '_ {

Is nuts and not helping anyone.

  1. If there is two ways to express everything in the language, for example, then we have 1024 ways to write the same 10 line function.

Clearly that is not helping anyone when they have to read it. Given that I hear a lot about "idiomatic Rust" if one is using said idioms then one does not need the other multitude of ways to say the same thing.

  1. I don't know what the argument is about postfix 'await'. If it's a simple question of postfix, or prefix I don't much care which wins out. But given 3) above it would seem better to just have one or the other, not both.

Totally agree with @ZiCog. This sentiment is beautifully captured in the Zen of Python:

There should be one—and preferably only one—obvious way to do it.

Python, with all its flaws, stays true to its Zen where it matters. The Python community also frowns upon code not deemed Pythonic. The Zen of Python is lived and enforced by the community, is not just a bunch of nice words.

Excuse my Python reference here, I don't want to start a language/community war. That being said, is there something equivalent in Rust? In the sense that the Rustacean community as a whole is actively trying to keep the language follow a philosophy?

I see @H2CO3 has mentioned 'simplicity of the language' as a goal of Rust a few times in this thread. But according to what he has written about it, it seems some people with decision power are not keeping up to that promise.

Personally, I think simplicity is key in the adoption of a new language.


I don't know. I'm a new kid on the block around here.

As such I have eagerly watched pretty much every presentation at every conference about Rust on Youtube that I can find.

Many of the presenters have uttered the phrase "idiomatic Rust". Which is as close a "Zen of Rust" as I can find.

Of course I still have no idea what they mean by "idiomatic Rust" or what they would like "idiomatic Rust" to be in the future. No doubt they all have a different idea in mind.

To elaborate on that, I don't view simplicity as a goal but as a tool that helps me write correct code and others to understand my code more easily. Unfortunately, many people who oppose my idea of simplicity seem to assume I want a less sophisticated language. That is not the case but I have a really hard time (and am quite exhausted) explaining it over and over.


Using some of the more sophisticated language bits in the right places lets you write simpler code in other places. The right abstractions permit writing code at the level of thought in the core of your application. They also let you design mental labyrinths if used without taste and care.


A start to "idiomatic Rust" could maybe be viewed as satisfying all of the Clippy lints, which are a collection of general rules developed to help people write consistent and best-practice code.

As far as I understand, part of writing idiomatic code means writing code that fits well with the way that the language works and doesn't abuse features in a way that will hurt either readability, maintainability, or performance ( essentially best practices I guess ).

Yes, it's a mix of intuitiveness, logicality and uniformity.

  • Intuitiveness: Items and constructs in the language do no more nor less than intended and expected.
    • String manages a utf8 buffer. It does not entail odd edge cases like a null byte or a buffer overflow.
  • Logicality: Items and constructs in the language follow a structure that scales, is maintained, and will be readable twenty years from now without the need to read a 30 post github issue/forum thread, or they can be summarized in a few lines in docs. (Unsafe is an exception, it's a can of worms occasionally)
    • str may seem odd at first, but its explanation isn't: str is the data in a String, so &str is a reference to a part of the String.
  • Uniformity: Items and constructs in the language follow a pattern in their conception, naming, and usage.
    • An odd choice: Everything that is considered "runnable code" can be contained in a {} pair, and any time you encounter them, they follow the same rules. With some grammatical exceptions present.

Note that these are all arguably the same


Again, I'm not arguing against sophistication. I'm arguing against features that only work as crutches to existing functionality or merely for the sake of making Rust similar to another language.


Unfortunately that statement does not say very much. All three of those qualities are not as rational as one might think. Given almost any language feature one can find programmers passionately arguing for and against them. Each claiming to be arguing from a position of "intuitiveness, logicality and uniformity".

Often it could be that a weird language feature suggestion will be seen as intuitive, logical and uniform, by a programmer because that is what they are familiar with from some other language. No matter if it sticks out like sore thumb in some new language and does not work well in the new context. Not to mention unintuitive to those from different backgrounds.


I've been using Rust for 5+ years, and I think I still concur with @domibay-hugo. It isn't about when to use a particular string type, it's about how to convert between them: for some conversions it's the new() method, for others you use from()/into(), others yet need from_xxx()/as_[lossy]_xxx(). I dunno, maybe there is a method to this, but I haven't been able to figure it out yet.

The worst is when you need to call a C function taking a path: then it's something like CString::new(path.as_os_str().to_str().unwrap()).unwrap(). See if you can figure this one out in less than 15 minutes using just std documentation...

No, say what you want, but the many strings of Rust do deserve their bad reputation.


I would not fret about strings in Rust. Strings are a mess in all programming languages.

Even C has at least 2 string types. A string literal is not the same as a string that exists on the stack or in some malloc'ed place. If you are lucky your compiler complains if you try to mutate a string literal.

Then in C++ we have the String class. I cannot count the times I have had to get down to the actual bytes of a String with c_str.

Of course all of that is useless when you need to deal with Unicode.

Old guys like me wish that we had stuck to ASCII and that a character was a byte and everything was easy. Sadly now, we now have to accommodate Unicode, Pile of Poo emojis and all.



Since only 36% of the people in the world have a language that uses a Latin script, and many of those use accented vowels and consonants that are not in ASCII, restricting to ASCII advantages native English writers and disadvantages almost everyone else. That's patently unfair.


I totally get that but I still think Unicode has some bizarre and irritating edges. Which is to say I agree with other people that strings are just inherently complicated and I find Rust’s multitude of string types less complex than having to think about the underlying bytes myself.


String types, by nature, are confusing, and in a low-level language such as Rust, lots of that confusion lies close to the surface compared to other languages such as Python. If you want the extra control, you can't get away from the fact that there is a difference between &str, String, OsString, &OsStr, etc.

Maybe the best investment to fix this issue is just to write a good tutorial or make a good video explaining it.

Maybe another possibility would be to make a crate for a new string type that converts between all of the different types, making all of them look the same to the programmer, and hiding the details like would happen in other languages. The trade-off is that the new string type will not be a zero cost abstraction.

I would say anyone coming from low languages would take less than 3 mins lol

Googling and reading the following doc was enough for me

Documentation is pretty clear imo and reading the description made it clear what it was for, and looking at the api showed how to use it. But coming from C++ probably helped as these concepts were already familiar to me.

@domibay-hugo mentioned Perl, people coming from higher languages probably would struggle with multiple types of strings and understanding the documentation.


Yes we know why.

What is patently unfair on the entire human population is the insanity of Unicode. I thought it had jumped the shark years ago but then this got added to the standard: :poop: These emoji things come from no language and convey no meaning.

And what do you make of this Javascript?:

let ﻝ = {
    ﺍ: function () {
        return ("Hello world!");

let msg = ﻝ.ﺍ();

ف = (2 + 3) * (3 + 3)

1 Like

I failed to understand why your JavaScript example is supposed to be considered bad. You used Arabic text; so what? The actual JavaScript VM doesn't care. The names are just opaque blobs to the system anyway.

Or why the poo emoji is to be considered a hairy part of implementing Unicode: sure, it takes multiple bytes, and its existence is kind of superfluous, but it involves no combining marks, and it is not an inherently cursive script with specific shaping rules, and it does not interact with writing direction or other Unicode state machine stuff in any way (unlike your JavaScript example), and the desired rendering doesn't even depend on the text's language. The only tough part is that it's a color glyph, but the Unicode spec allows you to forgo color rendering if you need to, and if you want to correctly render all the real language scripts, then you're probably using an off-the-shelf text rendering library anyway.


If you are seeing what I am seeing in that Javascript in Chrome today it does not look so bad.

When I crafted that example years ago it looked like there was an object called "J" and it had a method called "i". In my editor and in the forum I first presented it on. The call is then "i.J()". Which of course makes no sense and threw people into confusion until they looked at it closely.

Similarly the expression looked like "(3 + 3) * (3 + 2) = J". Which is also nonsense.

My intention with the example was to show that Unicode is nuts and that potentially it was a way to sneak malware into the code. The later has come to light recently as a security issue as people craft fake URLs using Unicode to lead people astray.

Luckily we can't do that kind of thing in Rust yet: "error[E0658]: non-ascii idents are not fully supported". Hopefully it never comes to be.

As for the poo and friends. My main objection is that they have no meaning. The first time I saw a poo emoji it was a dirty ugly looking things with a bad smell emanating from it and flies buzzing around. That carried a very different meaning that the happy, jolly little fellow as he is rendered today. Apparently the likes of Apple felt the need to clean him up. The same can be said of pretty much all emoji.

I don't think such childish, cartoonish graphics have a place in a technical specification in an engineering discipline.

I'm sure many here would object to a pussy emoji. But why, it's symbology I see had written in many places?