IBMは先頃、サーバサイドSwiftの開発を中止した。これはSwiftがオープンソース化して間もなく開始されたもので、Swift Server Worl Griup[SSWG]のリーダシップも同時に譲渡されている。今回の決定がSwiftおよびSwiftコミュニティに対して持つ意味について、IBMのChris Bailey氏に話を聞いた。
先月のSwiftメーリングリスト上で明らかにされた今回の決定に対して、Swiftを含む広範な開発コミュニティからはすぐさま反応(1および2)があり、今回のIBMの発表がサーバサイドSwift開発にとって実際に持つ意味や、IBMがそのような決定に至った理由に関して、多くの憶測やさまざまな考えに基づくコメントが寄せられている。
一部の開発者からは、IBMのサーバーサイドSwift開発フレームワークであるKituraと競合するフレームワークであるVaporの存在が、Kituraの選択肢としての魅力を削いだのではないか、という指摘があった。サーバ上のSwiftよりも有望な競合言語としての、RustやGoといった言語の存在を理由とする声もある。さらには、この決定によって、サーバ上でSwiftを使用するというストーリは終わるだろうという意見さえあるのだ。いずれの意見に対しても、反論の余地は残る。Twitterでも同じような意見が交わされている。
状況の明確化に寄与すべく、InfoQでは、シニアテクニカルスタッフメンバとしてSwiftのランタイムテクノロジに関わり、今回の決定でIan Partridge氏とともにSwift Server Work Groupを離れることになった、IBMのコントリビュータのひとりであるChris Bailey氏に話を聞く機会を持つことにした。
これまでのサーバサイドSwiftプロジェクトへの関わりについて、説明をお願いします。プロジェクトにはおもに、どのような形で参加していたのでしょうか？
私を含むIBMのチームは、オープンソースのSwift.orgプロジェクトが発表された時点から、このプロジェクトに関わってきました。当初は主として、Swift言語のコアとAPIをLinuxおよびサーバ環境で動作可能にするための開発を行っていました。この中にはSwift言語自体、Dispatch並列性ライブラリ、基本的なAPIライブラリといった、Swiftランタイムを形成するものがすべて含まれています。さらに、さまざまなコミュニティグループがサーバフレームワーク開発で協力して、コアライブラリの共通セット上でコラボレーションし、サーバエコシステムをさらに大きなものにする場として、Swift Server Working Group(SSWG)を立ち上げました。
Swing.orgコミュニティ以外でも、Kituraフレームワークを開発して、関連するライブラリやツールのエコシステムを確立することで、クラウドネイティブアプリの開発に必要なものをすべて揃えた、完全なマイクロサービスフレームワークを提供しました。
Kituraにはフレームワークとして、70以上のコントリビュータと、長年にわたって163回のリリースを提供した実績がありますが、Ian Partridgeさんとあなたがプロジェクトを離れた後も、Swiftを使用したい開発者にとって重要な選択肢であり続けると思いますか？
Kituraは毎日数千回ダウンロードされていて、多くの大企業で実際に運用されていますし、採用を公式に発表している企業もいくつかあります。
IBMは今後も、締結済の有償契約を通じたKituraのサポートを続けますが、将来的な新機能開発に対するコントリビューションは少なくなります。同時にそれは、より広く参加する余地と機会がコミュニティ生まれた、ということでもあります — 私たちは現在、このテクノロジをコミュニティの関係者が活用できるような取り組みを行っています。オープンプロジェクトの常として、プロジェクトの成功は、それを取り巻くコミュニティの存在と、そのテクノロジを活用するユーザの貢献意識にかかっています。
Kituraが今以上にコミュニティ主導のプロジェクトとなって、今後も繁栄を続けることができることを願っています。
Linux版Swiftの状況はどうなのでしょうか？Linuxプラットフォーム上の有力なプレイヤになるためには、何を行う必要があると思いますか？
Swingは過去の資産に立脚した、優れたテクノロジです — 新言語であるSwiftでは、既存の知見を十分に活用すると同時に、他言語のよい面を取り入れた設計と構築が行われています。
サーバでの使用に関しても、優れた基本的特性を備えています。元来がモバイル向けであったというその成り立ちは、メモリフットプリントが少なさと、起動時間の短縮というメリットも生み出しています — これらはいずれも、サーバ上で動作する場合にも有用な特性です。
大きな疑問として常に指摘されるのは、iOSモバイル開発者がモバイルアプリのフルスタックBFF(Backend for Frontend)開発に使用しているものから、より広いユースケースに対応する汎用的なサーバテクノロジへという、キャズム(chasm)を越えることが可能なのか、という点です。
SwiftはAppleのエコシステムの一部であることから大きなメリットを受けていますが、それは同時に、サーバエコシステムの要求する機能に関してもAppleへの依存が大きいということでもあり、その有機的成長において課題を生み出すことになります。例えば、Swift開発者のほとんどはIDEにAppleのXcodeを使用していて、エミュレータ環境によるローカル実行など、それが提供するiOSデバイス用の開発サポートを享受しています。ですから、Appsodyのような開発ツールのXcodeへの簡単なインテグレーションがサポートされることで、ローカルIDEから直接コンテナ環境での開発ができるようなサーバコード開発サポートが加われば、と思います。オープンなガバナンスとエコシステムが存在すれば、コミュニティが協力して、自分たちにとって重要な問題やユースケースを解決することは可能です。
Appleはこれらの問題に積極的に取り組んでいて、Swiftをよりオープンにすることで、サーバエコシステムの構築を支援するように努力しています。この活動は最近になって、さらにペースが早まっています。AppleのTom Doron氏が推進役となって、Swift Server Working Groupを通じてサーバエコシステムの推進すると同時に、サーバに関連するAppleの活動をリードしているのです。加えて、Ted Kremenek氏が先日投稿した"On the road to Swift 6"という記事には、エコシステムの拡張とさらなるオープン化を進めるという強い意志が表明されています。その中には、他のIDEでも優れたSwift開発を可能にするために誕生したLanguage Server Protocol(LSP)プロジェクトも含まれています。
サーバサイドSwiftとKituraがローンチされてから、ネイティブ言語の分野ではGoとRustに注目が集まっています。特にRustは、少なくとも安全重視という視点において、Swiftと直接的に競合すると思われますが、これらの言語はどのように重なり合っているのでしょうか？
GoとRust、そしてSwiftは、型安全でコンパイル可能なネイティブ言語として、CおよびC++の代替となる"現代的ネイティブ言語"としてグループ分けされることが少なくありません。
プログラム言語としてのSwingは非常に若く、最初に登場したのは2014年の半ばです。オープンソースプロジェクトとしてLinuxを公式にサポートしたのは2016年の9月以降なので、まだ3年半しか経っていません。これに対して、Goは登場から10年、Rustは9年半が経っています。つまりどちらも、スタートはずっと早かったのです。
GoはKubernetesのようなクラウドテクノロジのコアインフラストラクチャや、CLIの開発などに使われるシステム言語として、真の得意分野を見つけることに成功しました。Rustはまだ展開すべき場所を模索している段階ですが、Web Assemblyによって大きな関心を集めるようになっています。Swiftが採用曲線において遅れを取っていることは否めない事実です。
昨年のAltConfで私は、"Server-Side Swift State of the Union"と題して、サーバサイドSwiftの普及状況について講演を行ったのですが、その中で、Swiftのパッケージエコシステムの規模が同時期のNode.jsと比較して示されました — その結果からは、同時期のNode.jsに遅れは取っているものの、その差はそれほど大きくない、ということが分かります。
基本的に、サーバサイドSwiftには多くの可能性があります。それを成功と広範な採用に結び付けることができれば素晴らしいと思います。
サーバサイドSwiftの発展はその公式フォーラムで見ることができる。InfoQは今後も、関連する記事を読者にお伝えする予定だ。