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

61–70 of 171 posts

Re: Rust's Ugly Syntax (2023)

#61

Post by zarzavat »

cdogl wrote: post #37
d_tr wrote: post #27

Earlier quoted context omitted.

> Most people would probably be better served by a language that was a tiny bit slower but had better developer productivity. D maybe? D and Rust are the two languages which come to mind when I think about "possible C++ replacements".

When GP said “most”, I interpreted it more broadly. Most applications simply do not require the guarantees of a non-GC language. When you expand that horizon, list of contenders becomes considerably larger - even when restricted to statically typed languages.

Yes for example many Python users switched to Go, a native code GC language, and are satisfied with the performance.

There’s also the middle ground of Swift’s memory management which uses compiler-elided refcounting - i.e. the compiler detects when a count goes up then down again and removes those operations.

Re: Rust's Ugly Syntax (2023)

#62

Post by scotty79 »

demurgos wrote: post #32
mjburgess wrote: post #9

Kinda disingenuous, you don't reskin one language in another to make an argument about syntax -- you develop a clear syntax for a given semantics. That's what rust did not do -- it copied c++/java-ish, and that style did not support the weight. When type signatures are so complex it makes vastly more sense to separate them out, Consider, read :: AsRef(Path) -> IO.Result(Vec(U8)) pub fn read(path): inner :: &Path -> I…

People may disagree on specifics, but you're definitely right that being able to separate the function signature from its definition would be very helpful in complex cases.

Why? You can easily find parameter names in the signature if you just put them on separate lines. For me there's very little reason of putting them all together on separate line after the signature. And then when you look for a type of a parameter you know the name of, it gets difficult.

Re: Rust's Ugly Syntax (2023)

#63

Post by mrweasel »

WhyNotHugo wrote: post #54
sedatk wrote: post #2

I think the article makes a good point, but the actual example isn’t Rust’s worst, not even close. It gets really hard to follow code when multiple generic types are combined with lifetime markers. Then it truly becomes a mess.

Here's a nice example of a Trait that has async functions: fn list_items ( &'life0 self, collection_href: &'life1 str, ) -> Pin , Error>> + Send + 'async_trait>> where Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait, Rendered docs: https://mirror.whynothugo.nl/vdirsyncer/v2.0.0-beta0/vstorag... Source: https://git.sr.ht/~whynothugo/vdirsyncer-rs/tree/v2.0.0-beta...

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 obviously, but why not simply have the developer prefix the variable with the keyword "lifetime", rather than assigning a symbol. It seems a little like starting functions in Go with a upper case letter to export them, dude just give us an export keyword, it's fine.

Re: Rust's Ugly Syntax (2023)

#64

Post by the_mitsuhiko »

mrweasel wrote: post #63
WhyNotHugo wrote: post #54

Earlier quoted context omitted.

Here's a nice example of a Trait that has async functions: fn list_items ( &'life0 self, collection_href: &'life1 str, ) -> Pin , Error>> + Send + 'async_trait>> where Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait, Rendered docs: https://mirror.whynothugo.nl/vdirsyncer/v2.0.0-beta0/vstorag... Source: https://git.sr.ht/~whynothugo/vdirsyncer-rs/tree/v2.0.0-beta...

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…

> 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?

Re: Rust's Ugly Syntax (2023)

#65

Post by the_mitsuhiko »

WhyNotHugo wrote: post #54
sedatk wrote: post #2

I think the article makes a good point, but the actual example isn’t Rust’s worst, not even close. It gets really hard to follow code when multiple generic types are combined with lifetime markers. Then it truly becomes a mess.

Here's a nice example of a Trait that has async functions: fn list_items ( &'life0 self, collection_href: &'life1 str, ) -> Pin , Error>> + Send + 'async_trait>> where Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait, Rendered docs: https://mirror.whynothugo.nl/vdirsyncer/v2.0.0-beta0/vstorag... Source: https://git.sr.ht/~whynothugo/vdirsyncer-rs/tree/v2.0.0-beta...

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.

Re: Rust's Ugly Syntax (2023)

#66

Post by lelanthran »

the_mitsuhiko wrote: post #64
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…

> 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?

>> It wouldn't fit the syntax of the language obviously, but why not simply have the developer prefix the variable with the keyword "lifetime", rather than assigning a symbol.

...

>> 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

> What would your syntax suggestion have been?

Is the syntax suggestion he provided not applicable?

Re: Rust's Ugly Syntax (2023)

#67

Post by zerodensity »

sk11001 wrote: post #34
zarzavat wrote: post #16

Earlier quoted context omitted.

My reading is: people use Rust because it’s fast but then they complain about the semantics that make it fast. In other words, be careful what you wish for. Most people would probably be better served by a language that was a tiny bit slower but had better developer productivity. However, once you deviate from the goal of “as fast as possible”, then you have to choose which parts you want to sacrifice speed for produ…

> people use Rust because it’s fast but then they complain about the semantics that make it fast. I don't think most people use Rust because it's fast - fast is nice but Rust is being thrown at a bunch of use cases (e.g. backend services and APIs) for which it replaces "slower" garbage collected languages (the language being faster doesn't always make the overall product/service faster but that's a separate question)…

> I don't think this is true either - a large part of the Rust community seem to think that it's as complicated as it needs to be. As a beginner/outsider, I found it kind of cumbersome to get started with, but that's certainly not everyone's opinion.

Personally I feel it's not complicated enough. Where is my function overloading, variadic templates and usable compile time reflection? (Sure you can sometimes use macros but ew macros)

Re: Rust's Ugly Syntax (2023)

#68

Post by Filligree »

the_mitsuhiko wrote: post #65
WhyNotHugo wrote: post #54

Earlier quoted context omitted.

Here's a nice example of a Trait that has async functions: fn list_items ( &'life0 self, collection_href: &'life1 str, ) -> Pin , Error>> + Send + 'async_trait>> where Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait, Rendered docs: https://mirror.whynothugo.nl/vdirsyncer/v2.0.0-beta0/vstorag... Source: https://git.sr.ht/~whynothugo/vdirsyncer-rs/tree/v2.0.0-beta...

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.

Re: Rust's Ugly Syntax (2023)

#69

Post by mrweasel »

the_mitsuhiko wrote: post #64
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…

> 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 should remove then '...' usage. It's really confusing that the same character has two different meanings depending on something that happens later. Rust does this with ! as well if I understand correctly, so it's NOT like everywhere else, but something!() is macro expansion... Why not just prefix with "macro" so macro something()

So you have something that has a ' in front, is that a lifetime, or a missing ' later? The compiler will catch it, so it not a problem in that sense, it just makes it hard to read the code.

Personally I would almost always prefer a keyword. For Rust I think my problem is that the language is a little to happy with symbols and operators being one character picked for the none numbers and letters and the choice of ' makes it seem like they are running out of characters to choose from. Like we just one or two features away from assigning meaning to § and €.

Re: Rust's Ugly Syntax (2023)

#70

Post by remcob »

gary_0 wrote: post #51
oneshtein wrote: post #13

Earlier quoted context omitted.

How to return an error in your example?

pub fn read(path: Path) -> Result { File::open(path)?.read_to_end() } isn't so bad either.

Exactly, and this is in my experience what most Rust code ends up looking like.

It compromises a bit on generality and (potential) performance to achieve better readability and succinctness. Often a worthwhile trade-off, but not something the standard library can always do.

Post reply on HN