Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust's Ugly Syntax (2023)

matklad.github.io

Post reply on HN
Print view View original

111–120 of 171 posts

Re: Rust's Ugly Syntax (2023)

#111

Post by steveklabnik »

_answ wrote: post #104
dmurray wrote: post #92

Earlier quoted context omitted.

> And the clumsy Arc >> makes users feel bad about using runtime cost paid types Yeah, this would look worse than any of the "complicated syntax" examples in the blog post. A language should be designed so that the typical case is the easiest to read and write. Syntax for the most common abstractions. Rust forces you to be explicit if you want to do an Arc >>, but lets you inherit lifetimes almost seamlessly. That me…

Simple != idiomatic. It's perfectly idiomatic to `Arc >` in Rust, and it is more complex because it deals with more concerns than a simple reference, namely being thread-safe. Sometimes you need that, sometimes not, but you have to be explicit about it.

There’s no reason to have a Box there, because Arc already boxes.

Re: Rust's Ugly Syntax (2023)

#112

Post by the_mitsuhiko »

mrweasel wrote: post #69
the_mitsuhiko wrote: post #64

Earlier quoted context omitted.

> The use of ' as a symbol that has any meaning on it's own has got to be one of the most stupid choices I've seen in a language Can you clarify why you have that opinion? What would your syntax suggestion have been?

Because pretty much any other language has '...' for strings, or at least something to do with text. It's also a character that in all other languages (that I know of) must be closed with another '. Now you could say, we don't close it in contractions in English, so there's a case where one ' can just exist on it's own. That's sort of fine, a bit outside of the realm of programming, but fine, but then I think you sho…

> So you have something that has a ' in front, is that a lifetime, or a missing ' later?

Not once has this come up for me. They are in completely different places syntactically and can never overlap.

Sure, `'` might be text related in a lot of languages but definitely not universally. In LISP 'foo is shorthand for (quote foo) and also does not have a second character. Ocaml uses 'foo for types and foo' is just a valid identifier. Standard ML also has 'foo for type variables and I believe also allows identifiers named foo'. Haskell allows identifiers named foo' as well.

Maybe it's odd coming from languages you are familiar with, but it's not at all something that is unique to Rust.

> Rust does this with ! as well if I understand correctly

I am not sure how the case with ! is similar. Macros just end with ! to make them clearer visually, it's not part of an operator. There can never be any syntax ambiguity with them, neither visually or lexically. Also what would be the point. Take this example:

    try!(do_something(...)).further();
Do you really think this would be more readable?

    (macro try(do_something(...))).further();

Re: Rust's Ugly Syntax (2023)

#113

Post by Brian_K_White »

kitkat_new wrote: post #107
Brian_K_White wrote: post #103

Earlier quoted context omitted.

It's more like if a ; was allowed somewhere else and had a different meaning there. enum foo; blah ...;

like parenthesis for functions, tuples and for denoting prioritized evaluation?

[flagged]

Re: Rust's Ugly Syntax (2023)

#114

Post by kitkat_new »

Brian_K_White wrote: post #113
kitkat_new wrote: post #107

Earlier quoted context omitted.

like parenthesis for functions, tuples and for denoting prioritized evaluation?

[flagged]

absolutely yes.

I even gave three different places where parenthesis can be used and have different meanings

Re: Rust's Ugly Syntax (2023)

#115

Post by K0nserv »

jiwangcdi wrote: post #91
K0nserv wrote: post #59

Earlier quoted context omitted.

That's orthogonal. If the type was `&[u8]` instead of `Path` the type signature would be: pub fn read >(path: P) -> Result > The reasons for it to be generic and us `AsRef` remain. The reason for Path over &[u8] is, AFAIK, because not all byte slices are valid paths on all OSs, but also because a dedicated type lets the standard library add methods such as `Path::join`

So abstraction is still a point, but Rust cares about memory layout as well.

Sort of, this API enables static dispatch, but it could also have been written as

   pub fn read>(path: &dyn P) -> Result>
In which case the size of `path` is always the same(two words[0]) and the same machine code could be used regardless of how the function is called. Rust still cares about the memory layout but because `&dyn AsRef` has the same layout for all implementations of `AsRef` there's no need for monomorphization[1].

0: https://doc.rust-lang.org/1.80.1/reference/types/trait-objec...

1: https://rustc-dev-guide.rust-lang.org/backend/monomorph.html...

Re: Rust's Ugly Syntax (2023)

#116

Post by Brian_K_White »

kitkat_new wrote: post #114
Brian_K_White wrote: post #113

Earlier quoted context omitted.

[flagged]

absolutely yes. I even gave three different places where parenthesis can be used and have different meanings

You can also use the letter a in 3 dufferent places and have different meanings, and is also not an example.

Re: Rust's Ugly Syntax (2023)

#117

Post by dwattttt »

Brian_K_White wrote: post #103
kitkat_new wrote: post #93

Earlier quoted context omitted.

why? It makes type information unnecessarily longer without adding information, and feels like writing "end_stm" instead of ";" after every line

It's more like if a ; was allowed somewhere else and had a different meaning there. enum foo; blah ...;

Perhaps a better example would be & referring to AND operations (logical and bitwise), but also being a unary operator for taking the address of a variable.

Re: Rust's Ugly Syntax (2023)

#118

Post by WhyNotHugo »

Filligree wrote: post #68
the_mitsuhiko wrote: post #65

Earlier quoted context omitted.

It's worth pointing out here for people not familiar with Rust, that this is the result of code generation by a third party crate to enable async methods on traits.

Which isn't even needed anymore; now the compiler accepts it without any macros.

The compiler only supports these for static dispatch, the above use case relies on dynamic dispatch.

Re: Rust's Ugly Syntax (2023)

#119

Post by Dagonfly »

Filligree wrote: post #68
the_mitsuhiko wrote: post #65

Earlier quoted context omitted.

It's worth pointing out here for people not familiar with Rust, that this is the result of code generation by a third party crate to enable async methods on traits.

Which isn't even needed anymore; now the compiler accepts it without any macros.

Well, you can't use the `async` keyword version if you need the `Send` bound.

Imo, Rust should introduce some syntax like `async(dyn+Send)` that desugars to `Box + Send>`. This solves most of the async wards if you don't care about heap allocation and perfect performance.

Re: Rust's Ugly Syntax (2023)

#120

Post by treyd »

jeroenvlek wrote: post #89
mrweasel wrote: post #63

Earlier quoted context omitted.

The use of ' as a symbol that has any meaning on it's own has got to be one of the most stupid choices I've seen in a language. It's made worse by the fact that you can still use '...' as s character literal. Not only is is incredibly ugly it's also rather confusing, but it fits well into how I view Rust, complicated for the sake of making the developers look smart. It wouldn't fit the syntax of the language obviousl…

A lifetime keyword would actually go a long way in improving ergonomics. You could even make it synonymous with '. Then people can choose. Maybe one will get much more traction and the other can be deprecated.

The only calls to change the lifetime syntax have been coming from "outside the house". Rust developers are fine using the ' as the lifetime sigil and there are no calls from within the Rust community to change it. Adding a keyword would increase the verbosity substantially.
Post reply on HN