Goのエラースタックトレースの歴史と今後Jetpack ComposeとGraphQLによるServer Driven UI/jetpackcompose-grahpql-serverdrivernui
unexportedなmethodを持つGoのinterfaceとsum type - 3日経てば忘れる
何か書けと後輩に詰められたので、寝る前に雑に調べごとをしてメモを残しておくことにする。 これは8日目。 adventar.org Goのinterfaceに書けるメソッド名にはidentifierが指定されているだけで特に制限が無い。 つまり、unexportedなメソッドを定義することができる。 InterfaceType = "interface" "{" { ( MethodSpec | InterfaceTypeName ) ";" } "}" . MethodSpec = MethodName Signature . MethodName = identifier . InterfaceTypeName = TypeName . ( https://golang.org/ref/spec#Interface_types より ) 周りのコードを見渡してみると、例えば reflec
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のerrorがスタックトレースを含まない理由 - methaneのブログ
Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
Go 1.22 is released! - The Go Programming Language
The Go Blog Go 1.22 is released! Eli Bendersky, on behalf of the Go team 6 February 2024 Today the Go team is thrilled to release Go 1.22, which you can get by visiting the download page. Go 1.22 comes with several important new features and improvements. Here are some of the notable changes; for the full list, refer to the release notes. Language changes The long-standing “for” loop gotcha with a
What We Got Right, What We Got Wrong
This is my closing talk (video) from the GopherConAU conference in Sydney, given November 10, 2023, the 14th anniversary of Go being launched as an open source project. The text is interspersed with the slides used in the presentation. What We Got Right, What We Got Wrong INTRODUCTION Hello. Let me start by thanking Katie and Chewy for the giving me the honor of presenting the closing talk for the
Goで非推奨(Deprecated)や撤回(Retracted)を明示する方法 - Plan 9とGo言語のブログ
最近のGoには、関数やパッケージを非推奨と扱う方法があります。まとまっていると便利かなと思うので、種類ごとにまとめてみました。GoDocコメントを多用するので、GoDocを書き慣れていない場合は以下も参考にしてください。 blog.lufia.org 関数と型を非推奨にする 関数コメントに、// Deprecated: ではじまる段落を追加します。 // Parse parses a string of the form <status>=<status>. // // Deprecated: Use ParseStatusMap instead. func Parse(src string) (map[Status]Status, error) { ... } 型の場合も同様に。 // Error is the interface that wraps Error method. //
Goの日時比較が覚えられない件
不等号の向きが一緒なので覚えやすいですね！ 追記ここまで 確認コード 日時の比較をわかりやすくする Bad Know-How として Time.UnixNano を使うという手があります。 Unix Timestamp は整数なのでおなじみの比較演算子を使えます。 ただし厳密には Monotonic Clocks があるので、結果がことなる場合があることに注意が必要です (SEE ALSO: Go1.9 から使える Monotonic Clocks を試してみた)。 あとは Time.UnixNano の戻り値は 1678 年から 2262 年の間でしか保証されないというのもありますね。 2262 年問題が発生するけど、みんな気にしないんだろうか・・・まあ気にしたところで、そのとき作者は死んでるわけですが。 とはいえ 2038 年問題を埋め込んでしまった人たちも同じことを考えていたはず。
Go言語のAPIサーバーの冗長なエラーログを40%削減した話 #LayerXテックアドカレ - LayerX エンジニアブログ
こんにちは。バクラク申請・経費精算エンジニアの@upamuneです。先週末は30kmのトレイルレースがありましたが、今週末はフルマラソンがあるので満身創痍です。 この記事はLayerXテックアドカレ2023の22日目の記事です。 私はなぜか3日分もテックアドカレに入れてしまったのですが、2回目の今回はAPIサーバーのエラーログを40%削減した話をします。 昨日は@tataneによるバクラクの Vue3 移行戦略と詰まったポイント #LayerXテックアドカレ - LayerX エンジニアブログでした。明日は@trsによる入社エントリーです！楽しみですね。 はじめに 弊社では基本的にGo言語を利用してAPIサーバーを実装しています。エラーが発生したら、調査しやすいようにエラーログを出力して調査しやすくしていますが、1つのエラーに対して複数回の冗長なエラーログが出力されるという問題がありました
Goの自動テスト高速化のための調査と改善手法 - Cluster Tech Blog
はじめに こんにちは、クラスター株式会社でソフトウェアエンジニアをやっているid:shiba_yu36です。 クラスターではGoの自動テストをCircleCIで実行しています。入社して以降、この自動テストの実行時間が少し長いと感じたため、調査と改善を進めてきました。結果として速度を改善できたので、この記事でGoの自動テスト高速化のための調査と改善手法について共有したいと思います。 はじめに Goの自動テストで課題だったこと 最終的な結果 自動テスト高速化の流れ テスト実行時間のボトルネックを調査する CircleCIのTIMINGタブで大まかなボトルネックを調査する make testのボトルネックを調査する 高速化でやるべきことを決定する 1つずつ改善し結果を計測する go generateの成果物をレポジトリにcommitし自動テスト上では実行しない: 2分短縮 ビルドキャッシュを用い
GitHub Actions上で安定したベンチマーク環境を得る（ただし、相対比較専用） - Copy/Cut/Paste/Hatena
現在、実験的にですが少しパフォーマンスを気にしたいパッケージを書いています。 ちなみに、その1つはリバースプロキシです。 github.com 「気にしたいパフォーマンス」というのは以下の2つです。 現在のGoの実装がNGINX（のリバースプロキシ機能）と比べてリクエストあたりの処理時間が小さいか 現在の実装が以前の実装（Pull Requestであればmainブランチ）と比べてリクエストあたりの処理時間が極端に大きくなっていないか GitHubにリポジトリがあるのでCI環境としてはGitHub Actionsがあります。 そこで、上記2点をGitHub Actions上で継続的に計測したいと考えました。 まず、1つ目の「NGINXとの比較」ですが、これはただNGINXを使ったベンチマークと自分の実装を使ったベンチマークをそれぞれ実行することにしました。 NGINXを使ったベンチマークの結
What Color is Your Function? – journal.stuffwithstuff.com
↩ ↪ February 01, 2015 code dart go javascript language lua I don’t know about you, but nothing gets me going in the morning quite like a good old fashioned programming language rant. It stirs the blood to see someone skewer one of those “blub” languages the plebians use, muddling through their day with it between furtive visits to StackOverflow. (Meanwhile, you and I, only use the most enlightened
Go の Test に対する考え方 - Qiita
この記事は Go Advent Calendar 2013 の 9 日目の投稿です。 今回は、 Go の testing というパッケージの使い方を解説しようと思ったのですが、 それだとつまらなすぎるので、合わせて Go が test というか assert についてどういうスタンスをとっているかを書いてみます。 Go でテスト さて、「テストのないコードはレガシーコード」などと言われて久しく、様々な言語が test (主に Unittest) について言語レベルでサポートしたり、デファクトなライブラリが確立したりといった状況が、今日では至って普通のこととなっています。 そんな言語や環境で、息をするようにテストを書いてきたみなさんが、はじめて Go でコードを書く時に見るべきは testing パッケージです。 http://golang.org/pkg/testing/ 命名規則 では、
Illustrated Guide to SQLX
Illustrated guide to SQLX sqlx is a package for Go which provides a set of extensions on top of the excellent built-in database/sql package. Examining Go idioms is the focus of this document, so there is no presumption being made that any SQL herein is actually a recommended way to use a database. It will not cover setting up a Go development environment, basic Go information about syntax or seman
Synchro - タイムゾーン型安全な Go ライブラリを開発している
synchro と呼ばれる Go でもタイムゾーンを含めて型比較できるようになるライブラリを開発し始めました。スターください。 こんな感じで使えます。 package main import ( "fmt" "time" "github.com/Code-Hex/synchro" "github.com/Code-Hex/synchro/tz" ) func main() { utcNow := synchro.Now[tz.UTC]() jstNow := synchro.Now[tz.AsiaTokyo]() fmt.Println(utcNow) fmt.Println(jstNow) // Output: // 2023-09-02 14:00:00 +0000 UTC // 2023-09-02 23:00:00 +0900 JST fmt.Println("------") d
mockgenのコード生成を1回にまとめて高速化するツールbulkmockgenを作った - 私が歌川です
tl;dr 表題のようなツールを作りました。go install コマンドでただちにインストールできます。 $ go install github.com/utgwkk/bulkmockgen/cmd/bulkmockgen@latest 従来の //go:generate コメントから移行するツールもあります。 $ go install github.com/utgwkk/bulkmockgen/cmd/mockgen-to-bulkmockgen@latest tl;dr 課題感 モックを使った開発と問題 mockgenのコード生成に時間がかかる //go:generate コマンドを1行で書くと人間に優しくない bulkmockgen mockgenから移行する ベンチマーク before (1つずつ生成する) after (まとめて生成する) bulkmockgenの制約 他の方針
docker build 時に private リポジトリから go get する - Diary of a Perpetual Student
要件 Go 言語で作られた、GitHub の private repository の go module に依存しているアプリケーションについて考えましょう。例えばオープンソースではない社内ライブラリに依存している、という状態です。 手元の開発マシン上では GOPRIVATE 環境変数を利用して、go mod download できている状態です。このアプリケーションはコンテナ上で動かすことを想定しており、Dockerfile 内で RUN go build することでバイナリを生成し container image に格納しようとしています。 しかし、public な module だけに依存しているときと同じように Dockerfile を書いても docker build に失敗してしまいます。go mod download 時に private repository から fet
Goのビルドタグの書き方が// +buildから//go:buildに変わった理由
ざっくり言うと // +buildは、一般的な&&や||を使う論理式の書き方じゃないので分かりにくかった 複数行書くこともできたので暗黙的な論理演算になり、意図しないビルド条件になることがあった だから、より身近で明確な書き方ができる//go:buildへ置き換えることになった（記述位置の条件とかも見直してる） Go1.17でビルドタグの書き方が変わることがアナウンスされた 2021年8月のGo1.17から//go:buildが使えるようになりました。 後でも触れるのですが、もちろん後方互換性が維持されているので// +buildも使えます。 // +buildだけが指定されているファイルに対してgo fmtを実行すると、同等の//go:buildがすぐ上の行に追加されるようになっています。 // +buildはいくつかの問題を抱えていた もともと// +buildに指定できるのはOS名か
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
txtar package - golang.org/x/tools/txtar - Go Packages
go の json 変換の挙動まとめ - Qiita
