3781f49ea2c76d6ecf0c6cda46096d49

iOSDC2017でやっていきが高まったCreated on 2017-09-20 by omochimetaru

iOSDC2017に参加した。
参加者全員ブログを書くことが強く推奨されているので書く。
(@は敬称とする)

個人的に一番良かったセッションは @taketo1024 の数学のやつ。

Swift で数学のススメ 〜 プログラミングと数学は同時に学べ
https://www.slideshare.net/taketo1024/swift-79828803

群、環、ユークリッド環、体をプロトコルで表して実数に適用させ、
抽象的にユークリッドの互除法を実装することで、
それを多項式上でも適用可能になって、
体の拡大をして、解析的な二乗根や虚数を構成する、みたいな話を、
解説とコードを交えながらものすごいスピードとテンションで解説してた。
終盤の数学の話は知らなかったので今度学びたい。
大学で群、環、体とかバナッハ空間とかやったとき、
これって型付けして整理すればコンパイラサポートが受けられるのに、
頭で全部把握して取り回すのはややこしいなあ、と思ったのを思い出した。
Swiftのプロトコルには型クラス的な特性があるし、
こうした実装に相性が良いよなと思った。
ただ、質疑応答で、「依存型が無いのでできない事もある」と言っていたが、
何のことかわからなかったのでこれも宿題になった。

@taketo1024 は次のSwift Tweetsで一緒に登壇するのでその点でも刺激を受けた。

https://swift-tweets.github.io

@sonson_twit の発表では、2ちゃんねるブラウザの実装上の工夫について聞けた。

Swiftで実装するHTML特殊文字の高速処理
http://sonson.jp/blog/2017/09/18/iOSDC/

utf16で処理するのはパフォーマンス上優位だからなのか、
utf8やutf32との対比ではどうなるのか?
と質問したら、おもち君実装して調べて、と返されて、
そのあとハッシュタグ付きでツイートされてしまったw

これも宿題。

↑のブログに出てくる

KotlinとSwiftのラムダ式内でのreturnの取り扱いの是非で,30分も口論,失敬,議論できるエンジニアが世の中にいて

のくだりは @inamiy, @koher, @takasek, 僕 などの事ですね。

この話題の発端は

@eduraaa の Swift と Kotlin という発表の質疑応答で、

https://speakerdeck.com/ezura/swift-to-kotlin

@d_date が 質問したことに対して @eduraaa がちょっと回答に詰まっていたので、
僕が横槍を入れたあたりにあった。

他に印象的だった発表は
@ainame が SidekiqをSwiftでクローンしたLumpikのパフォーマンスについてのもの。

https://speakerdeck.com/ainame/server-side-swiftshi-yong-xing-ping-jia-2017-number-iosdc-number-b

Ruby実装よりSwiftが速くなったのは良いとして、Crystalのほうが速いとされていてマジかよ・・・となった。
CrystalというのはRubyの構文をもった型推論言語で、
Ruby on Railsからの移行先としての Server Side Swift という観点ではライバルに当たる言語だ。
CrystalはRubyに構文が似てるしTrace GCもあるが、
Swiftは似てないしARCなので、これで速度面でも優位性が無ければ、SSSの将来性が結構揺らいでくる。
個人的にはSwiftが大統一してほしいのでそれは困るので不愉快な気分になった。

帰宅してからとりあえず結果を追実験するぞ!と思って、
Linux版のSnapshotビルドをインストール、
しかしビルドできないので、これはホヤホヤのmasterが必要なのか?と思って、
Swiftをビルドし始めたが、T2microではビルド中にバーストクレジットがなくなって、
CPUパワーが10%に落ちてこれ無限に終わんねえな、
となっていたところで、
@ainame からリプが来てどうやらMac上での実験だった。
SSSの話だからLinuxかと早とちりしました。

で、Mac上でやってみたら、同様に Crystal > Swift > Ruby という結果が出てしまいました・・・。
Swiftの場合 GCD で25並列ぐらいのワーカーが回っているのに対して、
Crystalは1スレ中のファイバーによるグリーンスレッド + GCスレッドx3という構成で、
うーんナンデ。
Swiftに対して Time Profile かけたところで、ボトルネックが2箇所ほど特定、
片方は vapor/core に含まれる効率悪そうなコード、
片方は Swift4 の Codable が遅いっぽい、というところまで進んで、
さーどうするかととりあえず @ainame に投げたら、
それはわかったけど考えてそのままにしたよ、とリプが返ってきた図。

はい、見えない背中を追っていただけだったのでした。

この件についてはとりあえずCPUバウンドで並列性が効くタスクなら勝てる勝てる、
と思っておくことにする。。
(ベンチマークは空のタスクなので単なるredis通信のオーバヘッドが支配的)

ちなみに @ainame@r7kamura とシェアハウスしていたことがあるらしい。
パワを感じる。

懇親会では @yutailang0119 に10月の登壇での発表内容に期待してます、
的なことを言われてやっていきが高まった。
Ownership Manifestoの僕の微妙な和訳を参考にしながら、原文も読んだらしい。

https://github.com/omochi/swift-ownership-jp/blob/master/OwnershipManifesto.md

役にたってよかった。
発表についてどうしようというのは @tarunon とも話して、
とりあえず下書きは @tarunon 向けに書くことにした。
その後ブラッシュアップしていけば良いだろう。

@inamiy にはtry-swift nycのときに僕が日本からlibSyntaxの作者に質問を代行してもらったのだが、
それを覚えていてその件について会話をした。

僕はAppleのソースツリーから SwiftSyntax を切り出してSPMパッケージ化して、
その際に一部 swiftc のinvocationを修正している。

https://github.com/omochi/SwiftSyntax

で、それを利用してちょっとしたツールを作っている。

https://github.com/omochi/SwiftPack

それについて話したら、担当の人は良い人だし連絡とりなよ〜的なことを言われた。
これも宿題。

他にも、 僕の enum の話とかが、

https://qiita.com/omochimetaru/items/991b5e3d9a0c713a628e

そこまで調べてる人少ないし面白い話題だから try-swift とかで発表したらいいと思うよ、
などと言われた。
うーんハードル高いンゴね。

ついでにSwiftPackについて書いておくと、
Swiftのライブラリ、SPMで依存組むまでもなく、
直接ソースで取り込みたいときがまれにあるので、
そういうときにそれを支援するためのツール。

クラスや関数の可視性を fileprivate にしてからソース全部くっつけて1ファイルにすることで、
ライブラリの機能をワンファイルに閉じ込めてプロジェクトを汚さないようにする。
これだと何も使えないので、指定した名前については internal にする機能も用意する。

他にも、可視性を全て internal にして、
ライブラリ内にライブラリをソースで埋め込みつつ、ライブラリ外には漏らさない、
というパターンも想定している。

簡単なテキスト変換だけど、 libSyntax をベースにしているので、
構文の複雑化に対して追従する下地があるし、
コメントなどもちゃんと維持してテキスト操作が可能。

まだ完成度が中途半端なので、
これは進捗が出てきたら記事にするつもり。

そんな感じで
書ききれてないけどいろんな人と話したし、
知り合いも増えてきた。
やっていきが高まったし宿題がいろいろ出た。
まずはSwiftTweetsの下書きを作る。