Hacker News Reader

Comment by steveklabnik | Hacker News Reader

Which special characters bother you the most? Before 1.0 we largely removed most of them.

::, & (pass by ref?), ! (macros), {:?}, _ => (), whatever is happening in this example with <T> and [T]: fn largest<T>(list: &[T]) -> T {

To be fair, some of these are in Zig too, such as &.

I'm a rust newbie, but I have to disagree.

Your "horror example" is actually very readable for most programmers familiar with either Java, C# or c++, I think. In java or C# it would be something like

    T largest<T>(T[] list)

The major difference being the reference syntax in rust, but that's the price of explicit ownership/no GC.

I love the fact that it's obvious where macros are being used.

_, => and () are originally from ML, so I know it from my university days, but these days you also find some or all of them in C#, Java, Kotlin, ES6. So a lot of programmers have already been exposed to them.

Yeah, I guess

* :: is the same as in many other languages

* & too

* ! is unique, I guess

* The format string stuff is based on ... C#/Python stuff? I forget exactly.

* _ => () is composing three other bits of syntax that aren't unusual on their own

* <> is genrics, like in many languages

* [T] is slices, which are not entirely unique but are also similar to array stuff which uses []s

Thanks for elaborating, it's helpful to understand the perspective.

:: probably looks unfamiliar to anyone who hasn’t worked in C++, PHP, or Perl.

:: is used in Java too, ever since Java 8.

So 50% of Java devs :)

It might be hard for someone who writes Rust every day to see it, but it has a lot of special characters compared to many languages.

It also has less or equal amounts compared to other languages, of course, but I dislike that aspect of those languages too :)

Compare these two listings:

http://rosettacode.org/wiki/Stack#Simple_implementation

http://rosettacode.org/wiki/Stack#Nim

You can see directly that Rust has a lot more there. Obviously Nim skips out on braces so that's a gimme, but I don't really count block braces when I'm talking about special characters. It's more stuff like Option<&'a Frame<T>> or &'a mut T or ->

> It also has less or equal amounts compared to other languages, of course, but I dislike that aspect of those languages too :)

Yeah, thanks, I think this is at the root of a lot of it.

> It's more stuff like Option<&'a Frame<T>> or &'a mut T or ->

Yeah; some of the stuff isn't needed anymore; you can drop the : 'a s, for example. And we have been talking about allowing some more elision, so

  pub struct Iter<'a, T: 'a> { 
      next: Option<&'a Frame<T>>,
  }

could be

  pub struct Iter<'_, T> { 
      next: Option<&Frame<T>>, 
  }

when all is said and done. The '_ in the signature is important so that you know it's parameterized by a lifetime, so we don't plan on ever getting more concise than that.

Steve I wish some of the reg deref stuff used pattern matching for cleanliness instead of &.

I want to say I like you how you guys develop in the open and how you in particular are out and about in the discussions here.

Also, can you make a post someday about your experience with WSL?

> used pattern matching for cleanliness instead of &.

Could you expand on this, I don't quite know what you mean, but I'm interested!

> I want to say I like...

Thanks!

> your experience with WSL?

My experience was, "This is pretty cool!" but, in the end, I don't use WSL anymore and just use regular old Windows. I can elaborate more if you'd like, but it boils down to "basically everything has windows native versions anyway and it works a bit better that way."

    a::b::c::<T>()?  // Rust
    try a.b.c(T)   // Zig

That’s not what Rust looks like normally, though; usually you’d use “use” and the T is inferred.

The :: and <> are also not particularly unusual syntax for their respective features either.

a::b::c is ugly compared to a.b.c whether you put it in an expression or in a use statement and ::<T>()? is not that rare (ex. rdr.read_u16::<BigEndian>()?).

You asked what bothered us, not what was unusual :)

Oh totally! I mean it as a way of sorting out why. Like, it would bother me more if I had to write it more, so maybe it’s that styles are different or some libraries require it more often? byteorder is one of those crates, it’s true, and I don’t use it super often. So this is helpful!

Reply on news.ycombinator.com