curlの開発者が語る苦悩とRustへの期待
curlといえばコマンドラインでWebサーバにリクエストを送ることができるツールで、私個人もAPIの開発や評価のためにcurlコマンドを何回実行したかわからないほど使っていた時期があった。
そんなcurlの開発者であるスウェーデン人のDaniel Steinbergは1996年に26歳という若さでcurlの原型を開発し、現在もIETFでHTTP/2やQUICKの議論に参加している。
そんなDaniel Steinbergがブログに書いていた記事が話題になっていた。
- I can do it in less than a 100 lines
- I can do it in a three day weekend
- No reason to be written in C
- We sold a curl exploit
- This isn’t a big deal
HackerNewsやRedditなどで見つけたcurlに対する批判を集めたものだ。偉大なツールの開発者って大変だ。
この記事では、ひとつひとつに対して反論はしていないが、現在のcurlに対してどう考えているかを書いている記事がある。
A rewrite of curl to another language is not considered. Porting an old, established and well-used code base such as libcurl, which to a far degree has gained its popularity and spread due to a stable API, not breaking the ABI and not changing behavior of existing functionality, is a massive and daunting task. To the degree that so far it hasn’t been attempted seriously and even giant corporations who have considered it, have backpedaled such ideas.
curlを他の言語で書き直すということは考えていない。giant corporationでさえもアイデアを挙げたがbackpedal（撤回）している。
ここでgiant corporationと書いているのはGoogleのことだが、Googleがlibcurlを書き直そうとしていることについても別の記事に書いている。
The Chromium bug states that they will create a library of their own (named libcrurl) that will offer (parts of) the libcurl API and be implemented using Cronet.
CronetはChromiumのネットワークスタックだが、この中でlibcurlが提供していた機能の一部を提供するlibcrurlという名前のライブラリを作ろうとしている。
まず、名前がややこしいが、それ以外にも次のように反論する。
I don't think applications will be able to arbitrarily use either library for a very long time, if ever. I don't think applications will be able to arbitrarily use either library for a very long time, if ever. libcurl has 80 public functions and curl_easy_setopt alone takes 268 different options!
If they just put two paid engineers on their project they already have more dedicated man power than the original libcurl project does…
libcurlはpublicな関数だけで80あり、setoptでは268ものオプションがある。Googleは2人のpaid engineerを配置しており、それだけで元のlibcurlよりもdedicated(献身的)な人材だといえるで作ってるが、それで大丈夫だろうかと。
どこかの北欧出身の開発者のような暴言ではなく「がんばってほしい」と書いていたが、その１年後のブログで「backpedal」と書いているので大丈夫ではなかったようだ。ではGoogleのlibcrurl以外の実装に対してDaniel Steinbergはどう反応しているのか元の記事を読んでみる。
As long as those libraries have APIs that are accessible to libcurl, libraries used by the backends can be written in any language – but since we’re talking about memory safety in this blog post the most obvious choices would probably be one of the modern and safe languages. For example Rust.
他の言語でlibcurlを呼び出しているライブラリが存在するのであれば、どの言語でもlibcurlの機能を呼び出せる。Daniel Steinbergはメモリ安全性についてブログに書いており、その立場からするとRustのようなモダンで安全な言語で書くのがmost obvious choicesだという。
Hyper is a HTTP library written in Rust. It is meant to be fast, accurate and safe, and it supports both HTTP/1 and HTTP/2. As another step into this world of an ever-growing number of backends to libcurl, work has begun to make sure curl (optionally) can get built to use Hyper.
Rustで書かれたHyperというHTTPライブラリがある。このHyperをlibcurlのように使えるようにする作業が始まったという。
Hyper didn’t have a C API, they’re working on making one so that C based applications such as curl can actually use it. I do my best at providing feedback from my point of view, but as I’m not really into Rust much I can’t assist much with the implementation parts there.
元々、HyperにはC APIがなかったが、C APIを実装しようとする動きがあり、Daniel Steinberg自身もフィードバックなどに協力している。ただ、それほどRustに興味があるわけではないので、実装についてはそこまでアシストできていないのだとか。
hyper is a safe, correct, fast HTTP implementation written in Rust, and as it matures, the desire to use that safety in places that aren’t Rust grows. We’ve been working on a C API for hyper, with the first main user being the curl project. We’re so excited to be part of this effort for a memory safe ‘curl’, and you can already experimentally try it out!
そのhyperを開発しているseanmonsterのブログでもhyperのC APIの最初のユーザがcurlであり、メモリセーフなcurlの実装に関われることを喜んでいるようだ。2017年にseanmonsterがFirefoxを去ったとき、RustのHTTPライブラリの開発が止まるのではと心配になったが、現在もエキサイティングに開発を続けているようだ。
この記事が気に入ったらサポートをしてみませんか？