[seppo0010]

That's a fair criticism, and well taken, but keep in mind I'm learning the language as I go, and most of the commits are just rewriting things because they were suboptimal, not idiomatic, or hard to read. At this stage, I would consider adding comments wasteful.

I also have no intention of making this project live as long or have as many users as Redis does.

[illumen]

Learning to write readable code is a good thing I think worth the effort.

Can rust be readable?

[seppo0010]

If you want good examples of Rust code, you should probably look into other repositories. Today I was checking out how Rust's HashMap works and I found it quite readable:

https://github.com/rust-lang/rust/blob/master/src/libstd/col...

You can also look at `mio`, the asynchronous IO library that's popular in Rust:

https://github.com/carllerche/mio/blob/master/src/notify.rs#...

[anonfunction]

I would hardly say this is readable:

    fn search_entry_hashed<'a, K: Eq, V>(table: &'a mut RawTable<K,V>, hash: SafeHash, k: K)
        -> Entry<'a, K, V>

[pygy_]

I don't know Rust, and the only thing opaque to me in that line is the `'a` syntax. I suppose it is related to memory safety.

In plain English:

`search_entry_hashed` is a parametric function. It works in a type safe way on any kind of K and V. It takes as arguments a reference to a mutable hash table, a hash function and a key, and returns an `Entry` object whose precise type depends on the type of the parameters.

You could hardly express that more succinctly. You can't understand it by skimming it, but it is a complex definition.

[Tuna-Fish]

Your guess about 'a is correct. 'a is here used to signify that the return value can only be safely used while the value table exists and is not being concurrently modified. This implies that the value is not copied on return, but only a reference into the table is returned.

[pygy_]

I'm surprised that RawTable isn't parametrized on the type of hash function. Something like this (possibly wrong way to express it, but you get the idea)

    fn search_entry_hashed<'a, K: Eq, V, H: SafeHash>(table: &'a mut RawTable<K,V,H>, hash: H, k: K)
        -> Entry<'a, K, V>

[Jweb_Guru]

It could be inferred in some languages (notably MLs).

[pygy_]

Including parametrization?

[pornel]

In Rust it's unfortunately typical to give one-letter names to generic types. A verbose version could be:

   fn search_entry_hashed<'lifetime, KeyType: Eq, ValueType>
      (table: &'lifetime mut RawTable<KeyType, ValueType>, hash: SafeHash, key: KeyType)
      -> Entry<'lifetime, KeyType, ValueType>

[Jweb_Guru]

"'lifetime" gives no useful semantic information there. All 'somethings are lifetimes; it would be like naming a type parameter "Type," or a variable "variable." If you don't have a specific shard context that would give the name meaning, `'a` is as good as any. I do agree that something like Key or Value would probably be better than K or V.

[nemaar]

Yes, in general, it is a good idea to give more descriptive names but in the context of a hashtable, K and V are good enough. I seriously doubt that there is anyone reading the source code of a hashtable and cannot figure out in milliseconds what K and V mean (how fast is the human brain?:).

[rmc]

Depends if you know Rust. The language can do things with types and memory that (say) something like Python or Ruby don't do, which means Rust needs extra syntax to mark those things. Most of the <> or ' are to do with types or memory safety.

[yaongi]

It's alright.