Hacker News Reader

Comment by eklavya | Hacker News Reader

There might be some reasons to have <> instead of [] for specifying Type arguments (I think [] are a lot easier to read). I can't fathom the reasoning behind choosing "::" instead of a ".".

View on HN

The reason for <> instead of [] is that both are just as ambiguous to Rust's grammar, and that <> is, unfortunately, more-or-less the industry standard (C++, Java, and soon Swift). I would personally prefer something akin to D's generic syntax (but with a different symbol, since the exclamation point already has meaning in Rust).

The reason for using :: instead of . for paths is because the Rust developers did not want to conflate path lookup and field lookup, which would obscure the runtime costs of indirection. (This is also the same reason why you can't omit the parens when calling a method with no arguments: a field lookup and a method call have wildly different runtime costs.)

Thanks for shedding the light. I really really wish they had chosen [] instead of <>. I use Scala and I have fallen in love with how clean [] looks.

Good to know the reasoning behind ::.

Waiting for Rust 1.0, after it gets released it's Scala for JVM and Rust for everything else (except Qt) :P

Here's a recent RFC closed by its author on the subject: https://github.com/rust-lang/rfcs/pull/148

(a big issue with []-generics is that they're easy to confuse with indexing/slicing to a human. <> may look noisy, but it's harder to confuse it with comparisons)

Interesting that you won't replace Qt with Rust, because I'm considering doing it. The reasons:

- Qt core (QList, QMap) can be replaced with Rust std lib

- I don't use QML and Javascript (because Javascript errors don't show up at compile time)

- The only thing missing from Rust is QWidgets, but I'm sure there will be something to replace it

I wouldn't like to use a Rust port of Qt just to get QWidgets for Rust, because it would also mean shipping huge Qt core libraries with my Windows application. I don't need them so I don't want to do that.

You list Qt core but that's not what I use Qt for. I use it to make GUI apps and it's pretty darn good at it.

QML is the way forward for making GUI apps, you are not supposed to use javascript much (although you can make complete apps with it). You are supposed to have your complex logic in a C++ backend which interacts with the QML frontend.

Maybe QML will have Rust bindings.

What I like about Scala is the use of () for indexing arrays. It feels like a more uniform syntax - indexing an array is conceptually like calling a function from int to elements of the array - and I guess it reduces parsing ambiguity w.r.t. generics.

Though apparently this couldn't be used in Rust, since they want both traits for indexing ( [] ) and calling like a function ( () ) on types that implement those respective traits.

Matlab uses () for indexing, and I find it awful - you can't tell the difference between indexing and function calls, making code much harder to understand and reason about. It can be pretty confusing for people learning, too (I teach it to undergrad engineers, and don't get a say in the language choice).

`()` is now overloadable, so one could implement that operators for arrays/vectors/slices to get indexing via ().

Not `map[k] = v;`, which is deal breaker.

Other languages don't offer indexing sugar at all, so even minimal sugar for retrieving elements might be nice. There are however, more significant road blocks, like how to handle returning references (basically, we would be left in a similar situation to the current Index trait, which has its uses, but isn't what most indexing should do).

Right, that too, no first-class lvalues in Rust.

Honestly, it's kind of sad that things are chosen because they're industry standard, instead of how good/nice they are. After using Scala, I think that []'s are much easier on the eyes than <>'s.

When designing a language, you have to decide which hills are worth dying on. Uglier it may be, but if using <> makes our syntax more immediately recognizable to C++ developers, then we have a better chance of succeeding in bringing safety to the low-level niche where C and C++ reign supreme.

Don't worry, once Rust has established a foothold here, then we can start designing the pretty language that will usurp it. :)

I really really hope it changes to [] in future. I am scared of the code with lots of <>, I don't know why but I lose context.

I agree with that. Having worked with languages which use <> and Scala, [] are just magnitudes more readable when expressing the same types.

I hate the `<>`s, but the semantics are enticing enough for me to do all of my current personal projects in Rust. I would love Haskelly syntax, but life is never perfect... maybe somebody will make a pre-processor or something! Haha.

I agree, it's not a deal-breaker. It's just that freezing something into a language forever because it's easier for someone just starting out feels wrong. Once you're familiar with the language, you have to deal with the ugliness forever.

I'm not sure what you're saying here, do you mean like in 'std::gc::Gc<T>' ?

Using :: to indicate a submodule has tons and tons of precedent. The only prominent example I can think of is PHP, and there was a ton of outrage when it didn't use ::.

Language design error: syntax error, expected T_PAAMAYIM_NEKUDOTAYIM

I maybe be remembering some of these wrong, but I think these don't use :: (mostly . instead): Java, C#, Haskell, Clojure.

I don't know about Clojure, but . in Java is ambiguous in the grammar, since it's also used for method calls. And . is function composition in Haskell. I can understand why Rust would want a different sigil.

I think I saw some proposal to replace the function composition from prelude (.) with some other symbol, and presumably making it illegal to define operators named (.). This would of course break a lot of code, but it seems simple enough to make a largely automated transition.

The reason for the proposal was that (.) for function composition made the grammar more complex or problematic because of the accessing 'operator' (.), and/or something that had to do with more fancy accessing and such (lenses?).

If it's meant to signify paths, why not use the sigil that everyone uses for path separation, i.e. /

Because this is ambiguous in any language that uses that same character as the division operator. The compiler wouldn't be able to tell whether `foo/bar + 2` is "divide foo by bar, then add two" or "add two to the bar item found in the foo namespace".

Theoretically it's solvable by requiring whitespace to surround all arithmetic operators, which is actually a bit of an intriguing proposition because it would then also allow you to use dashes in variable names and have it be unambiguous, i.e. `foo-bar/qux - baz / spam` would unambiguously mean "divide baz by spam, then subtract it from qux in the foo-bar namespace". But nearly all languages try to avoid this sort of whitespace dependence (look at the ancient furor over the `> >` requirement in C++), and it would be quite a reach for Rust to start championing it now.

Something has precedent doesn't mean you ought to do it. kibwen explains the reason above.

While this is true, that doesn't mean precedent is irrelevant. While what kiwiben said is true, https://github.com/rust-lang/rfcs/pull/148#issuecomment-4771...

Reply on news.ycombinator.com