概要: Rustの impl が定義できる型にはコヒーレンスと呼ばれる制限がある。これについて説明する。なお、この記事では特殊化がない前提で説明する。 コヒーレンス初心者のための概説 以下のように impl が重複していたり、自分のところ以外の型の impl を定義しようとするとエラーになる場合がある。これをコヒーレンスという。 struct A; // overlap rule 違反 impl A { fn f(x: i32) {} } impl A { fn f(x: i8) {} } // orphan rule 違反 impl Option<A> { } コヒーレンスの目的 コヒーレンスには以下の2つの目的がある。 同じトレイト/型に対して、状況に応じて異なる実装が採用されてしまうことを防ぐ。 将来の上流クレイトの変更による下流クレイトへの影響を最小限に留める。 コヒーレンスの分類

この記事はRust 2 Advent Calendar 2020 の16日目の記事です。 はじめに crates.io では様々なクレートが配布されています。Rust でコードを書いていると、既存のクレートの機能がイマイチで動作を書き換えたくなることがあります。このようなときは、cargo の patch 機能を使うと便利です。 この記事の内容は以下の環境で検証しました: rand クレートの動作を書き換える 乱数を生成するクレート、 rand の動作を書き換えてみましょう。 rand では確率分布を指定することができるのですが、rand::distributions::Alphanumeric を使うとランダムな ASCII 文字列を生成することができます。例えば、このようなコードを書くと use std::iter; use rand::{Rng, thread_rng}; use r

新しいAPIが作られるたびに、私たちは、古いAPIを置き換えるだけで高速化という夢をみます。何度夢破れても、高速なAPIが追加されたと聞けば、試さずにはいられませんよね！ 今回は、Linuxカーネル5.1で追加されたio_uringを使って、Rustのasyncランタイムを実装し、gRPCサーバのベンチマークを実行してみました。 io_uringとはio_uringは、ファイルシステムとネットワークの非同期I/Oのために開発されました。同期よりも非同期のほうがおしゃれ、そういう雰囲気ありますよね！クラウドネイティブも、非同期にAPIを介して、なんかやってるやつですよね。 io_uringのインターフェイスは、高い性能を目指し、1）アプリケーションとカーネル間でのメモリコピーを避ける、2）複数のI/O要求を一度にカーネルに伝えることができる、という工夫がされています。 下図のように、アプリケ

降り積もる雪はすべての罪を覆い隠してくれるので初投稿です はじめに rust-lang/rustはいわゆるrustcをビルドするためにそのソースコードだけでなく、CIコンフィグや各種ツール群、ブートストラッピングのあれこれなどを含んでおり、なかなかに巨大です そのような巨大なコードベース上だと、簡単なbugfixでもPRを提出するまでにいくつかのroadblockに出くわすことがあります また、日本語圏内でのRustの知名度も上がってきており、rustcにPR投げてみてぇ～という人もそれにつれて増加していることが予想できます しかし、上述した複雑さ、あるいは日本語が使えない場でのコミュニケーションに対して奥手になり、したくてもできない状態がそこそこの頻度で発生していそうです この記事では、その後の貢献を促せるといいなあという意図のもと、とにかくはじめての貢献を手助けすることを主眼においてい

こんにちは。コンパイルが一発で成功しないminaminaoです。 突然ですが、皆さんはコンパイルエラー爆発をご存知でしょうか？ コンパイラは、私達プログラマーにコードの間違いを指摘し修正を促してくれる良き相棒です。 しかし、特定の条件下でとんでもなく大量のエラーメッセージを出力することがあります。 そのような、コードをコンパイルしたらエラーがべらぼうに出力されてしまう現象のことを、コンパイルエラー爆発と呼ぶことがあります。 コンパイルエラー爆発の遊び 昔から一部プログラマーの間で、コンパイルエラー爆発を使った遊びが行われてきました。 2014年には、C++のコンパイルエラー爆発コンテスト、なんてのも開かれています。 The Grand C++ Error Explosion Competition 2014 このコンテストは、短いサイズで大量のエラーメッセージを出すソースコードを作ることを

まとめ async/await 構文は、Promise で書ける処理のうち特定のケースしか表現できない 特定のケースとは、ある非同期処理の前処理と後処理がそれぞれ 1 個ずつの場合のみである async/await 構文は初心者に非同期処理を導入する際に適しているが、非同期処理を逐次処理として書けるという幻想を与えるので、どこかで知識をアップデートする機会を設けるべきである この記事はなに？ 少しバズったのでまとめておこうかと。 「async/await があれば Promise なんて難しいものは要らない！」とか言ってるウブな子に、複数の API に並列にリクエストを投げて一つ以上成功した時だけ先に進む、みたいな問題を与えて愛でてみたい。— Yuta Okamoto (@okapies) 2020年12月11日 async/await は Promise のネストを手続き的なコードに見え