HackerNewsつまみぐい 2015/8/9
Erlang関係のスレッドがチラホラとあった1日でした。
元記事はBEAM（=ErlangVM）についての専門家の紹介とQAっぽい内容です。ただコメント欄はBEAMとJVMの比較で議論が伸びてますね。
元記事はErlangをいく選択すべきか？という内容。CPU負荷が高いのには向いていない、レイテンシーやスループットが必要な場合は向いているとErlangの本を読むと書いてある内容が羅列されていますが、向いていない項目の中にGlue-together style web applicationというのがあります。Railsっぽいアプリ（つまりDBとフロントがガッツリくっついてる=Glue-together？）はやらん方が良いと書いてあります。
対してHNのコメントで、下記のようなやり取りが行われています。
ffn 16 hours ago
>Erlang is not good for Glue-together style web application
Granted Elixir's Phoenix framework is not Rails level yet, it's system of plugs and heavy inspiration from rails actually makes it quite useable as a replacement for rails. Also immutability and the associated smaller memory footprint makes it more feasible to run cheaply on services like heroku or aws. Personally, I think elixir is a good boat to jump on to carry us over to the next world of web development.
reply
ElixirのPhoenixフレームワークはまだRailsのレベルには達していない。（少し略）Elixirは我々を次のWeb開発の世界へと連れていってくれる良いボートだ。
troutwine 14 hours ago
I wrote this article way back in 2013. Initial commit of Phoenix was Jan 18, 2014.
But! you're quite right. Elixir is focusing on the web application type things that Erlang and the community around it has never much addressed. There's enough interoperability from Elixir to Erlang that you could probably say the ecosystem as a whole is addressing the problem if you squint hard enough.
Side comment, it's been interesting to see Elixir grow since 2013. A lot of folks learn Elixir and then Erlang but I think it's less common to learn Erlang and then learn Elixir. It's led to an interesting situation where Elixir has had to bootstrap knowledge about OTP on its own terms without a large pool of domain experts sitting around. The asymmetry in knowledge--knowing Erlang does not imply knowing Elixir but knowing Elixir implies knowing Erlang--also makes me wonder how the squinting assumption above will shake out long-term. ¯\_(シ)_/¯
（前半部分略）
（だいたいの訳）
- 多くの人がElixirを学びErlangを学ぶ、ただErlangを学びElixirを学ぶ人はあまりいないのではないか
- それはOTPを、Elixir自身の言葉でさらにその領域の熟練者たち抜きで乗り越えるという面白い状況が生まれるのではないか
なるほどね、という感じです。僕もElixirはまだチラッとしか見ていないのですが、OTPの各ビヘイビアをElixir側でラップして提供していたりします。（AgentやTask.Supervisor） ElixirユーザーがOTPを意識せずに使えるようになるとより敷居が低くなって普及が進むのかもしれません。
Rustでスクリプト言語を作ってみようとする (2) - 字句解析部分
字句解析の部分
メモ
v2
- enumに諸々のパラメータを持たせるのはやめる（パターンマッチを簡単にできるようにする）
- マクロが便利そうなので積極的に使う
v1
ちゃんとできたら説明のようなものを書いてみたいと思うのですが、とりあえず今は書いてみたという進捗報告のみ。
token.rs
tokenizer.rs
Rustでスクリプト言語を作ってみようとする (1)
Rustでスクリプト言語を作ってみようと思います。
その進捗報告および備忘録をつけていきます。
想定しているゴール
- Rustで実装されたスクリプト言語の処理系が存在する
- 字句解析・構文解析・VMについてはライブラリを使わずにハンドメイドで実装されている
- ユーザーがコマンドラインから操作するための何らかのバイナリが存在する
モチベーション
- Rustの可能性を引き出したい
- 言語処理系の中身を知りたい
考えている言語
正直はじめてこういった言語処理系を実装してみようとしているので、あまり奇抜なことはできません。なので、基本的に次のような言語を想定します。
筆者の能力的な部分
情報系の授業は受けたことがありますが、コンピューターサイエンスを学んだ人間ではありません。ましてや形式文法や構文解析について専門的に学んだ経験もありません。そのような凡プログラマが私です。
