はてなブックマーク

はじめに Rustは「きちんとしたプログラムを書く時にはいいけど、書き捨てのプログラムを書くには向いていない」と言われることがあるようです。「一般論としては全くその通り」と思う一方で、自分自身を振り返ってみると、これまでPythonで書いていたような書き捨てに近いプログラムも全部Rustで書くようになっています。 なぜ書き捨てのプログラムもRustで書くのかを考えてみると 最初は書き捨てだと思っていても、手直ししながら使い続けることは意外と多い コンパイラが割と多くのエラーを捕捉してくれるのでデバッグの時間が短くて済む 記述量の多さはエディタの補完があってあまり気にならない といったあたりが理由になっています。 そうはいってもRustがいろいろと面倒な言語であることには違いないので、書き捨てるときは普段のRustプログラミングとは少し違った書き方をした方がより早く書けるのではないかと思いま

はじめに Rustのドキュメントのうちいくつかは日本語に翻訳されていますが、それらは必ずしも最新の英語版と同期がとれているわけではありません。 最大の理由はもちろん翻訳のコストが高いからですが、英語版の更新をチェックしたり、更新があったときに日本語版にマージする作業も意外と大変ですし、モチベーション的にも辛いものがあります。 というわけで自動化できるところは自動化するようにツールを作ってみました。 いくつかmdbookの独自拡張に対応している部分があるのでmdbook向けとしていますが、Markdownの文書全般に使えると思います。 できること まず前提として、翻訳されたMarkdownに原文がコメントアウトされて残っていることを仮定します。 その上で、以下の機能を提供します。 原文と「翻訳文中でコメントアウトされた原文」の一致確認 翻訳しなかった部分（ソースコードなど）の一致確認 原文が

はじめに 「Rustの標準ライブラリは小さい」と言われます。実際、正規表現や乱数など多くの言語で標準ライブラリに入っているようなものが、Rustの標準ライブラリにはありません。こうなっている理由は「標準ライブラリに入っていなくても依存関係を簡単に追加できる」「後方互換性を保ちながら大きな標準ライブラリを維持するのは難しい」といったことが挙げられます。もちろん標準ライブラリが小さいと不便なこともあり「サードパーティライブラリの選択が難しい」というのはよく言われるところです。 ところでRustの標準ライブラリは実際に小さいでしょうか？小さいというと、どうしても低機能・できることが少ないというイメージになりますが、個人的な印象としては「Rustの標準ライブラリはカバー範囲は狭いが高密度」というものです。 あまりこういう観点で書かれたものは見たことがないので、この記事ではRustの標準ライブラリの

2022/4/8 追記 Rust 1.60.0にてSource-based code coverageが安定化しました。また、cargoからSource-based code coverageを扱えるツールとしては cargo-llvm-cov があり、以下のように簡単に使えるようになっています。 $ cargo install cargo-llvm-cov $ rustup component add llvm-tools-preview $ cd RUST_PROJECT $ cargo llvm-cov はじめに この記事はRust2 Advent Calendar 2020の2日目です。 RustのコードカバレッジはこれまでGCC互換のDebugInfoを用いたものが広く使われてきました。これを使ってコードカバレッジを取るツールとしてcargo-tarpaulin、cargo-kc

はじめに Rustの特徴としてはメモリ安全性やGCなしで高速といったことがよく挙げられます。それらもRustの利点ではありますが、個人的に魅力を感じる部分の一つに「厳密な型付けをする文化」があると思っています。それはあまり明文化されておらず、個人的に感じているだけなのですが、Rustを使う動機の1つになりうると思うので、ここで宣伝してみます。 ちなみにこの記事のきっかけの1つが アンサー： なぜTypeScriptの型定義に凝るのか です。これを読んでいて、「自分はRustの型付け方針が好きなんだなぁ」とあらためて気づきました。 技術的な正確性より「気持ち」多めなのでポエムということで。 「厳密な型付けをする文化」とは Rustは静的型付き言語なので、ソースコード上の様々なところで型付けが行われます。これ自体は他の静的型付き言語と同様ですが、Rustではどのような型を付けるかということにつ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事はRust Advent Calendar 2020の3日目です。 今年の春から夏にかけて、「実践Rustプログラミング入門」という本を書いていました。お陰さまで売上好調のようでありがとうございます。（ちなみにちょうど昨日、電子書籍版も出ました） この本を書くにあたって、すでにいくつかRustの日本語書籍があるなか新しい本を出すということで、既刊との差別化をどう図るかは考えないといけないと思っていました。その時にRust本を一通り読み直したので、それぞれどのような本であるかを簡単にまとめておこうと思います。 基本的な書

はじめに Rustは所有権など新しい概念が多く学習難易度が高いと言われています。 しかし個人的な感触としてはかなりソースコードの読みやすさに振った言語ではないかと感じているので、 そのあたりを説明したいと思います。 内容的に論理的な話というより感覚的な話が多く出てきますのでポエムということにしておきます。 ちなみに筆者がこれまで経験してきた言語はC/C++/C#/Java/Python/Ruby/Scalaあたりです。 そのためどうしても「それらの言語と比べてどうか」という話になりがちですが、 Rustが他言語より優れている/劣っているといった主張をするつもりはなく、 あくまで目指している方向が違う（と個人的に思っている）のだとご理解ください。 数値型 Rustの数値型は例えば i32: 符号付き32bit整数 u128: 符号なし128bit整数 f64: 64bit浮動小数点数 isi

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに この記事はRustその3 Advent Calendar 2019 23日目です。（空いていたので飛び入り参加で） Rustでプラグインシステムを実装する必要があったので、その時の知見をまとめてサンプルプロジェクトを作ってみました。 ここで言うプラグインシステムとは、例えばGIMPのプラグインのように、バイナリ形式のプラグインを実行時に読み込んで機能追加するものを指します。最近この手の拡張はスクリプト言語でやることが多く、この形式はあまり見かけなくなりました。しかしRustで実装したいならバイナリの動的ロードをするしかないだろう、ということでやってみました。 注意 以下のコードは手元の環境のRust1.40.0では動作していますが、Rustコンパイラが保証していない仮定をいくつか置いているので、動く保証はありません。不具合が致命的になるような環境では使わない方がいいと思います。

2019/10/23追記 structopt v0.3にてbreaking changeが入ったため、それに合わせてソースコードを更新しました。 はじめに structoptはRustのコマンドラインパーサです。コマンドラインパーサとしてはclapが有名ですが、structoptはstruct定義からclapのコードを自動生成するものです。 本家のドキュメントを含めてあまり細かい例が書かれた記事がなかったので、ここではそれなりに実践的な例を示します。 ちなみに現在計画中のclap v3ではstructopt相当の機能が取り込まれるようです。記法が変わる可能性はありますが、似たような書き方がclapでも使えるようになりそうです。 ドキュメント まず最初に参照すべきドキュメントについて書きます。先に述べた通り、structoptはclapのコードを生成します。そのため細かい設定をしようとすると

はじめに SnapcraftとはCanonicalが開発しているパッケージマネージャです。（昔はSnappyだったと思うんですが変わったんですかね？公式サイトがSnapcraftになっているのでここではそれに従います） 最近のUbuntuにはデフォルトで入っていたり、いろいろなlinuxディストリビューションに対応したりしているようです。 Rustのソフトウェアを配布する際に、Rustの開発者前提ならcargo installでいいのですが、一般には敷居が高いです。 そうすると「yumやaptといった普通のパッケージマネージャで入れたい」となるのですが、こちらは公式リポジトリに入れるのはすごく大変ですし、野良リポジトリというのも（開発者にとっても利用者にとっても）手間がかかります。 というわけで第三の選択肢として、Snapcraftのようなクロスプラットフォームのパッケージマネージャがあり

はじめに システムコールのptraceを使うと他プロセスの呼ぶシステムコールを覗き見ることが出来ます。 これを使って実行中の他プロセスの標準出力や標準エラー出力を読み取るライブラリを作ってみました。 使い方 std::io::Readを実装しているので 通常のファイルIOやネットワークIOと同じように扱えます。 extern crate nix; extern crate proc_reader; use nix::unistd::Pid; use proc_reader::ProcReader; use std::process::Command; use std::io::Read; use std::time::Duration; use std::thread; fn main() { // 読み取り先のプロセスを生成 let mut child = Command::new("s

はじめに この手の記事も3回目ですが、ようやくTravis-CIだけでLinux/Windows/macOSの64bitバイナリが生成できるようになりました。 Travis-CIのRustサポートも改善されてかなり少ない記述でできるようになっています。 必要なファイル 必要なファイルは.travis.ymlと.cargo/configの2つです。 .travis.yml Travis-CIのlanguage: rustでrustupも入るようになりました。 before_scriptで追加するのはrustup target addとwindows用のリンカとしてmingwのgccのみでOKです。 language: rust os: - linux - osx before_script: - if [[ $TRAVIS_OS_NAME == "linux" ]]; then rustup

大抵の場合これで十分なのですが、公式ドキュメントを見るとオプション扱いのディレクトリがいくつかあるようです。 このあたりに関するまとまった記事はなさそうだったので、今回はcargoが特別扱いするディレクトリを全て使ったサンプルプロジェクトを作って簡単に解説します。 リポジトリはこちらです。 dalance/sample-rs ディレクトリ構成 サンプルプロジェクトの構成は以下の通りです。 ▾ src/ # ソースファイル lib.rs # ライブラリ用のエントリ・ポイント hello.rs world.rs ▾ bin/ # (オプション) 追加の実行可能形式 hello.rs world.rs ▾ examples/ # (オプション) 使用例 hello_world.rs ▾ tests/ # (オプション) 統合テスト hello_world.rs ▾ benches/ # (オプシ

はじめに 以前「RustのLinux/Windows/OS X向けバイナリをCIで生成する」という記事を書いたのですが半年たって情報が古くなってしまったので更新します。 また、前回記事を書いた後に気づいたのですが、rust-everywhereというのもあるようです。こちらもCIでRustのバイナリ生成するテンプレートになっていて、ARMとかもサポートしているようです。 変更点 前回からの変更点は以下の2点です。 rustup.rsの使用 muslターゲットに変更 rustup.rsは現在のRustのデフォルトのセットアップツール兼ツールチェーン管理ツールです。以前のrustup.shやmultirustは非推奨になったようなので皆さん乗り換えましょう。 rustup.rsではクロスコンパイル用のターゲット追加が簡単にできるようになっているのでCI用のスクリプトがだいぶ簡素化されました。

はじめに この記事では、Cの構造体におけるいわゆるZero-length Array / Flexible Array Member(このイディオム自体知らなかったわけですが)をRustのFFIから扱う際にstd::mem::transmuteを使って強引にキャストしていました。その後いろいろ試したところ、特にtransmuteが必須というわけでもなかった、ということが分かりましたので、現時点で妥当と思うやり方を書いておきます。 （もっといいやり方がありましたらお教えください） Zero-length Array / Flexible Array Member この記事で扱うのは、以下のようなCの構造体をRustのFFIでどう扱うか、です。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

測定方法 時間測定には/usr/bin/timeを使い、10回測定した平均を取っています。検索結果は/dev/nullに捨てたりせず、実際に表示させています。また、ディスクI/Oに影響されないよう検索対象はディスクキャッシュに乗った状態で測定しています。 結果 Linuxカーネルソース linuxをクローン直後（ファイル総数約5万、2.2GB）のディレクトリ検索です。検索結果の多いキーワード（EXPORT_SYMBOL_GPL）と少ないキーワード（irq_bypass_register_producer）の2通りの結果になります。 Linuxカーネルソース（ビルド済み） ↑と同じですが、カーネルビルドを行いバイナリが生成された状態（ファイル総数約9万、9.3GB）での検索結果です。生成されたバイナリは.gitignoreで無視されるので、そのあたりを考慮したツールが有利になる条件です。 W

はじめに Rustの練習として、ファイル検索・置換ツールamberを作ってみました。検索は昔ながらのgrepから、最近だとackやagなどいろいろありますが、置換に関してはいまだにfind ... | xargs sed -i '...'くらいしかないように思います。 検索速度についても多少気にしていて、少なくとも固定文字列検索についてはgrep/agあたりと遜色ないはずです。 リンク Download Source 使い方 インストール ダウンロードしたzipを展開するとambs/ambrと2つファイルがあるのでパスの通ったところに置くだけです。 ambs（"amber search"）が検索コマンド、ambr（"amber replace"）が置換コマンドです。 検索 デフォルトで以下のような設定になっています。 固定文字列検索 カレントディレクトリから再帰検索 VCSの管理ディレクト