Rust for Linuxでは独自のallocライブラリを使っている
Rustを第二言語として採用してデバイスドライバなどのモジュールをRustで書けるようにする「Rust for Linux」が近々マージされる予定だともLinus氏自身が発言しています。 そんな期待のかかるRust for Linuxですが、提案された当初は期待こそされていたものの、様々な懸念点も指摘されていました。 その1つが標準ライブラリの一部であるallocクレートの設計です。 このクレートはヒープ領域を扱うBox、Vec、StringなどRustではお馴染みの構造体を提供しています。 Rustの標準ライブラリはOSのサポートを前提とした構造体も多くあります。そのため、OSそのものを書くようなベアメタルプログラミングにおいて標準ライブラリをそのまま使うことはできません。 使えるのはcoreと呼ばれる依存関係のない全く無いライブラリがありますが、allocはOSのサポートが必要なヒープ
cargoのどこがいいのか | κeenのHappy Hacκing Blog
κeenです。久しぶりのブログですね。 LLイベントに行ってきたらパッケージマネージャの話がありました。 その懇親会でcargoについて振られたんですがタイミングがなくて喋れなかったのでブログに書いておきます。 ざっくりまとめると パッケージマネージャ/ビルドツールに要求される要件を卒なくこなしている 面倒を見る範囲が広く、要はワンストップソリューションだから便利 コンパイラと同じ母体が開発してるのでグダグダがない じゃないかなと思います。あとバイナリなのでキビキビ動く。 因みにcargoが便利という声の中にはcrates.ioで欲しいパッケージを探しやすいだとかみんな割とセマンティックバージョニングを守るので理不尽にビルドがコケたりしないなどもあると思います。 1に関しては最近のよくあるベストプラクティスを全部やったらこうなったって感じですね。 セマンティックバージョニングで依存関係を管
isucon7予選のアプリをRustに移植したから解説するね | κeenのHappy Hacκing Blog
κeenです。こういう流れがあったので移植しました。 keenさんが「2028年、Rust でイケてる web application framework はこれだ！」みたいな記事を書くとと "余力" が生まれるかもしれません…！！ — FUJI Goro (@__gfx__) 2018年8月28日 まずISUCONを知らない方に雑に説明しておくと、意図的に遅く作られたWebアプリケーションが与えられるので7時間くらいでどれくらい高速化できるかを競うコンテストです。 このお題のWebアプリケーションが参加者や流行りに合わせて複数言語で提供されるのですが、今年はRustが来そうだということで参加者の肩慣らしのために過去問を移植しましたというお話。 ひとまずソースコードは こちら 手元でベンチマークをしてみた限り、Pythonの2倍くらいは速いもののGoには劣るようでした。これの考察については
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - uutils/coreutils: Cross-platform Rust rewrite of the GNU coreutils
