Denoばた会議 Monthly 第12回

2022年8月28日開催。
connpassリンク。

今月のアップデートを追う

Denoのアップデートを追っていくLT。
そのあとの雑談込みでザックリと箇条書き。

@uki00aさんのスライド

Deno v1.25

npmパッケージのサポート

npm:<パッケージ名>でnpmパッケージをimportできる
npxライクにパッケージを実行することもできる
去年の10月この機能の検討を始めた
今年の前半は、Deno社の方針が変わって、npm互換性にあまり力を入れていなかった
Bunの登場などもあり再度npm互換性への意識が高まり、ついに実装する事になった

新しいHTTPサーバ (Flash)

Deno.serveで利用できる
チューニングをしていく中でtokioのスケジューラが遅い事が分かってきた
- tokioはマルチスレッドプログラミングをサポートするためのsystem callをいくつか発行している
- Denoのhttpサーバーの実装だと2スレッドしか使わないため、それらのsystem callが純粋にオーバーヘッドになっていた
tokioのさらに下のレイヤーのmioを直接使って、それより上の部分をRustで作り直しつつチューニングする、という作業を行った
bunの影響が大きい
Bun.serveに近いものになっている
honoというフレームワークの作者がベンチマークして、Bun.serveより速くなっていることを確認（SlackのキャプチャURL）
Windowsでかなりバグっているという話なので今後修正される
まだ不安定なところがあるが、改善していく

`deno init`コマンド

npm initやyarn initなどのようにプロジェクトの初期化ができる
社内で物議を醸した
Deno本体でやることなのか？という疑問視
社内で駆け引きがあって、本バージョンでリリース

FFIへの"buffer"型の追加

破壊的変更
今後は、TypedArrayを渡す際は"pointer"型ではなく"buffer"型を使う必要がある

パフォーマンス最適化

依存関係の解析結果をキャッシュすることによる起動時間の高速化
- 依存関係は0から解決していて、それが遅くなっていた
- ts_morphの解析が遅くて1秒くらいかかっていたが、200ミリ秒ぐらいに短縮された
- サードパーティの解析が速くなった
V8 Fast Callsを使用したopsの最適化の仕組みが導入
- V8の新しい仕組み
- ネイティブバインディングより速い
- V8に色んな値を渡せなくなるが、その代わり速くなる
Deno.open(Sync)やWeb Streams APIなどが最適化
FFIの高速化もしている
Bunを意識している
Deno FFIとBun FFIが速いというベンチマークをBunに出されてしまった

Big Changes Ahead for Deno

Denoの今後の計画についての発表
Node.jsとの互換性の向上
- npmパッケージのサポート
パフォーマンスの向上
エンタープライズユーザへのサポートの強化
- オフィスアワーというのを設けていく
開発体験の向上
- サードパーティモジュールやAPIの検索性の向上
今まで作ったものについては書いていたが、作るものについては書いていなかった
今回、大きな変更があったので告知が出された
ブログ時点だとロードマップという感じだったが、本バージョンで姿が見えてきている
Bunをかなり意識している
Bunに対するデカい牽制球という感じ

Deno Merch

DenoステッカーやDenoパーカーとかが販売されている
GraphQL Storefront API(Shopify)やFreshなどを使って開発されている
Denoのショーケースアプリの最後弾
雨の速度ゆっくりとかhashrockさんのこだわりが見えるアニメーション
商品はAndyさんがポチポチして送る
ソースコードはオープンになっている
Deno DeployでECサイトを作れるというサンプル
割と期限超過した案件だった
- 本来はQ2（6月末）で出さないと行けなかったが、全然進んでいなかった
- Colinさんがどうにかしてくれた、ありがたい

Freshのロードマップ

プラグインシステム実装
<Head>の非推奨化 (代わりに<head>を使う)
マージまではされているので、次のバージョンでリリースされる
UnoCSSとTwindのどちらがいいのか、というのがlucaさん周りであった
UnoCSSもサポートしたいが、TwindはTwindで使いたいのでということでプラグインシステムが作られることに
AlephはUnoCSS
メディアクエリはUnoCSSのほうが便利そう

PrismaのDenoサポート

まもなくprisma generateコマンドが動かせるようになるかもしれないとのこと
PrismaのgenerateはNode向けで、そこから吐き出されるのをnpm:にならないとうまく動かない
Bartekさんの「まもなく動くかも」はもうちょっと気長に考えるほうが良さそう

deno-jaのLP

hashrockさんがdeno-jaのLPを作ってくださった
Deno Newsでも紹介されている
Deno社からWeb+DBに声をかけて広告枠として買った

Deno社の社員の話

Deno社メンバーページにいくつか更新あり
- crowlさんとdivyさんはインターンから社員になった
- Alonさんという方がDeno SurveyをやってくれていたDeno社の戦略運用責任者
- hashrockさん入社🎉🎉🎉
  - 今までバイトという感じでDeno関連のイラストを描かれていた
  - deno-jaのアイコン作るのもこの一環という感
  - ijeさんはデザイン寄りの人で、デザイン技能ありという人はProduct Engineerと表記される傾向
- 退社されたBenさんがパートタイムで復帰した
  - パフォーマンスをカリカリにチューニングするのが得手で、そのために復帰してきたような感じ
  - パフォーマンスチーム周りは「こういうことできるんだ」を毎日のように盛り上がってる

LT1

skanehiraさん
ゴリラ.GoなどGo界隈で活躍されている方
ここ1年くらいDenoを使われている
先日記事を書いた
マルチプラットフォームでクリップボードを扱えるDenoモジュールを作った
- Rustの勉強として作った
- 外部依存なしのクリップボードモジュール『arboard』をFFIで呼び出している
- 外部依存なしのクリップボードモジュールが作りたいという理想をモチベーションとして始まっている
- Denoからクリップボードを使うことがあるのか？
  - VimでTwitterをするdenops-twihiで使っている
  - webview_denoなど、GUIアプリを作るときにも使い所があると思う
- Linuxだけ正常に動作しないが、WindowsとMacは正常に動いている
  - Linuxはxclipに依存することで動作している
  - 理想実現のため改善したいが原因わからず、ご存じの方がいれば教えていただきたい
- Denoがdeno_bindgenを提供しているので小難しいことはせずに作れた
- 途中、deno_bindgenのバグを見つけてPRを送った
  - テストも書きたかったが、今回はやめた
  - リリースすれば使うものがバグっていたので、deno_bindgenをskanehiraさんしか使ってない可能性
  - 完成度を上げきれてないところなのかも、PR感謝
- 他にも気になる点がある
  - 構造体をポインタで受け渡ししているところがあるが、rustのclipiyが#paramsあたりが引っかかってる
    - unsafeにしてないので分岐が必要そう？
    - lib.rsの211行あたり
- Rustの手続きマクロは手続きなので処理が複雑になりがち
- このマクロで別言語を作れるくらい表現力は高いが、そのぶん複雑

※ 記事についてザックリと書きましたが、記事がとても読みやすくわかりやすかったので、記事を読んだほうが当然ながら理解は早いです

質問や共有コーナー

ARMのLinux版が用意されていないが、対応予定はあるのか
- GitHub Actionsにくれば確実に対応する
  - リリースはGitHub Actionsで行なっているため
- ARMのMacとLinuxがGitHub Actionsにない
- ARMのMacは需要があるので手作業でリリースに乗せている
- 現状はサードパーティに頼るしかない
Deno deployでプロセスって何秒継続できるのか調べたりした
- 検証したが、大体カウント950前後くらいまではプロセスが生きてる
- CPUタイムを何ミリ秒縛りというが合って、それに引っかかるはず
  - リクエストあたりのミリ秒
- 数百秒くらいは生きてる
  - ウォールクロックタイムでは絞ってないので長期まで行っちゃう
- CPUタイムで絞られている
- 1秒ごとにログ出したら900秒いけたのなら、例えば3秒ごとにしたら3倍になるかも？
Deno Deploy専用のロゴが作られる予定があるのか
- Deno Deployボタンというので専用のロゴがあったが、今は本体と同じものが作られている
- デザインシステムを作っている方がいるので、もしかしたら将来的に作られるかも
Deno Deployで書き込み系でパーミッションエラーが出たが、対応予定はあるのか
- Deno Deployは厳密にはファイルシステムを持っているわけではない
- パーミッションエラーと出ているが、アーキテクチャ上できない
- 別の場所にファイルサーバーがあって、そこからfetchしている
- 書き込み系だとキャッシュというのが追加される予定なので、待ってみてほしい
HTTPサーバーの新しい実装について、原因を探しているときはtokioのスケジューラがDenoと合ってなかったという記憶だが、その後どのように解決したのか
- ファイルに関係ないシステムコールが出されていた
- マルチスレッド用のシステムコールがあって、そこがオーバーヘッドしていた
- メインのスケジューラは外した
- tokioのmioというベースを使ってDenoに合うものを作った
- BunのベンチマークはHTTP/1.1で出していて、それがメチャ速いという話で、HTTP/1.1で最適化するかという話（HTTP/2誰も見てないなら最適化してもしょうがない、HTTP/2のプロトコルは面倒）
- NodeのアプリケーションサーバーがHTTP/2までしかないが、HTTP/3はどうしているのか
  - Issueの中に「実装してくれたらお金出します」というスレッドもあった
  - ロードバランサーでHTTP/3でしゃべらせてるので必要ない、という人もいそう

Bunの話

Node互換のJavaScriptランタイム
Bunがオープンソースになった
Ovenという会社ができた
- 7百万ドル（約9億円）の資金調達を行なった
よりDeno社の脅威になっている
求人ツイートが炎上した
- 「Oven社は最初の9ヶ月はキツい、ワークライフバランスが仕事量を減らすという意味だったら、貴方はこの会社には向いてない」（意訳）
- 引用RTが1000まで行ったところで削除された
- 自分でメチャクチャ優秀なエンジニアが募集してきたよって引用RTしてたが、それも含めて削除された
- kitsonさんが1日8時間くらい残業は月10時間くらいかなータイムゾーンの関係で業務外にコメント飛ぶことがあるけど、
- 週90時間働いているので同じレベルの人を求めてそういった可能性がある

参考資料

上記をまとめる際に眺め、かつ箇条書きの中に含められなかった資料です。
名前だけ掠ってて関係ない資料もあるかと思いますが、まとめる作業の可視化として残しています。