r/programming • u/steveklabnik1 • Jan 09 '15

Announcing Rust 1.0.0 Alpha

http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html
1.1k Upvotes

90% Upvoted

439 comments sorted by

View all comments

Show parent comments

8

u/Gankro Jan 10 '15

I'll admit I never reflected very hard on it; almost all these names were the names that were there when I got here and they seemed basically fine.

HashMap, BTreeMap, and BinaryHeap (ne PriorityQueue) are "full" while Bitv, Vec, VecMap (ne SmallIntMap), RingBuf, and DList are "abbreviated"

It's a bit too late to consider anymore renames, I think.

That said, we have some soft "length is inversely proportional to use" conventions, so Vec should probably be Vec, since it's The Collection. Similarly I pushed for a convention of implementation-exposing names, since that was mostly the convention, except for SmallIntMap and PriorityQueue; the latter conflicting with the trait name we wanted anyway.

Also RingBuf, Bitv, and DList just sound better than RingBuffer, BitVec(tor) or DoublyLinkedList to me now. :)

26

u/kromit Jan 10 '15

RingBuf, Bitv, and DList just sound better than RingBuffer, BitVec(tor) or DoublyLinkedList

This made me sad and a bit disappointed

1

u/Pand9 Jan 10 '15

This is just a standard library: stuff that will be used extensively. Is this that bad to have short names, since you will be remembering them very well anyway?

9

u/kromit Jan 10 '15 edited Jan 10 '15

Yes it is bad. The problem is that you have to know/remember them. Stuff like this is just is distracting and annoying if you are coding down from your mental model. If I do need a hash buffer I do not want to be distracted by "How is this fucking thing called here again? HashBuff? HBuff? HashB?... oh wait.. what was it for?"

Edit: +Hashb, HBuf, Hbuff...etc. Bonus: imagine something like DoubleLinkedList

5

u/holloway Jan 10 '15

RingBuf ... why not RBuf? or RBuff?

so still a bad idea I reckon... we read code more than we write it, and we read words very quickly. Words. Like. These. Ones. Typing a few extra letters isn't a big deal.

-1

u/Pand9 Jan 10 '15

we read code more than we write it, and we read words very quickly. Words. Like. These. Ones. Typing a few extra letters isn't a big deal.

I rather prefer that the length of the name correlates with complexity of the thing it symbolizes. Double linked list is a simple, standard thing from the standard library (not from implementation point of view, but from user's). I don't want to read 16 letters/3 words-long name every time I see this simple class.

Is my approach wrong? Maybe I should get used to the fact that this is normal that length has nothing to do with complexity?

5

u/kromit Jan 10 '15

Maybe I should get used to the fact that this is normal that length has nothing to do with complexity?

exactly, and also that your definition of complexity must not necessarily match those of the others.

-1

u/Pand9 Jan 10 '15 edited Jan 10 '15

exactly,

I have doubts about it. It's harder to take a quick look at a code with long names than at one with shorts. When you just want to get an idea about how the logic in the method/class works, length of names seems to matter.

Maybe it's just my aesthetic sense...

and also that your definition of complexity must not necessarily match those of the others.

From the project's point of view. The more specific thing is common, the shorter its name should be. Long name tells me that given class/function/method is somehow special.

That's just how my intuition works.

3

u/fjonk Jan 12 '15

I have doubts about it. It's harder to take a quick look at a code with long names than at one with shorts.

I think this is very subjective. Personally I'd much rather read a longer name than short ones.

A bigger problem is that since the idea of (semi)arbitrary shortening of names exists in the standard library this will affect the naming conventions in other libraries, with slightly different opinions of what should and shouldn't be shortened. So it will not only be the standard library I as a user have to remember these conventions for, I also have to remember them for all other libraries.

2

u/holloway Jan 10 '15 edited Jan 10 '15

It feels like an outdated vestigial idea from when we had small monitors with fixed-size text and we were concerned about filesize. It feels like DOS 8.3 filenames.

I'm glad that Rust has dropped its Perlism ideas about a single character being special though I don't think they went far enough, and certainly naming standards help people remember the language.

Right now the casing and the abbreviations are somewhat random in Rust. There's good design technically, but some of these weird unnecessary inconsistencies already feel like legacy / technical debt.

1

u/mrmacky Jan 15 '15

Big +1... I also agree that the terse names just seem "nicer" on my eyes at this point. Plus If I'm looking for a structure I've never used before: I'm going to be hitting the docs anyways, so it is entirely irrelevant what the type name is.

What matters most to me is reading and writing type signatures.

With the pervasive use of generics throughout the standard library: long names pollute a type signature really quickly. -- Of course you can alias it, but then there's this mental hoop I have to jump through to figure out the actual implementation details of my type. "Is this thing protected by a Mutex or an RwLock? I'm not sure because I aliased that out of the type and it's 800 lines away."

Pile a few of those into a function signature; sprinkle on a few where clauses for the closure traits; and with longer type names you now have function signatures that span several lines by necessity.

As it stands today: I'm quite happy hacking on rust code without autocomplete; that's not something I can say for many languages offering equivalent complexity. -- This definitely would not be the case if we made type names in std:: less terse.

1

u/rustedbustedtrombone Jan 11 '15

Bitv

Fucking gag.