f tweak docs explaining why different Score

Author: TheBlueMatt

lightning/src/routing/scoring.rs

@@ -63,17 +63,17 @@ use core::ops::{DerefMut, Sub};
 use core::time::Duration;
 use io::{self, Read}; use sync::{Mutex, MutexGuard};
 
-/// We define Score ever-so-slightly differently based on whether we are being build for C bindings
+/// We define Score ever-so-slightly differently based on whether we are being built for C bindings
 /// or not. For users, `LockableScore` must somehow be writeable to disk. For Rust users, this is
 /// no problem - you move a `Score` that implements `Writeable` into a `Mutex`, lock it, and now
 /// you have the original, concrete, `Score` type, which presumably implements `Writeable`.
 ///
 /// For C users, once you've moved the `Score` into a `LockableScore` all you have after locking it
 /// is an opaque trait object with an opaque pointer with no type info. Users could take the unsafe
 /// approach of blindly casting that opaque pointer to a concrete type and calling `Writeable` from
-/// there, but downstream bindings users (e.g. Java users) can't even do that. Instead, we really
-/// want `Score` and `LockableScore` to implement `Writeable` directly, which we do here by
-/// defining `Score` differently for `cfg(c_bindings)`.
+/// there, but other languages downstream of the C bindings (e.g. Java) can't even do that.
+/// Instead, we really want `Score` and `LockableScore` to implement `Writeable` directly, which we
+/// do here by defining `Score` differently for `cfg(c_bindings)`.
 macro_rules! define_score { ($($supertrait: path)*) => {
 /// An interface used to score payment channels for path finding.
 ///