Goの標準のutf8.RuneStart関数がエレガントすぎる
先日以下の記事を書きました。 ここでUTF-8の最初の文字かどうかの判定を以下の自作した関数で実装していました。 const ( t1 = 0b00000000 tx = 0b10000000 t2 = 0b00000110 t3 = 0b00001110 t4 = 0b00011110 ) func isUTF8LeadByte(tmp byte) bool { if tmp&tx == t1 { return true } tmp >>= 3 if tmp == t4 { return true } tmp >>= 1 if tmp == t3 { return true } tmp >>= 1 if tmp == t2 { return true } return false }
リトライ処理を追加するとバッチが安定することがあることもそこそこあるので「avast/retry-go」を使ってみる - じゃあ、おうちで学べる
はじめに インフラエンジニアは日々の業務でプログラムを書く機会が多く、その中で処理の実行やHTTPの通信などでリトライ処理を実装する必要があることが少なくありません。リトライ処理を実装する必要は必ずしもなくても、実装することでバッチが安定することがあります。もっと言っておくとリトライ処理を実装することで、一時的なエラーによる処理の失敗を回避し、バッチ処理の安定性が向上する可能性があります。実行基盤によってジョブの再試行の自動化、最大再試行回数を設定するやPod失敗のバックオフポリシーなどとの兼ね合いを考える必要もあると思います。あとはマジでガー不のバグを引き寄せることもあるので注意が必要です。 はじめに シンプルな例 最大リトライ回数の指定 次のリトライまでの待ち時間の設定 特定の例外のみリトライするケース さいごに 今回はGolangには「retry-go」というリトライ処理を簡潔に実装
Secure Randomness in Go 1.22 - The Go Programming Language
The Go Blog Secure Randomness in Go 1.22 Russ Cox and Filippo Valsorda 2 May 2024 Computers aren’t random. On the contrary, hardware designers work very hard to make sure computers run every program the same way every time. So when a program does need random numbers, that requires extra effort. Traditionally, computer scientists and programming languages have distinguished between two different ki
PerlからGoへのシステム移行のアシスト 〜Perl XSとUnix Domain Socketを活用〜 - Mirrativ Tech Blog
こんにちは ハタ です。 Mirrativ では 2020年頃から サーバサイドの技術をPerlからGoへのシステム移行 を行っており、2024年現在でもサグラダファミリアのように移行作業は継続しています PerlとGoという2つの環境を同時に運用していますが、 基本的には 新機能は Go で実装 し、 Perlでは積極的に新規実装を行わない というスタイルで進めていました しかし、既存の機能の一部に手を加えたいとなった場合、まだまだ Perl の実装に手を加えることが一定あり、Perl から Go の機能を呼び出したいというニーズが出てきました （配信やギフトといったビジネスの根幹を支えるレガシーな実装においては顕著） そこで PerlXS を利用することで Perl から Go を直接呼び出せるようにできないかと考え検証を進めることにしました Goの -buildmode=c-shar
ぼくのかんがえたさいきょうのGo HTTPサーバー起動方法
これまで何度か HTTP Server の Graceful Shutdown について記事を書きました。 Go 言語で Graceful Restart をする Go 言語で Graceful Restart をするときに取りこぼしを少なくする Go1.8 の Graceful Shutdown と go-gracedown の対応 最終的に Go 1.8 で Server.Shutdown が導入され、この件は解決を見ました。 しかし、最近「あれ？本当に正しく Server.Shutdown 使えている？」と疑問に思い、少し考えてみました。 というか ↑ の記事もまだ考慮が足りない気がする。 ぼくのかんがえたさいきょうの Go HTTP サーバー起動方法 とりあえず完成形のコード。 package main import ( "context" "log" "net/http" "os
Go’s Error Handling Is Perfect, Actually
2024-02-12 [Updated: 2024-02-12] :: verygoodsoftwarenotvirus :: 7 min read (1476 words) Spend any amount of time in programming circles, and just as the sun rises and falls, you are certain to hear someone complain about error handling in Go. These complaints are, anecdotally, rarely well thought out suggestions on what error handling could or should be like in a language like Go, but often merely
bpftraceによるGoアプリケーションのトレース｜hayajo
はじめにシステムの状態を的確に捉え、運用に必要なインサイトを継続的に得るための特性は「オブザーバビリティ」と呼ばれます。オブザーバビリティを実現することで、パフォーマンスのモニタリングやトラブルシューティングを効果的に行い、システムの信頼性を高めることができます。 この重要な特性を実現する上で、eBPFやbpftraceは強力なツールとなります。 本記事では、Goアプリケーションにおけるオブザーバビリティを実現するための一つの方法として、bpftraceを用いたトレースの手法を紹介します。 内容が多いため、目次を活用して段階的に読み進めることをお勧めします。 eBPFとbpftraceはじめに、eBPFとbpftraceについて簡単に説明します。 eBPFとはeBPF(Extended Berkeley Packet Filter)はLinuxカーネル内で動作する柔軟なプログラミングフレー
One Billion Row Challenge in Golang - From 95s to 1.96s
One Billion Row Challenge in Golang - From 95s to 1.96s Renato Pereira Mar 18, 2024 Introduction The One Billion Row Challenge (1BRC) is quite simple: the task is developing a program capable of read a file with 1 billion lines, aggregating the information contained in each line, and print a report with the result. Each line within the file contains a weather station name and a temperature reading
More powerful Go execution traces - The Go Programming Language
The Go Blog More powerful Go execution traces Michael Knyszek 14 March 2024 The runtime/trace package contains a powerful tool for understanding and troubleshooting Go programs. The functionality within allows one to produce a trace of each goroutine’s execution over some time period. With the go tool trace command (or the excellent open source gotraceui tool), one may then visualize and explore t
The One Billion Row Challenge in Go: from 1m45s to 3.4s in nine solutions
The One Billion Row Challenge in Go: from 1m45s to 3.4s in nine solutions March 2024 Go to: Baseline | Solutions | Table of results | Final comments I saw the One Billion Row Challenge a couple of weeks ago, and it thoroughly nerd-sniped me, so I went to Go solve it. I’m late to the party, as the original competition was in January. It was also in Java. I’m not particularly interested in Java, but
Go1.22のリリースで本業で即利用できそうなものをまとめてみた
本業でGoを使っており、備忘録として、Go1.22で導入された新しい機能のうちすぐに利用できそうなものをまとめた。 TL;DR database/sql の Null[T] は独自で型定義しているとき、 Scan などの実装をスキップできる slices の Concat 1. database/sql の Null[T] 独自の型を定義をしている場合以下のように読み取り( Scan )と書き込み( Value )用の実装することがある type Email string func (e *Email) Validate() error { r, err := regexp.Compile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`) if err != nil { return err } if !r.MatchString(st
ARMアーキテクチャがメモリアクセスを省略することで意図したベンチマークになっていなかった話
概要 あるサンプルコードのベンチマークを測定したところ、期待していたよりも18倍速い結果が出力されました。バイナリを調査してみると、メモリ読み出しの命令が1つ増えるだけでこの性能差が生じていました。さらに調査を進めると、ARMアーキテクチャは連続したメモリへの書き込みを1つにマージし、実行を省略する可能性があることがわかりました。そのため、一般的なベンチマークのように複数回の測定結果を平均化するやり方では、正しい速度を測定できていませんでした。 「パフォーマンスを解釈するのにアーキテクチャの理解が不可欠だった事例」として面白かったのでこの記事を書いてみました。Go言語で説明しますが、言語に依存しない話だと思います。 得られた教訓 バイナリを見ても説明できない性能差は、アーキテクチャの理解によって説明できることがある マイクロベンチマークは、何を計測しているのかを理解した上で実施する必要があ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Don’t return err in Go — akavel's digital garden
Implementing MVCC and major SQL transaction isolation levels | notes.eatonphil.com
GitHub - MHNightCat/superfile: Pretty fancy and modern terminal file manager
Constraining Go type parameter pointers
Go Generics: Use Structs for Generic Arguments Lists
High-Speed Packet Transmission in Go: From net.Dial to AF_XDP
One Billion Rows Challenge in Golang
1.5+ million PDFs in 25 minutes - Zerodha Tech Blog