1 ポイント 投稿者 GN⁺ 1 일 전 | 1件のコメント | WhatsAppで共有
  • 型安全でスケーラブルなシステムを目指すGleamリポジトリをTangledでも利用可能
  • デフォルトブランチはmainのみで、約11,000件のコミット、スター254件、フォーク2件を記録
  • リポジトリのコードは**Rust 92.9%**が大半で、JavaScript 3.6%、Gleam 1.8%などが続く
  • コンパイラと言語サーバーからWASMコンパイラ、Erlangコード生成器、フォーマッタ、テストプロジェクトまで、1つのリポジトリで管理
  • Gleamは企業所有ではないスポンサー支援プロジェクトで、プロジェクトとコアチームメンバーの双方を支援できる

リポジトリ構成

  • gleam.run/gleamGleam言語のTangledリポジトリ
  • 主な構成要素は以下のとおり
    • compiler-cli, compiler-core, compiler-wasm
    • language-server, erlang-generation, erlang-term-format
    • format, hexpm, gleam-bin
    • ベンチマーク、ドキュメント、コミュニティパッケージ、コンパイラ関連のテストプロジェクト
  • mainが唯一のブランチかつデフォルトブランチで、公開タグはない

言語比率とクローン方法

  • 言語別の比率はRust 92.9%、JavaScript 3.6%、Gleam 1.8%
  • HTMLとCSSはそれぞれ0.4%、ErlangとShellはそれぞれ0.3%で、TypeScript、Makefile、Dockerfile、Elixir、PowerShellも含まれる
  • HTTPSとSSHでクローンでき、tar.gz.zip形式のダウンロードにも対応
  • セルフホストしたTangled knotでは、設定によってクローンURLが変わる場合がある

最近の開発作業

  • 最近のコミットには、フォーマッタとJavaScriptコード生成の性能改善、廃止された引数を持つexternalのErlang生成コード修正が含まれる
  • 言語サーバーには、variant生成コードアクションのタイトルに型名を入れ、数値の基数変換コードアクションを追加する変更が反映された
  • 異なる基数の負数を許可し、コンパイラの提案文言とtodo警告文言も改善
  • HEXPM_READ_API_KEYを設定すると、Hex依存関係の探索とダウンロードリクエストを認証する
    • 厳格なIP別制限の代わりに、より高いユーザー別リクエスト上限が適用される

プロジェクト運営

  • Gleamは型安全性を基盤に、スケーラブルなシステム構築を目指す
  • 企業が所有しているものではなく、スポンサーの支援によって運営されている
  • Gleamスポンサーシップページで、プロジェクトまたはコアチームメンバーを支援できる

1件のコメント

 
GN⁺ 1 일 전
Hacker News のコメント
  • この記事には文脈の説明がもっと必要です。今のままだと、そもそも説明不要な人だけがすぐ理解できます。
    https://knowyourmeme.com/memes/curtains-for-zoosha

    • Gleam は Erlang や Elixir が好きな人たちに人気のある言語で、いずれも BEAM 仮想マシンを基盤にしています。
      Tangled は Bluesky と同じ ATProto の上に構築された、分散型の GitHub 代替です。
    • リンク先ページが、再投稿された普通のツイート1つを何画面分もの「コンテンツ」に引き延ばしていて、肝心の内容が芸能ニュース記事のように読めてしまうのは皮肉です。
    • それならこのサイト、つまり HN(Hacker News)が何なのかから説明すべきかもしれません。
  • Tangled は初めてで登録してみましたが、新規ユーザー体験を磨く必要があります。メール入力と認証を経てユーザー名を作ったのに、その名前で直接ログインできず、見慣れないソーシャル URL プロトコルまで覚える必要がありました。
    認証の途中では、プロジェクト所有に見えるもののブランディングや色がまったく違う画面と URL に移動し、パスワードマネージャーがそれらを関連付けられませんでした。登録時の摩擦にはかなり敏感なほうですが、プロジェクト自体は興味深いので、このフィードバックが役に立てばと思います。

    • 私の登録・ログイン手順は「ログインをクリック → 既存の Bluesky ハンドルを入力 → bsky ドメインのログイン画面でパスワードを入力 → 承認をクリック」だけでした。現段階ではこの経路のほうが最適化されているようです。
      アプリとアイデンティティが密結合していないため別インフラを用意したものの、画面の完成度にはまだあまり時間をかけていないように見えます。独自アカウントを作っていないのにユーザー名でログインできないなら、何を使うべきなのか気になります。
    • 私の場合はそれよりひどく、Failed to complete sign up. Try again later. というエラーだけが表示されました。
  • Gleam は小さく洗練された設計を志向する興味深い言語です。最近 Ubuntu Summit で Gleam チームに会いましたが、小さく保ちながら慎重に作っていくという設計哲学を、発表で見事に伝えていました。
    Giacomo がすべての画面遷移を自分でアニメーション化したと言っていましたが、発表自体も小さく丁寧に作られていて、中心となるメッセージをさらに強めていると感じました。
    https://youtu.be/E6_JqYMeNqs
    https://discourse.ubuntu.com/t/gleam-and-the-value-of-small/...
    https://en.wikipedia.org/wiki/Gleam_(programming_language)

  • Tangled で自前の Knot サーバーを運用してみましたが、リポジトリは Knot に正常に作成される一方で、その後の変更が Tangled には表示されませんでした。
    Knot には IPv6 接続がありましたが、安定して動かすには複数の IPv4 NAT を有効にし、ダミーの A レコードまで作る必要がありました。これは既知の問題です: https://tangled.org/tangled.org/core/issues/494

  • なぜ Codeberg ではなく、ベンチャー投資ベースの Forgeを選んだのか気になります。「親しみやすい言語」という主張ともあまり合っていないように見えます。

    • 「Tangled にある」というのは、実質的には sh.tangled.* ATProto レコードを発行するという意味です。tangled.org の Web アプリの背後にあるベンチャー投資会社に縛られる構造ではなく、アプリがプロトコル上で公開された Git リポジトリを読み取り、見やすい画面で表示しているだけです。
      同じレコードを読む別の ATProto アプリも同じ情報にアクセスできます。リポジトリ自体も Tangled に置く必要はなく、Git、SSH、HTTP、WebSocket をサポートするサーバーで直接ホストできます。
    • Tangled の資金調達方法は好みではありませんが、ATProto にはインターネットを改善する大きな可能性があると思います。Gleam コミュニティでもこのプロトコルへの関心が高く、Gleam リポジトリのミラーをホストするのに適していると判断しました。
    • Gleam は今もGitHub にも残っています。正式な移転ではなく、ATProto ベースの Forge にも追加で置かれただけです。
    • 金銭的支援の条件だった可能性が高そうで、結局のところ中核的な価値はコミュニティよりお金なのだという苦い印象を受けます。むしろプロジェクトでは Elixir を使うことに集中します。
  • Tangled を初めて使ってみましたが、実用が難しいほどバグが多いように見えます。リポジトリを作ったのに 404 が出て見られず、同じ ATProto ハンドルを毎回コピーして入力したにもかかわらず、ログインにも何度も失敗しました。
    それでも、Git ホスティングの代替を開発するチームが増えるのは歓迎です。

    • 初期の GitHub でも、リポジトリを非同期に作成しながらすぐ遷移させていたため、同じことが起きていました。数秒後に再読み込みすると表示され、その後は待機してから自動で遷移する中間画面が追加されたと記憶しています。
  • しばらく分散型 Git サービスを探していて、自前ホスティングも始めましたが、ソーシャル機能が不足していました。Tangled についてもっと知りたいです。

    • Radicle は目標にもう少し近く、自前ホスティングと連合が可能です。ただし GitHub のような社会的重力を備えた代替を見つけるのは難しく、この要素を Forge から切り離せるのか、それとも一緒に提供する必要があるのかはまだ不明です。
    • 現時点では、画面と API 自体を自前ホストできないようです。Git サーバーである Knot と CI ランナーである Spindle は運用できますが、サービス全体はまだやや中央集権的で、それを変える作業が進んでいます。
    • 会社がフィンランドに登録されているという事実以外、誰が運営し、どのように資金調達しているのかは見つけにくかったです。
  • プロジェクトを1つ Tangled に載せてみる気はありますが、既存サービスとの差を埋める機能セットにはまだ道のりがあります。特に、リポジトリを閲覧するだけでも発生する GitHub の障害が大きな妨げになっています。

    • ATProto という雰囲気だけで Tangled を選ぶより、より成熟した Codeberg や、自由・オープンソースの Forgejo または Gitea を使わない理由が気になります。
    • GitHub の障害への不満から、確実に別のサービスを探し始めました。
  • Tangled が Codeberg とどう違うのか、移行プロセスはどのようなものなのか気になります。

    • どちらも使っていますが、Tangled には非公開リポジトリや保護ブランチのような重要な機能がまだありません。一方で画面は Tangled のほうが心地よく感じられ、Codeberg は私の環境ではかなり遅いです。
      CI/CD は使っていないので複雑な移行プロセスまでは分かりませんが、ホストされた Knot にリポジトリを push するのはとても簡単です。自前で Knot を運用するのも難しくなく、コードを送るサーバーの少なくとも1つを自分で所有している点が気に入っています。
    • Tangled は Forgejo や Codeberg と違い、ATProto 連合プロトコルを中心に構築されている点が大きな違いです。
  • Tangled が何で、どの Gleam のことなのか分かりにくいです。

    • 分かる人だけ分かるタイプの記事に見えます。リンクを開いても Tangled と関係ありそうな内容はほとんどなく、対象読者が限られた HN 投稿の中でも特にひどい部類です。
      URL が Tangled だという手がかりは、3回目に開いてようやく気づくほど微妙で、ランディングページには Tangled を説明する内容が実質的にありませんでした。