PLの文字化け

PLマニアにとって、文字化けとは、長い長い戦いだった。
悲しいのは、そもそもascii以外は考えていいない、舶来言語に片思いが、多かったことだ。
そして現代、多くの言語が、uftに対応したが、
Ruby でも、古い版は、文字化けする。3.0では、文字化けは無い。
国産言語と銘打って登場したが、日本語の優先順位は低かったのだ。
Pythonでの文字化けの経験はない。
c++でも、dでも未だ、文字化けが起こる。
gccで、文字化けが、起きないのは不思議だが、事実、起きないのだ。
それもあって、gccは大好きなPLの一つなのだ。
大体は、内部では、unicodeで、windowsのcp932に対応して居なおということだ。
なでしこが文字化けしたら、笑っちゃうが、コンソールへｒの表示はどうするんだ？
goは文字化けとは、無縁の様だ。goは、日本語のraw文字列もスマートに扱えるんだ。
goに不満を言っては、罰が当たる。

また、goはその並行機能によって、数十台のRubyサーバーを
たった数台のgoサーバーに置き換えることができた実績があるとのことだ。
魔術師が、goを好きなのは、コンパイルから実行までの扱いがシンプルなことだ。
変なツールを導入されたり、うんざりする言語も多いのだ。
goには、腹立つことが無い。いいぞgo。
シンプルな言語仕様もいい。
kotlinは美しい言語だが、IDEが絡んでいてウザいんだ。
それに、醜いJavaが絡んでくる。うんざりするんだ。
その点、goはスッキリしていていい。魔術師好みだ。
あれこれ余計な面倒見ないで、任せてくれよって言いたいのだ。
著者の問題かもしれないが、Rustのパケージマネージャって言うんだっけ、
コンパイルくらい自分でやりたい。コンパイラは無いのか！
と思ったら、最後に、rstc（だったかな）を使う方法もあるだって、
それから言いなさい！
goでは、こんなイライラは、味わわなくていいんだ。
初めて、goを使ったとき、インストールもコンパイルも、
何も見ないでできたよ。ただ一つだけ、go build のbuildだけは、ネットを見て知った。
今goと出会ったとしたら、go buildは、二番目くらいにはやってみるだろう。
一回目は、gocだろう。でも、binフォルダの中を見れば違うのに気づくだろう。
いつも、PLをインストしたら、binフォルダを覗いて、exeとdllを見るからね。
コンパイラは何処にいるだ～ってね。