Goのerrorがスタックトレースを含まない理由 - methaneのブログ
Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
WebアプリケーションにGoの並行処理アーキテクチャを導入してSLOを改善し、WebAPIを100倍速くした話 - スタディサプリ Product Team Blog
こんにちは。スタディサプリの小中高プロダクト基盤開発グループでProduct Platform Engineer兼テックリードをやっている@tooooooooomyです。 今回は、WebアプリケーションにGoの並行処理機構を導入してSLOを改善し、WebAPIを100倍速くした話をしたいと思います。 前提条件 システムを0から作らない場合、アーキテクチャの改善の際には前提条件が付きものです。そこでまずは今回のシステムの前提条件をお話します。 対象となるシステムと、アーキテクチャ 今回対象とするシステムは、ここでは security-tracker と呼び、Webアプリケーション本体はGoで書かれています。 スタディサプリの各アプリケーションにおけるユーザーのログ1を、Amazon Kinesis Firehoseを通して、リクルート全体のセキュリティチームが管理するS3バケット(スタディサ
Goとエラーハンドリング慣習について
エラー返値が無用な条件 関数ないしメソッドの実装がオンメモリ操作のみで完結 将来も（メモリ以外の）I/O操作は追加されることがない 逆にいうと上記の条件のいずれかが達成できない可能性がある関数やメソッドはエラー返値を付与すべき。 返値エラー型はerrorで統一する 返すエラーがerrorインターフェース型でなければそのエラーは正常にハンドリングできません。またerrorインターフェースを満たす別の返値型で返してerrorインターフェース型で受け取るのも後述のトラブルの元です。 Goの実装方針に「インターフェースで利用するものもコンストラクター相当では構造体ポインタで返す」というものがありますがコンストラクタを呼ぶ側は元型にアクセスすることが多いのでこういう方針になっています。が、エラー値に関しては元型を意識せずに利用可能にするという役割があって、この実装方針は当てはまりません。 エラーチェ
Big Sky :: Go の struct は小さくできる(fieldalignment のススメ)
動的型付けプログラミング言語や、class を持つようなプログラミング言語を使う場合、そのフィールドメンバの定義順などを意識する事は少ないかもしれません。 Go は struct という、C言語が持っている構造体と同じ様にメモリ配置され、構造体そのものをレシーバとして、メソッドを定義しつつプログラミングを行います。struct はデータ構造そのものを示し、それが大きくなるにつれ、当然ながらメモリ使用量も多くなります。 さて、例えば以下のコードを実行すると、struct 100 個分のサイズは幾らになるでしょうか。 package main import ( "fmt" "unsafe" ) type Account struct { TimeZone struct { Name string `json:"name"` UtcOffset int `json:"utc_
Goのなぜ問答
はじめに Goはできるだけ冗長な機能セットを増やさずに応用の効くシンプルで強力な機能セットに絞り込んだ設計であることを目指した言語処理系です。なのでリッチな機能を持つ言語処理系経験者からするとたくさんの「なぜ？」を感じると思います。 しかし、Goの開発者たちは他の言語処理系にある機能だからGoにも採用しようとは一切考えません。あくまで大きなゲイン（デメリットをメリットが大きく上回る）を示されるまでは採用しません。特に言語仕様についてはより変更を嫌う傾向があります。「Go1の約束」というものがあり、Go1.0向けに書かれたコードはGo1.xでも動くもしくは機械的にコードにパッチを当てることで移行可能にするということをずっと守っています（約９年？）。 最近になりGo2プロポーザルがたくさん書かれ、それらの提案のうち言語仕様に関するものは最終的に２〜３個に絞り込まれ順次採用されていくという計画で
Big Sky :: gocode やめます(そして Language Server へ)
はじめに まず始めに言っておかなければなりません。 gocode 今まで本当にありがとう この記事は、Go 言語歴10年になる僕がこれまで愛用してきた Go 言語のコード補完ソフトウェア gocode の歴史と功績、そして今、gocode 自らがその役割を終えようとしている姿をぜひ皆さんに知って頂きたいという思いから Go Advent Calendar 2018 の記事として起こしました。この記事では gocode が歩んできた歴史と苦悩を少しでも皆さんに分かる様に解説させて頂きつつ、そして次にやってくる Go 言語のコード補完の未来についてご紹介したいと思います。Vim について多めに書かれていますが、Visual Studio Code での Go 開発にも影響する話です。 gocode とは gocode は nsf 氏が開発した Go 言語のコード補完サーバです。 GitHub
Go言語の型とreflect
最近型ではまることがたびたびあったのでまとめてみました。 主に下記についてまとめています。 型とインターフェース 代入のルール 型の変換 型アサーション reflectパッケージの使い方 インターフェースの実装などについては触れていません。 型とインターフェース 名前を持つ型と名前を持たない型 型には名前のある型(named types)とない型(unnamed types)がある。 代入の可否など名前の有無で動作に違いのあるケースがある。 ざっくりいえば、英数字で表されているものが名前のある型、括弧やアスタリスクなどの記号を使って表されている型が名前のない型 名前のある型 下記のようにtypeを使って宣言されている型は名前のある型。
Goで学ぶポインタとアドレス - Qiita
Goってシンプルで書きやすいですよね。 しかし、シンプルなGoでもいくつか躓きやすいポイントがあると思っています。 その最初のポイントがポインタではないでしょうか。特に、ポインタの概念が存在しない言語から始めた人にとっては、なかなかとっつきにくいものだと思います。そこで今回は、なんとなく使っていたポインタを、ちゃんと理解するためのエントリを書きました。ポインタをちゃんと理解しようとすると、その前提として知らなければならないことが多々あり、そこから説明するので、やや遠回りをした説明になっています。 「これちげえじゃねえか」とか、「ここわかりにくいぜ」っていうのがあったら、ご教授ください。 ※ 技術的な話は「です、ます」調よりも「である、だ」調の方が書きやすいので、以降は「である、だ」調で書きます。 前提知識Part 先ほど述べたとおり、ポインタを理解しようとすると、前提知識が必要になってくる
GoでEnumを定義する 〜intやstringよりも厳密に〜 - Qiita
package enum type SimpleSeason int const ( _ SimpleSeason = iota Spring Summer Autumn Winter ) var simpleSeasonStrings = [4]string{"未定義", "春", "夏", "秋", "冬"} func (s SimpleSeason) String() string { return simpleSeasonStrings[s] } package main import ( "fmt" "github.com/ikngtty/playground/enum" ) func main() { fmt.Println(enum.Summer) // -> 夏 }
【Golang】jsonのomitemptyタグについて - Qiita
player1 := Player{ Name: "Alice", } hogehoge, err := json.Marshal(player1) // このようにして生成されるJSONは以下の通り // { // "name": "Alice", // "weight": 0 // } omitemptyタグをつけていないweightフィールドには初期値（？）の0が勝手に入っている タグをつけたageフィールドは無視されている しかし、公式Docによると、このようにomitemptyタグをつけることで無視できるフィールドの型は決まっている The "omitempty" option specifies that the field should be omitted from the encoding if the field has an empty value, defined
Go言語Internal パート2：名前付き戻り値の魅力的な利点 | POSTD
ご承知のことと思いますが、Go言語では戻り値に名前を付ける機能を提供しています。これまで minio ではこの機能をそれほど使っていませんが、この先変わって行くでしょう。というのも、本記事で以下に説明するような魅力的な利点が含まれているからです。 私たちのような開発者であれば、下記に示すように “デフォルト”値を返すために return 文ごとに新しいオブジェクトのインスタンスを生成するという形で大量のコードを使うことがあるでしょう。 type objectInfo struct { arg1 int64 arg2 uint64 arg3 string arg4 []int } func NoNamedReturnParams(i int) (objectInfo) { if i == 1 { // Do one thing return objectInfo{} } if i == 2
Go言語のコードレビュー
SoundCloudが2年半ほどGo言語を利用したプロダクトを本番で運用した知見をGopherConで発表していた（“Go: Best Practices for Production Environments”）．その中で“CodeReviewCommentsというGoogleでのGo言語のコードレビューにおいてよくあるコメントをまとめたサイトが紹介されていた． 最近Go言語を書くようになり，使えそうなのでざっと抄訳してみた．“リーダブルコード”的な視点も含まれており，Go以外の言語でも使えそう． gofmtでコードの整形をすること コメントは文章で書くこと．godocがいい感じに抜き出してくれる．対象となる関数（変数）名で初めて，ピリオドで終わること // A Request represents a request to run a command. type Request str
golang の 引数、戻り値、レシーバをポインタにすべきか、値にすべきかの判断基準について迷っている - pospomeのプログラミング日記
日頃から 引数にポインタを渡した方がいいのか? 値を渡した方がいいのか? 戻り値はどーなの? メソッドのレシーバは? なんて迷っているのでアウトプットしてみる。 メソッドのレシーバについては以下に載っていた。 https://github.com/golang/go/wiki/CodeReviewComments#receiver-type 以下は日本語訳。 http://qiita.com/knsh14/items/8b73b31822c109d4c497#receiver-type レシーバについては、これが基準な気がするのでこれに従おうと思う。 ということで解決。 そして、このドキュメントにはレシーバというよりも、 ポインタと値の特徴が載っているので、 それらの特徴を「引数」「戻り値」でも考えていけば、それっぽい答えになりそう。 ということで、「引数」「戻り値」を対象にザックリとまと
Go で struct をそのまま公開するのはあんまり良くないんじゃないか - Humanity
と思った。理由は以下の通り。 ずっと地味に困ってた事があって、ある struct をコンストラクタ的な関数 (例えば Foo って struct だったら NewFoo って名前の関数) 経由で生成したい、と思っても、 Go の言語仕様上普通にこんな感じで struct を作れてしまう。 package main import "fmt" type Editor struct { name string } // ほんとはこっちを使ってほしい func NewEditor(name string) *editor { return &editor{name: name} } func (e *Editor) Hello() string { return "こんにちは、" + e.name + "です" } func main() { // NewEditor() 使わずに普通に作れてしま
Goでゼロ値の構造体を生成することを防ぐべきかという話 - pospomeのプログラミング日記
社内slackで以下の記事と同じようなことを悩んでいるというメッセージがあった。 2018年の記事ではあるが、自分もGoを利用し始めた頃に考えたことがあるので、この記事に書かれている内容をベースに改めて自分の意見をまとめておく。 ここに書く内容が正しいかどうかは自己判断して欲しい。 tyru.hatenablog.com なぜ golint でエラーになるのか? 元の記事の "Interface を定義することを考える" という解決策について 現実的に起こりうるリスクを考える まとめ 宣伝 なぜ golint でエラーになるのか? 上記の記事には "golint でエラーが出る" という内容があった。 なので "そもそもなぜ golint でエラーが出るのか?" を考える必要がある。 エラーになる理由は以下である。 github.com パッと読んだ感じ以下の2つになると思う。 1. クラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Not Found
【Go】print系関数の違い - Qiita
goのenumは文字列でいいのではないかという話 - Qiita
InterfaceSlice
Goを学びたての人が誤解しがちなtypeと構造体について #golang - Qiita
