Kotlinには、処理のブロック内（{ }のこと）でスコープを変えることによって、簡潔な記述が出来る便利なスコープ関数が、標準関数として用意されています。
ただ、便利な半面ちょいややこしいという面もあります。
そこで、よく使うと思われる「let と run」を、本当にざっくり過ぎる感じで解説してみました。詳しい解説は上の動画をご覧ください。
（applyとalsoについてはこちらから）
もくじ
本当にざっくり過ぎるまとめはこれ
スコープ関数はそもそも標準関数なので、使いみちは色々考えられるかと思うのですが、本当にざっくり言うと、「let」と「run」はnull（空っぽ）チェックのときに使えると思っておけばいいのではないかと。
違いは「this」と「it」
関数の定義で見てみると
letはこれ
/**
* Calls the specified function [block] with `this` value as its argument and returns its result.
*/
@kotlin.internal.InlineOnly
public inline fun <T, R> T.let(block: (T) -> R): R {
contract {
callsInPlace(block, InvocationKind.EXACTLY_ONCE)
}
return block(this)
}
runはこれ
/**
* Calls the specified function [block] with `this` value as its receiver and returns its result.
*/
@kotlin.internal.InlineOnly
public inline fun <T, R> T.run(block: T.() -> R): R {
contract {
callsInPlace(block, InvocationKind.EXACTLY_ONCE)
}
return block()
}
どちらも、「this」をブロック内で処理して、自分の好きな戻り値を返すことが出来る（applyとalsoは自分自身しか返せない）という点では同じですが、
「run」の場合は処理対象をレシーバーとして受け取り、
「let」の場合はラムダ式の引数（it）として受け取る点が違うようです。
例はこんな感じ
なので、実際に例を見てみると、違いは処理対象の受け取り方（呼び出し元へのアクセスの仕方）だけです。
もともとこんなコードは
if (arguments != null) {
title = arguments.getString(ARG_title)
deadline = arguments.getString(ARG_deadline)
}
こんな感じになります。
runの方は、処理対象である「Intent」をレシーバーの「this」としてアクセスしており、この「this」は省略できるので「getString」の前には何もいらなくなる。その代わりブロック内外で「this」の意味合いが変わってしまう。
一方、letの方は純粋なラムダ式なので、処理対象である「Intent」はその唯一の引数「it」として受け取っているため、「getString」の前に「it」が必要になる。その代わりブロック内外で「this」の意味合いは同じまま。
NULLチェックの場合は「let」でよい気がする
とはいえ、Kotlinを作った天才の方々にはいろんな思惑があるかと思いますが、let・runとも最終的にはnullチェックの対象（レシーバー）を受け取って処理するものの、返すもの（戻り値）は自分で設定できるので、そうであれば、NULLチェックに関しては、より簡潔に記述できる「apply」で良いのではないかと、凡人の私は思ったりするわけであります。
実際、Android StudioでFragment（フラグメント）を作った時に自動で生成されるコードのNULLチェックには、letが使われていますし。
（詳しくは下の動画で解説していますので、よろしければご覧ください）