ここ2年くらい、仕事では大体 Go を書いている。jmuk さんが Go言語は、なんというか「ちょうどいい」言語だな、と思っている。異論は認める。 と書いていたけれど、私はやっぱり Scala や Kotlin あたりが好きで、これは変わらなそう。 例えばコレクションを map しているのをみると、私は「なるほど、ここではコレクションの要素数は変わらないんですね」と思う。filter だったら「コレクションの要素数は変わるけど、個々の要素は変わらないのか」ということを、あるいは Result を map していたら「ここではエラーのほうは触らないのね」ということを読みとっている。 こういう意図が、素朴な for ループと、if err != nil だと読みきれなくて、いや真面目に字面を追っていけばわかるんだけど、私が「map するか」と思いながら for ループを書いて、その for ル
ざっくりGo言語を触ってきました。 今までJavaとかC#をメインに使ってきた僕としては、一見先祖返りしたような仕様にちょっと戸惑いました。 「コンパイル速度を上げる」目的で作った言語とのことで、その目的のためにコーディングしやすさをある意味犠牲にした、といいう点は理解できます。 が、明らかにコンパイル速度（あるいは実行速度）とは関係ないところで使い勝手を「わざと」悪くしたとしか思えない仕様に、Googleエンジニアの偏屈さを感じずにはいられません。 僕の単なる認識不足だけかもしれませんが、僕自身が感じた”偏屈”と思ったところを書いておきます。 ※アイキャッチ画像に自作Gopher君を載せていますが、Gopherの原著作者はRenée French氏です。 [ad#top-1] nullじゃなくてnil 「何もない」を表すnilですが、どちらかというとnullと表現する言語の方が多いです。
日本語を扱っていて困るのがgrep。正規表現パターンにマルチバイト文字を混ぜられなかったり、windowsで動かすと"表"の様に2バイト目にbackslashが混じる文字で動作しなくなったりします。 さらに複数のエンコーディングで書かれたファイルが散らばっていると一度のgrepで検索出来なかったりもします。 vimに限っては、内蔵のvimgrepを使う事で解決出来ますが、見つかったファイルをバッファに開いてしまうという挙動がある為、grepオリジナルの動作を求めている人にとっては都合の悪い物だったりもします。 vimgrepの様に複数のエンコーディングに対応していて、検索パターンにマルチバイト文字を含んだ正規表現が使えて、windowsでもちゃんと動いて、ついでといっちゃあなんだが、"**/*.txt"で再帰検索してくれる様なgrep無いかなぁと思ってたんですが、やっぱり無いので作りました
そこそこセンセーショナルなデビューを飾ったgolangも、まだまともなフレームワークが登場するにいたっていない。 1600人以上(11/15現在)の参加者となっているgolang MLへの投稿も玉石混交(・・・どちらかという石が多い）なのだが、これは、と思う人々もgolangワールドに乗り込んできている。 githubにgo-playを立ち上げたvito氏もその一人。 何を隠そう、かのLFE(Lisp Flavored Erlang)の作者である。・・って、LFEはほとんど知られていないだろうが、 Lispで記述したコードをErlangコードに変換するフロントエンドである。・・名前だけは今年はじめくらいに知っていたのだけれど、開発は0.5まで進んでいるみたい。 go-playは、サイトを立ち上げてからまだ10時間くらいで、現在絶賛開発中な感じで、「Playing with the Go l
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く