Hacker News Reader

Comment by wtetzner | Hacker News Reader

> Rust is already a weird language to come to from the likes of python, Java, or Javascript

I think that's a great reason to evaluate new syntax/features on how they will be used, as opposed to how they will attract (or not) new users. New users are already going to be expecting things to be different, and so making this one thing more familiar probably won't make much difference. On the other hand, code lives for a very long time once it's been written, so making the right choice in terms of readability/maintainability seems like the right move.

View on HN

While that's true on an individual basis you can't use that continually to introduce differences, because at some point if someone comes to rust and sees a heap of weirdness they're going to be less likely to adopt the language. I'm mostly a bystander since I've written some rust but not very much, but I think rust is neat and I don't want it to become an esoteric language.

If it's an effective solution it will only seem weird until it's proven to be more useful than the status quo approach.

I read this post and thought 'async as a prefix is intuitive!', but that's only because I saw it first in C#.

Rust already has an immense learning curve despite its ergonomics, I say it should continue to experiment. Same way Haskell does.

I do wonder if `.await` could have a sigil equivalent the same way `try!` did with `?`. `…` could work if it's not already used as spread args.

> If it's an effective solution it will only seem weird until it's proven to be more useful than the status quo approach.

Perl was a very effective solution. Still lost. And I say that as a long time perl5 nut.

Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). And it's getting rapidly worse.

> Perl was a very effective solution. Still lost.

For some version of "lost." It lost to $LANGUAGE_OF_THE_MOMENT for web development, but Perl is still a great text-munging and glue language, and I'll bet I'm not the only one using it for that. It didn't take over the world, but I'll bet that most people interact with a bit of Perl every day.

I agree that Rust is syntactically insane. Worse, while a Shell-and-C programmer would have some intuition about Perl syntax, a C++ programmer will almost start from scratch in Rust.

> Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was).

Can you elaborate?

Not even if you paid me to have that fight, no.

Edit: OK, one tiny crumb: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html -- Read through that thinking about how other languages express the same fundamentally simple concepts, and consider how Rust invents new syntax for basically everything, and then sticks it all together by re-using syntax from other areas. Why does a parametrized enumerant look like a function call and not a struct? Why is "127.0.0.1" not a String? Why do parametrized enumerants look in rvalues like C++ constructor arguments, which you promised earlier Rust didn't have?

Don't tell me the answers to those questions. I know the answers. Just recognize that those are questions that every new reader to that very early page in your docs is going to have. And... did they even need to be questions in the first place?

You need to tell us which other language you compare it to then. AFAIK most mainstream languages (the ones these hypothetical new readers are most likely to come from) don't have anything like Rust's enums. C++ does have the difference between C-style "const char " and "std::string" which is a bit* similar to &str and String, although &str is obviously massively safer and more ergonomic.

If they come from Scala or Haskell then yeah, sure but I'd argue that most programmers these days are likely to come from JS, Python or Java/C#/C++ and copying Scala or Haskell syntax would look even more foreign to them. Rust instead preferred to go for a syntax inspired by C++

>Don't tell me the answers to those questions. [...] And... did they even need to be questions in the first place?

So you know the answers but you still think it shouldn't be done that way?

Having things like &str instead of forcing everything into a dynamic String is Rust's killer feature. It means that you can write safe code while not being forced into adding any overhead. You pay for what you use, to quote the C++ motto. That means that as Rust matures it becomes a good competitor for replacing C and C++.

> Why does a parametrized enumerant look like a function call and not a struct?

I don't think this is an "invented new syntax"; plenty of languages with built-in support for sum types do it this way. Of course, most mainstream languages don't have built-in support for sum types, but that's an entirely unrelated point to Rust's syntax for them.

> Why does a parametrized enumerant look like a function call and not a struct?

Because tuples are considered good things to have in a modern language. Structs and enum variants are just named versions of tuples (denoted with parentheses) or records (denoted with braces—unnamed records don't exist in Rust). To follow languages like Python, they're written "(1, 2, 3)". (It would be weird if tuples were written "{1, 2, 3}", right?) Therefore, a tuple named Foo is written "Foo(1, 2, 3)".

Removing tuples from the language was actually considered at one point, but the community (including me) really wanted them to stay, so they stayed.

> Why is "127.0.0.1" not a String?

Because it's a str, and there is a difference between str and String. Not having a string-view type would be a big mistake in a systems language like Rust. Note that "127.0.0.1" is not a std::string in C++ either (though there is an implicit constructor that can make it one).

In fact, the reason why we have both "str" and "String" is precisely to address your criticism: if we named "str" "string_view" or something, then people would be really surprised that a literal like "127.0.0.1" isn't a string.

> Why do parametrized enumerants look in rvalues like C++ constructor arguments, which you promised earlier Rust didn't have?

Because saying Rust has C++ constructors would just make things more confusing, because then people would expect them to behave like C++ constructors. It's less confusing to say that Rust doesn't have constructors like C++ does.

> And... did they even need to be questions in the first place?

I don't see any alternatives to the above that would make the language better instead of worse.

> (It would be weird if tuples were written "{1, 2, 3}", right?)

That is the case in Crystal. Doesn't feel weird - if anything it is consistent in that ()s always denote something to do with execution. Both ()s and {}s have multiple different other syntactic usages though, so it is not as if either is optimal.

Most languages that offer tuples, either use (), or just treat commas as "tuple operator" anywhere they don't have another meaning already. And this goes a long time back.

Function calls can then be treated as functions from a single tuple argument, as is idiomatic in SML.

Like I said the first time, I know all that stuff. I'm trying to express problems a new user is going to have with this syntax, and "but our reasons are really good!" does nothing for them.

It's not inconsistent to hold the simultaneous beliefs that "trying to fix Rust's syntax would make it worse" AND "Rust's syntax is insane".

And given those beliefs, maybe adding a postfix operator to express what everyone else does with a function call was a poor call.

It is inconsistent to hold those beliefs. Because "insane" implies that the Rust team made wrong decisions with the syntax, in fact so obviously wrong that no "sane" person would make them. If you acknowledge that the syntax decisions make sense, then they aren't "insane".

Meh. That's just playing semantic games. I'm using "insane" in IMHO the more common colloquial sense of "inscrutable; hard to understand; inconsistent with existing paradigms". I'm absolutely not questioning your mental health.

Nothing about the soundness of your design means that Rust isn't hard to learn, is all I'm saying. And per the freakshow all around us, it's getting harder, not easier.

I've never understood the use of the word "semantic" in the dismissive sense. Meaning is everything when parties are trying to communicate. This thread finally got to the heart of the miscommunication, and instead of celebrating you say "meh." I don't get it.

That is exactly the same way Haskell does "parametrized enumerants", and in C terms, str is like any pointer to a string, while String is like a heap-allocated string. What's "new" about any of this? C++ has the same thing going on with string and string_view.

If anything, Rust's managed to be a whole lot simpler than other languages. Python, JavaScript and C++ have some of the worst string encoding stories I've ever seen. And most popular languages don't even have sum types, so it's like they have an "and" and no "or".

> Just recognize that those are questions that every new reader to that very early page in your docs is going to have.

I doubt all new readers will have those questions. It depends on their background. For example, plenty of languages use similar syntax for sum types (Scala, Swift, ML, Haskell, etc.).

I'll bite. For context, I'm very much a rust beginner with probably a couple dozen hours at most. I find that anything having to do with lifetime parameters is hard. I think this is even worse than C++ templating in some sense since it behaves differently than type templating.

Otherwise, I think the syntax is fairly reasonable.

My advice would be to completely forego lifetimes handling until much later in time. It is a difficult part of the language to master but it gets much easier once you get more practice. Get well acquainted with the rest of the language and you'll pick them up with less trouble.

That's legitimate; lifetime parameters are a new concept that aren't found in any other language. They naturally require a learning curve. Lifetime elision—making it so that you don't have to see lifetimes in most cases—is the main way we tried to make them easier.

Perl was designed to be familiar to C programmers.

No, Perl was designed to be familiar with Unix shell script (with its various variants), sed, and AWK programmers.

I've used perl5 for a long time (although these days I've replaced it with python in my toolchain, although I have my fair share of complaints about python as well) and I think your comparison is unfair.

Rust's sometimes complicated syntax is made necessary by the very concept of the language. You need to be able to express lifetimes, you need to be able to express generics, you need to be able to strongly type lambdas etc... Of course the syntax is going to be a bit more complicated than, say, Common Lisp where everything is dynamic and garbage collected and you can let the runtime figure things out.

Perl 5 was syntactically insane because that's how the authors decided to do it. Effectively it didn't let you express things that were impossible in Lisp, Python, Ruby or JS. It's just a design choice to lean heavily on sigils and magic variables to favor short code even if it can be cryptic to people not intimately familiar with the language. I doubt anybody who hasn't used perl before will be able to figure out exactly what this does (and I'd argue that it's a fairly simple and idiomatic script, not some heinously cryptic code golf):

    while (<>) { chomp(); s/f.o/bar/; print; }

Rust is noisy because it has to represent concepts that simply don't exist in other programming languages.

I'd go even further: Rust does a better job than most languages at letting you only explicitly mention things that need to be explicitly mentioned. Thanks to the very powerful type inference you can write very tidy code, IMO much more so than in C where I have to explicitly type every intermediary variable that I would use for instance.

> Rust is noisy because it has to represent concepts that simply don't exist in other programming languages.

In a few cases having to do with lifetime management and the borrow checker, that's certainly true.

But the example at hand is fundamentally just cloning ideas from Javascript.

The point is not that particular feature. It's how this new feature interacts with a bunch of existing language features.

Actually JS just cloned those ideas from C# and Python.

... and when you get down into the details, there are significant differences in what Rust is doing as opposed to these languages, even if the high level idea is roughly the same.

> 'async as a prefix is intuitive!', but that's only because I saw it first in C#

The analogy made in the post, with the possibility of “expression-oriented” keywords like .match, suggests that `match expr {..}` is equivalent to `expr.match {..}`. So by analogy `await expr` and `expr.await` are also similar.

So why was the "prefix await" syntax dismissed right out of the gate? It is the option that needs the best argumentation, because 1) it is familiar and 2) match is currently a prefix (keyword), so await could probably also be.

Edit: only the await prefix clearly signals a break in control flow, only the prefix variant emphasizes this. In contrast the dot await syntax hides this.

I feel like unusual language syntax isn't an issue, as long as the syntax is understandable/readable once the programmer learns the syntax.

It doesn't take too long to pick up and become comfortable with a new syntax in a programming language.

Imo, the reason some esoteric languages fail are not purely because their syntax is obscure but because even once you learn the syntax, it is still hard to understand the code (example: Brainfuck).

With Rust, once you learn the new syntax, you can understand Rust code with relatively little effort.

> Imo, the reason perl failed was not because the syntax was obscure but because even once you learned the syntax, it was still hard to read perl code.

IMO, the reason Perl failed is that Perl 6 (which is a fairly awesome language in its own right) sucked up all the energy in moving Perl forward for too long and delivered too late, while competing languages kept providing usable progress (and avoided, as a consequence, looking dead, which may be as important as the actual usable progress itself.)

New users expect things to be a bit different by assuming there are good reasons for change of convention.

EDIT: this might very well be the case here though, especially future extension for similar operators and chain-ability.

Right, which is why I mentioned that focusing on readability/maintainability is the right move in this case. I think we're in agreement.

Reply on news.ycombinator.com