なんか言いたかったことを、みんな言ってもらえた感じですっきりしました。
ちなみにメッセージ送信に ! を使うのがキモいという人のために (というわけじゃなくて apply や spawn なんかに使えるようにだと思いますが)、lib:send という関数がありますね。

lib:send は忘れていました(そういえば『Programming Erlang』にもあったかも)。ありがとうございます。ところでどっちがプリミティブなのかなあと思うと、この定義は、
send(To, Msg) -> To ! Msg.
なので、あくまでもプリミティブは ! なのかな。 dankogai が「構文糖衣」といったのはその辺の勘違いがあったりする？のかもしれませんね。

カンマは and で、セミコロンは or です。
カンマで区切られているものは全て実行されますが、セミコロンで区切られているものはそのいずれかが実行されます。ガードでもカンマは and で、セミコロンは or ですよね。
erlang:send/2,3 もあります。

＃長すぎとおこられたので分割します。
Erlang Programming
http://www.pragmaticprogrammer.com/titles/jaerlang/index.html
を読んで勉強中のものです。おおむね同意ですが、2点指摘を。
パターンマッチはHaskellとかStandard MLとかでもできますよ。
http://en.wikipedia.org/wiki/Pattern_matching
http://en.wikipedia.org/wiki/Standard_ML#Discrete_Wavelet_Transform_.28pattern_matching.29

もう1点はスレッド間でメモリを共有することができないのは、思想としてそういう方式を排除しているからです。複数のプロセスが並列に動いてプロセス間メッセージのみで連携するというのがErlangの並列プログラミングモデルなのです。この点がErlangの一番の本質だと私は思います。このへんについてはPrograming Erlangかあるいは
Making reliable distributed systems in the presence of software errors
http://erlang.org/download/armstrong_thesis_2003.pdf
に詳しい説明がありますので、ぜひぜひご一読ください。

＞クエックさん
ありがとうございます。そういえばパターンマッチにも,;は使えましたね。忘れていた(笑)。

＞hnakamur
むろん、パターンマッチはML系言語やHaskellでも使えます。でも変数への束縛がパターンマッチによって実現しているかというと……まあ、そうとも言えるか。しかし、構文的に何を意味しているかは少し違うと思っています。とはいえ、このテの言語でもパターンマッチは -> なのに関数定義は = なのには私は違和感を感じないことはありません。

もうひとつ。

むろん、メモリの共有は「意図的に排除」しているんですよ。でも普通の言語はそうなっていない。ちなみに、 Erlang なみの軽量スレッドを実装するとしたら、そのような制約を与えるしかないだろうと私は勝手に思っています（ただ処理系実装には明るくないので間違いかもしれません）。
「萎えるポイントもそこにある」っていうのは「可能性があるとしたらそこだ」ということで、私がそこをイヤだと感じているという意味ではありません（ちょっとわかりにくかったかな）。