ハクソク

世界を動かす技術を、日本語で。

エキスパート: ElixirのためのLSP

270日前原文(github.com)

概要

  • Expert はElixir公式の 言語サーバー実装
  • インストール方法 はOS・エディタごとに異なる
  • Nightlyビルド や ソースビルド にも対応
  • スポンサーシップ による支援方法を用意
  • ライセンス はApache License 2.0採用

Expert：Elixir公式言語サーバーの概要

  • Expert は Elixirプログラミング言語 のための 公式Language Server Protocol (LSP)実装
  • コード補完 や 診断 など、エディタ連携機能を提供
  • Elixir開発環境 の品質向上に寄与

インストール方法

  • releasesページ から OS・アーキテクチャ に合ったバイナリをダウンロード
  • ダウンロード後、 $PATH 上（例: ~/.local/bin/expert）に配置
  • エディタごとのセットアップ手順 は公式の Installation Instructions 参照
  • Nightlyビルド を試す場合、GitHub CLIで以下コマンド実行
    • gh release download nightly --pattern 'expert_linux_amd64' --repo elixir-lang/expert
    • ダウンロードしたバイナリをエディタに指定

ソースからのビルド

  • Zig 0.14.1 のインストールが必須
  • コマンド just release-local を実行しビルド
    • apps/expert/burrito_out ディレクトリにExpertバイナリが生成
  • 生成バイナリをエディタに指定

スポンサーシップ

  • 企業スポンサー は、EEF Sponsorship WGのDan Janowski氏（danj@erlef.org）へ連絡
  • 個人支援 は GitHub Sponsors 経由で寄付可能
    • チームメンバー一覧はサイドバーに記載

その他リソース

  • Architecture、 Development Guide、 Glossary などのドキュメントを提供
  • インストール手順 や ライセンス情報 も公式リポジトリで公開

ライセンス

  • Apache License 2.0 の下でソースコードを公開
  • 詳細は LICENSEファイル を参照

Hackerたちの意見

面白い選択だね、justを使うなんて。

└

ルートにjustfileとmakefileの両方があるんだよね。多くの人はmakeを完全に捨てたいと思ってるみたい。でも、私はjustが言語に依存せず、すごく便利だと思ってるし、mixはBEAMに直接関係ないワークフローにはあまり向いてないと思うな。

└

個人的にはjustの大ファンなんだけど、これが世界で最もよく考えられた意見だとは全然思ってないよ…。

└

"just"が何かよくわからない人のために: ウェブサイト: https://just.systems 以前のHNのディスカッション: https://news.ycombinator.com/item?id=42351101

アーキテクチャは素晴らしいね。言語のバージョン互換性やアプリの名前空間を守るためにここまでやるとは、特に印象的だよ。

└

Elixirのネームスペースって何？

Elixirにはいくつかの異なるLSP実装があって、それぞれに利点と欠点があるんだ。去年、みんなでLSPの共同作業をすることに合意したけど、これがその結果になるのかな？

└

うん。

└

そう、それで合ってる。すごくワクワクするね。

これには本当にワクワクしてるよ。Elixirのエディタサポートは、私が望むほど良くなかったからね。これに投資してくれてるのを見るとすごく嬉しい！Elixirほど一貫して素晴らしい開発者体験を提供する言語には、ちゃんとした公式のサポートされた言語サーバーが必要だと思う。早く試してみたいな！

わー、これ楽しみ！古い公式言語サーバーも悪くないけど、今までのコードベースでは大体問題なく動いてるんだ。ただ、たまに変なことをやってコンパイラーが遅くなっちゃうことがあって、そのせいでLSのパフォーマンスが悪くなることがあるんだよね。だから、elixir-lsがたまに遅くなる原因が解消されるといいな。

└

ちょっと指摘なんだけど、今まで公式のLSP実装ってなかったよね、コミュニティが作ったものだけ。今でもDashbitの社員や言語コアメンバーがこのプロジェクトに継続的に関わってるわけじゃないし。個人的には、それがどの選択肢を使うかの体験の質に大きく影響してると思う。

MCPサポートはないの？

└

各LSPがそれを実装するより、単一のMCP -> LSPアダプターの方が理にかなってるんじゃない？

└

BEAM MCPについては、アプリケーション内で動作してLLMにコンテキストと実行環境を提供するTideWaveをチェックするといいよ。 https://hexdocs.pm/tidewave/mcp.html

ElixirのいろんなLSP実装を試してるんだ—ElixirLS、Lexical、next-lsとか。Expertも少し前から追ってるよ。試してみるのが楽しみ！ただ、「Expert」って名前がちょっと気になるかな。なんか少し傲慢に聞こえるというか、まるでこの部屋で唯一の「専門家」みたいな感じがする。もうちょっと中立的な名前の方が良かったかも？それでも、公式ツールがどんなものになるか楽しみだね！

└

「かなり知識があって、常に謙虚に他者から学ぶ準備ができている」ってどう？略してFKAHRLO。

└

これはAIツールじゃないよ。LSPなんだ。部屋の中での専門家っていうのは、ランダムな単語生成器じゃないし、賢いわけでもない。ただ、その言語のルールに従ってるだけなんだ。

└

名前が完璧だと思ったよ。ちょっと楽しいし、ライブラリでよく見るexプレフィックスとも合ってる。

└

そもそもどうやって知ったの？ずいぶん前にElixirのブログでLSPプロジェクトの発表を見た記憶があるけど、それ以降は何も聞いてないな。

└

考えすぎだよ。無難よりも面白い方がいいね。

└

"NotExpert"ってどう？

言語とエコシステムの長期的な計画があるのを見るのはいいね！

"公式"ってどういう意味？公式のElixirプロジェクトなの？ホセ・ヴァリムが貢献者に入ってないのが気になるんだけど。

└

そうだよ、elixir-langのGitHub組織にいるのを見ればわかるよね。

└

「公式」っていうのは、Elixirのクリエイターたちが作ったってこと。ElixirにはJoseだけじゃなくて、もっとたくさんの貢献者がいるよ（彼は元祖/クリエイター/リーダーだけどね）。