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

81–90 of 171 posts

Re: Rust's Ugly Syntax (2023)

#81

Post by swiftcoder »

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…

Lisp variants have used the ' prefix as shorthand for the quote operator (interpret whatever comes next as a literal, instead of evaluating it) since about the time C became popular...

Re: Rust's Ugly Syntax (2023)

#82

Post by zarzavat »

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

With any language there’s an active part of the community and then there’s the “dark matter” of people who use the language but are not actively involved in shaping its direction, forums or subreddits, etc.

Of course the people who are actively involved are likely to be of the opinion that all the complexity is necessary, but I doubt that applies to the broader Rust userbase.

Re: Rust's Ugly Syntax (2023)

#83

Post by steezeburger »

mrweasel wrote: post #72
toolslive wrote: post #71

Earlier quoted context omitted.

in OCaml, the single quote is a valid char for an identifier: let f = ... and let f' = ...

I did not know that, and I question that choice as well. Why would you use that? It's a little less bad, because you can just have your own style guide that says "Don't do that".

It's common math notation to have f and f prime to represent something derived from f.

Re: Rust's Ugly Syntax (2023)

#84

Post by swiftcoder »

zerodensity wrote: post #67
sk11001 wrote: post #34

Earlier quoted context omitted.

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

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

Indeed. Rust is really crying out for a real CTFE implementation + richer macros to replace the mess that is procmacros (I really don't want to have to run an arbitrary external binary with full system access just to manipulate the AST...)

Re: Rust's Ugly Syntax (2023)

#85

Post by kelnos »

oguz-ismail wrote: post #7

The final version is still ugly. Why `pub fn'? Why is public not the default and why do you have to specify that it's a function? Why `: type' and `-> type', why can't type go before the identifier? Why do you need `File::' and `Bytes::'? What is that question mark? Why does the last statement not need a semicolon? It's like the opposite of everything people are used to.

> Why `pub fn'?

I prefer it this way; defaults should be conservative or more common: I write many many more private functions than public. I'm not sure what your objection to 'fn' is... seems like a superficial problem. It likely makes the language easier for the compiler to parse, and to me, it makes it easier to read.

> Why `: type' and `-> type', why can't type go before the identifier?

Because putting the type afterward is more ergonomic. If you're used to C/C++/Java/etc. it feels weird, but once you start writing code with the type after the declaration, it feels much more natural.

> Why do you need `File::' and `Bytes::'?

I'm not sure what you mean here. They're types. You have to specify types.

> What is that question mark?

The question mark is basically "if the Result is Ok, unwrap it; if it's an Err, return it immediately."

> Why does the last statement not need a semicolon?

Leaving off the semicolon returns the last expression from the block.

> It's like the opposite of everything people are used to.

Maybe if your experience with programming languages is fairly limited...

Re: Rust's Ugly Syntax (2023)

#86

Post by kelnos »

mFixman wrote: post #35
uasi wrote: post #19

Earlier quoted context omitted.

Your points have nothing to do with ugliness. > Why `pub fn'? Why is public not the default and why do you have to specify that it's a function? If public were the default, you'd end up having to make other functions `priv fn` instead. > Why `: type' and `-> type', why can't type go before the identifier? It's easier to parse, and most major typed languages other than C/C++/C#/Java put the type after the identifier.…

> If public were the default, you'd end up having to make other functions `priv fn` instead. My guilty pleasure is Go's visibility system, where all functions that start with lowercase are private to the scope of the current class/file and all Functions that start with Uppercase are public. It doesn't look but it would work and it's a mess when you need acronyms, but it somehow works great and the result looks nice.

I actually really dislike Go's system! Casing, to me, shouldn't be significant. (Just like I dislike how whitespace is significant in Python.) And to me it just doesn't look nice, but I also prefer snake_case over camelCase and PascalCase.

Re: Rust's Ugly Syntax (2023)

#87

Post by kitkat_new »

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…

> Because pretty much any other language has '...' for strings, or at least something to do with text.

The ' aren't used in places where strings occur (strings just don't make sense there anyways), don't take up to much space (i.e. give more space to the name).

I am not a Rust pro, but this has never been an issue for me, same for ! for macro expansions.

Re: Rust's Ugly Syntax (2023)

#88

Post by Ygg2 »

lelanthran wrote: post #66
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?

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

> Is the syntax suggestion not applicable?

Lets look at proposed syntax

  fn list_items(
         &lifetime life0 self,
         collection_href: &lifetime life1 str,
     ) -> Pin, Error>> + Send + async_trait>>
     where
         Self: life0,
         life0: async_trait,
         life1: async_trait,
I'm not going to pretend I understood what mrweasel meant fully, so I assume we can either omit generic or in parameter declaration (so I went with omitting lifetime keyword in parameters):

  fn list_items(
         &life0 self,
         collection_href: &life1 str,
     ) -> Pin, Error>> + Send + async_trait>>
     where
         Self: life0,
         life0: async_trait,
         life1: async_trait,
I guess you might be able to omit the "generic part" like so (it might be impossible, lifetime are just generics useful for lifetime tracking):

  fn list_items(
         &lifetime life0 self,
         collection_href: &lifetime life1 str,
     ) -> Pin, Error>> + Send + async_trait>>
     where
         Self: life0,
         life0: async_trait,
         life1: async_trait,
In both cases, you get a huge verbosity increase, and mix between not knowing if a value like `Self: x` is a trait with lower case or a lifetime.

So you trade verbosity for more ambiguity and programmer confusion, and possibly worse error reporting (is &a b a lifetime or a missing comma e.g. &a, b).

Re: Rust's Ugly Syntax (2023)

#89

Post by jeroenvlek »

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…

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.

Re: Rust's Ugly Syntax (2023)

#90

Post by lifthrasiir »

GoblinSlayer wrote: post #77
mrweasel wrote: post #69

Earlier quoted context omitted.

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…

In rust "macro" would be abbreviated to "mac".

Rust does reserve the exact `macro` keyword for the eventual replacement of `macro_rules!` [1] [2]. But it is unlikely to be used in the invocation syntax because that will be too verbose.

[1] https://doc.rust-lang.org/reference/keywords.html

[2] https://github.com/rust-lang/rust/issues/39412

Post reply on HN