Go界隈で巻き起こった go:linkname 騒動について - ANDPAD Tech Blog
お久しぶりです、ANDPADボードの tomtwinkle です。 この記事はGoの go:linkname 騒動は 6/18に行われた Go Bash で話した内容を要約したものです。 そもそも go:linkname とは何かといえば internal packageやprivate var/funcなど普通はアクセスできないオブジェクトシンボルをエイリアス出来るようCompilerに指示して、アクセス可能にするcompiler directiveです。 go:linkname はprivateな変数へアクセス可能な便利なものでしたが unsafe packageのimportを必須とする通り、せっかく互換性や安全を考慮して作られているGoプログラムを簡単に破壊できる諸刃の剣でした。 詳細は発表スライドを見てください。 go:linkname 禁止騒動 Go 1.23 のリリースまで2
Goでモンキーパッチするライブラリを作った - Plan 9とGo言語のブログ
Goで単体テストを実装する場合、動的な言語のように「テスト実行中に外部への依存を置き換える」といったことはできません。代わりに、 外部への依存を引数で渡す 外部への依存をインターフェイスで渡す のように、テスト対象をテスト可能な実装に変更しておき、テストの時は外部への依存をモック等に置き換えて実行する場合が多いのではないかと思います。 個人的な体験でいえば、テスト可能な実装に置き換えていく過程で設計が洗練されていく*1ことは度々あるので、面倒を強制されているというよりは設計を整理するための道具といった捉え方をしているのですが、そうは言っても動的な言語に比べると面倒だなと感じるときは少なからずあります。既存の実装がテスト可能になっておらず、変更するコストが高い場合は特にそうですね。 そんなとき、気軽にモンキーパッチできると嬉しいんじゃないかと思って、テストの時だけ関数を置き換えられるようなラ
Goのerrorがスタックトレースを含まない理由 - methaneのブログ
Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
改めて見直すGoの特徴
極力Goならではな特徴をいくつか挙げていく。 依存解決が必要最低限で互換性を考慮しつつ決定的 モジュール単位で依存をダウンロード。コンパイル対象はサブパッケージ単位。 依存の明示方法はコードに埋め込まれ、かつ未参照のインポートはコンパイルエラー。 つまり動作するコードのすべては正確な依存ツリーが明示されていて余計な依存は引き込まれない。 そして持ち前のコンパイルの速さを含め、相当深い依存ツリーでも依存解決にかかる時間は既知の処理系の中でも最速レベル。（唯一勝てるのはプリビルドバイナリが配布されている場合くらい） また、コンパイルやリンクに必要な処理量そのものが比較的少ないため、開発環境負荷も小さい。 かなり巨大なプロジェクトであってもメモリ8GBで困るようなことが無い。つまり、CI環境の維持にもローコストで済む。 ライブラリの提供側では後方互換性が破壊されるような変更はV1->V2というよ
GitHub Actions のワークフローをチェックする actionlint をつくった - はやくプログラムになりたい
GitHub Actions のワークフローを静的にチェックする actionlint というコマンドラインツールを最近つくっていて，概ね欲しい機能が揃って実装も安定してきたので紹介します． github.com なぜワークフローファイルの lint をすべきなのか GitHub Actions が正式リリースされてからだいぶ経ち，GitHub 上での CI は GitHub Actions が第一候補となってきているように感じます．僕も新規にリポジトリを作成して CI をセットアップする場合はほぼ GitHub Actions を使っています． ですが，GitHub Actions には下記のような問題があり，actionlint でそれらを解決・緩和したいというのが理由です． ワークフローを実装する時は，GitHub に push して CI が実行されるのを待って結果を確認するという
Go Style
Documents The Style Guide outlines the foundation of Go style at Google. This document is definitive and is used as the basis for the recommendations in Style Decisions and Best Practices. Style Decisions is a more verbose document that summarizes decisions on specific style points and discusses the reasoning behind the decisions where appropriate. These decisions may occasionally change based on
Goならわかるシステムプログラミング第2版が出たので書評しますね - moriyoshiの日記
少し前になりますが、3月23日に、渋川よしきさんの著された「Goならわかるシステムプログラミング 第2版 」が発売されました。初版と比べてかなり加筆されておりパワーアップしているので、初版をすでにお持ちの方でもさらに興味深く読むことのできる内容に仕上がっている、というのが第一印象です。 残念ながら初版発売時に記事にする機会がなかったのですが、あらためて今回書評したいなと思いましたので、徒然書いていきたいと思います。 この本は実はシステムプログラミングの本ではないかもしれない 「システムプログラミング」とは何でしょう。正直私にもわかりません。その語をはじめに思い浮かべた人は、プログラミングという概念のその中にあえて「システムプログラミング」という分類を作ろうと思い至ったということですから、きっと「非システムプログラミング」というものもあるということでしょう。知らんけど。しかし、これは本書の位
GoとRust - 並行プログラミング編
はじめに こんにちはnasaちゃんです。 goroutine何も分からん!async/await何も分からん!となったのでそれぞれを比較しつつ理解を深めてみよう。という考えのもとGo, Rustの並行プログラミングの解説記事を書いてみました。 ところどころふわっとしているため、補足や指摘を貰えると大変助かります。 今回話すこと goroutineとは結局何なの Goの並行処理の仕組み goroutine(Go)とasync/await(Rust)の比較 Goのランタイム、Rustのランタイムの話 話さないこと 構文の違いについては特に触れない どちらが優れているとい言う話はしない ベースになっている思想については特に触れない TL;DR Goには標準のランタイムがあるよ、Rustではランタイムライブラリを使う必要があるよ Goはランタイムが中断再開を管理するよ、Rustではプログラマーが管
Faster sorting with Go generics - Eli Bendersky's website
Recently, a new set of sorting functions has landed in Go's golang.org/x/exp/slices package [1]. These functions leverage Go generics to provide a more ergonomic API for sorting (without requiring users to implement sort.Interface), and also deliver a nice performance improvement, as the CL demonstrates. In this post, I'll dive deep into why these generic functions are faster than the existing one
Generics can make your Go code slower
Go 1.18 is here, and with it, the first release of the long-awaited implementation of Generics is finally ready for production usage. Generics are a frequently requested feature that has been highly contentious throughout the Go community. On the one side, vocal detractors worry about the added complexity. They fear the inescapable evolution of Go towards either a verbose and Enterprisey Java-lite
Scrapboxのコマンドラインクライアントを作った - 詩と創作・思索のひろば
ちょっとした手元の自動化を行おうとしたときに、Scrapbox のページ一覧を取得したり、プロジェクトの情報を取得したりしたくなる。Scrapbox ではとにかくほぼすべてが わかりやすい JSON API 経由で行われているわけなので、これをしてくれるコマンドラインツールがほしいわけです。 GitHub - motemen/sbx: An unofficial Scrapbox client ちなみに完全に野良だし、API も内部 API とされていて安定はしていないはず。そういうものです。 使い方 API の薄いラッパーなので基本的に JSON を返す。--jq オプションで結果を gojq で編集できる。 % sbx page list help-jp --limit 5 --jq 'map(.title)' [ "Scrapboxの使い方", "ブラケティング", "ページをリンク
jsondiff: JSONの構造の一部を無視して差分をとれるGoのライブラリを書いた - Sexually Knowing
github.com 背景 仕事でお世話になっているkayac/ecspressoの機能の中にローカルのタスク・サービス定義と現在使われている定義を比較して差分を出力してくれるものがある。 github.com これから加えようとしている差分をプレビューできるだけではなく、たとえばデプロイしようとしているわけでもないのに差分があればローカルの定義が古びていることがわかるのでCIに組み込めると便利。 しかし実際に使おうとすると困る点が見つかった。 たとえばタスク定義にイメージタグを書く際に {{ must_env 'IMAGE_TAG' }} のように環境変数を参照している時に「イメージタグ 以外 に差分がない」ことを確認するのが難しいということ。 理想的には image を無視したJSONの構造を比較して差分が出せると良い。あるいは出力されるdiffをパースして image の差分は無視す
“Sustainability with Rust” post misleading about Go | Hacker News
I struggled for years with a chronic misunderstanding of Go. I kept trying to compare it to the usual suspects in the "next systems language" crowd (D, Rust, Zig). That wasn't quite right.Once I realized that its sweet spot is large-ish services that you want closer to the metal than Java but for which would be silly to go as low level as C++, Go fans started making a whole lot more sense to me. I
Go言語のジェネリクス入門
Go1.18は2022年3月にリリースされました。このリリースはGo言語へのジェネリクスの実装を含んでいます。 この記事ではできるだけ最新の仕様と用語法にもとづいてジェネリクスの言語仕様について解説していきます。 更新履歴 2024/01/03: Go1.21(2023-08-08)でcmpパッケージが標準ライブラリに追加されたことに対応しました。 2023/02/23: Go1.20(2023-02-01)のcomparableの仕様変更に対応しました。 次の関連資料があります: The Go Blog - All your comparable types Griesemer氏によるGo公式ブログです。 Go言語のBasic Interfaceはcomparableを満たすようになる(でも実装するようにはならない) 上記の内容に対する筆者の解説記事です。Go1.20リリース前に書いたの
Goのなぜ問答
はじめに Goはできるだけ冗長な機能セットを増やさずに応用の効くシンプルで強力な機能セットに絞り込んだ設計であることを目指した言語処理系です。なのでリッチな機能を持つ言語処理系経験者からするとたくさんの「なぜ？」を感じると思います。 しかし、Goの開発者たちは他の言語処理系にある機能だからGoにも採用しようとは一切考えません。あくまで大きなゲイン（デメリットをメリットが大きく上回る）を示されるまでは採用しません。特に言語仕様についてはより変更を嫌う傾向があります。「Go1の約束」というものがあり、Go1.0向けに書かれたコードはGo1.xでも動くもしくは機械的にコードにパッチを当てることで移行可能にするということをずっと守っています（約９年？）。 最近になりGo2プロポーザルがたくさん書かれ、それらの提案のうち言語仕様に関するものは最終的に２〜３個に絞り込まれ順次採用されていくという計画で
I'm porting tsc to Go
I’m porting the TypeScript Type Checker tsc to Go, and not Rust. As the creator of SWC, an extensible Rust platform, this might sound strange. Let me explain. Why port tsc?# As TypeScript continues to rise in adoption, large projects are facing a dilemma: type checking is one of the slowest parts of their workflow. Developers want type safety without the tradeoff of slower iteration cycles. The Ty
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Using JQ with SQLite
GitHub - TomWright/dasel: Select, put and delete data from JSON, TOML, YAML, XML and CSV files with a single tool. Supports conversion between formats and can be used as a Go package.
GoのGenerics関連プロポーザル最新状況まとめと簡単な解説
Generically working with Kubernetes resources in Go