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

151–160 of 171 posts

Re: Rust's Ugly Syntax (2023)

#151

Post by needlesslygrim »

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…

I assume it's derived from the OCaml generic type syntax (the first Rust compiler was written in OCaml after all), for example the definition of the type `Option.t` in OCaml:

  type 'a t = 'a option = 
  | None
  | Some of 'a
I think this is the case because IIRC this function:

  fn slice(s: &'a str) -> &'a str { &s[0..2] }
Is generic over the lifetime of `s`, and it I assume it would have been difficult to distinguish generic types and lifetimes.

Re: Rust's Ugly Syntax (2023)

#152

Post by steveklabnik »

needlesslygrim wrote: post #151
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…

I assume it's derived from the OCaml generic type syntax (the first Rust compiler was written in OCaml after all), for example the definition of the type `Option.t` in OCaml: type 'a t = 'a option = | None | Some of 'a I think this is the case because IIRC this function: fn slice (s: &'a str) -> &'a str { &s[0..2] } Is generic over the lifetime of `s`, and it I assume it would have been difficult to distinguish gener…

It’s related yeah. In Ocaml it’s a generic, and in Rust, lifetimes are also a generic type.

Re: Rust's Ugly Syntax (2023)

#153

Post by apatheticonion »

iknowstuff wrote: post #147
carlmr wrote: post #127

Earlier quoted context omitted.

I'm a big Rust fan, but async Rust is an abomination.

I love async Rust. Its implementation is marvelous. Sueper plasant to write now that * async closures * async trait fns, * `impl Trait` everywhere are in place.

Wait up, are async closures in stable now?

Would certainly help with the wild return and type signatures I've had to write involving combinations of `Pin` `Box` & `Future>`.

I think Rust futures are really awesome as they expose the lower level details of how async behavior works, giving the developer the flexibility to adapt it to their use case - but the standard library really dropped the ball on standardized usage/types.

For instance, can we please just have `AsyncRead` and `AsyncWrite` traits? Can they also be easy to implement (are just `async read()`)?

Right now you have to use adapters between Tokio types and the Futures crate and they both offer their own non-interoperable read/write traits.

Re: Rust's Ugly Syntax (2023)

#154

Post by lifthrasiir »

LoganDark wrote: post #141
lifthrasiir wrote: post #47

Earlier quoted context omitted.

It was a good signal to me that you are overthinking into the architecture if that is really required. Rust makes something pretty much impossible in C/C++ possible, but not necessarily easy, and that would be one such example.

> It was a good signal to me that you are overthinking into the architecture if that is really required. Sure, maybe I don't need to statically guarantee the correct execution of code that could easily just throw at runtime instead, but it sure is a fun hobby.

Lifetime subtyping is normally not much necessary to ensure the correctness, provided that you are working at the sufficiently high level (so, say, std is available) and do have some freedom in the design. It often indicates that you are excessively avoiding heap allocations.

Re: Rust's Ugly Syntax (2023)

#155

Post by iknowstuff »

apatheticonion wrote: post #153
iknowstuff wrote: post #147

Earlier quoted context omitted.

I love async Rust. Its implementation is marvelous. Sueper plasant to write now that * async closures * async trait fns, * `impl Trait` everywhere are in place.

Wait up, are async closures in stable now? Would certainly help with the wild return and type signatures I've had to write involving combinations of `Pin` `Box` & `Future >`. I think Rust futures are really awesome as they expose the lower level details of how async behavior works, giving the developer the flexibility to adapt it to their use case - but the standard library really dropped the ball on standardized usa…

It’ll be a nice day when AsyncRead/AsyncWrite lands in stable but I think we should appreciate that it didn’t happen hastily. Now that Linux has uring, Windows has IOCP etc we need to pass ownership of buffers to the kernel instead of passing by reference.

Edit: we use nightly Rust at work so I’m able to use async closures no problem but they’re not quite in stable just yet.

Re: Rust's Ugly Syntax (2023)

#156

Post by needlesslygrim »

steveklabnik wrote: post #152
needlesslygrim wrote: post #151

Earlier quoted context omitted.

I assume it's derived from the OCaml generic type syntax (the first Rust compiler was written in OCaml after all), for example the definition of the type `Option.t` in OCaml: type 'a t = 'a option = | None | Some of 'a I think this is the case because IIRC this function: fn slice (s: &'a str) -> &'a str { &s[0..2] } Is generic over the lifetime of `s`, and it I assume it would have been difficult to distinguish gener…

It’s related yeah. In Ocaml it’s a generic, and in Rust, lifetimes are also a generic type.

Good to know, also cool that you replied!

Re: Rust's Ugly Syntax (2023)

#157

Post by jeroenvlek »

treyd wrote: post #120
jeroenvlek wrote: post #89

Earlier quoted context omitted.

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.

When is someone a Rust developer and why do you assume that I am not one?

edit: -4 points on my parent comment for a totally valid opinion, not violating any commenting guide line (please enlighten me). However, for the down voters: "Please don't use Hacker News for political or ideological battle. That tramples curiosity."

Re: Rust's Ugly Syntax (2023)

#158

Post by blksv »

mst wrote: post #133
blksv wrote: post #60

Earlier quoted context omitted.

I strongly support your point, but the example is still sand-in-the-eyes for me. I hold that one symbol should not alter the semantics of a program and there should never ever be sequences of one-symbol syntactic elements. In an Ada-like language, it would be something like generic type Path_Type implements As_Path_Ref; type Reader implements IO.File_Reader; function Read(Path: Path_Type) return Reader.Result_Vector_…

Huh. My brain says logically I should find that better, but the -lack- of punctuation is making it really tricky to skim read the way I do most languages. I'm not arguing the example you found sand-in-the-eyes is necessarily good but my mental skim reading algorithm copes with it much better.

It is indeed harder to skim, and I find myself much more relying on syntax highlighting and file outline when working in Ada than in C++. Not due to the lack of punctuation, though, which is in place but serves the guiding role only (it is MLs that tend to abolish all the unnecessary punctuation), but because of the overall dense style.

But while it is harder to _skim_, it is easier to _read_, as you don't have to concentrate on and decipher the syntax, risking to miss some of the crucial elements (oh, how do I hate missing ampersands in C++!).

Re: Rust's Ugly Syntax (2023)

#159

Post by mrweasel »

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

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

> Do you really think this would be more readable?

Much more readable, I can just browse the code, and see: Hey a macro.

I mostly write Python, but sometimes have to read, debug and modify C, Java, PHP, JavaScript, Bash and so on. Having code being easily readable and obvious is a huge win.

Very often your code has to be read, and reasonably understood by someone who doesn't exactly know the language, or at least is much less proficient. They don't need to be able to do complex task or debug the inner most workings of your code, but they do need to be able to reason about it, quickly, if you want them to contribute with patches or detailed bug reports.

Re: Rust's Ugly Syntax (2023)

#160

Post by [deleted] »

cozzyd wrote: post #123
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…

Not sure why you'd compare modern C++ to K&R which is a C book. Modern C is in fact less ugly than ancient C due to sugar like compound literals.

[deleted]
Post reply on HN