Hacker News Reader

Comment by eklavya | Hacker News Reader

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

View on HN

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.

`()` 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.

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

Reply on news.ycombinator.com