ちょっとJavaのsynchronizedをGoに移植しようとしたはずが、なぜか１万文字の作文ができた - エムスリーテックブログ
AI・機械学習チームのブログリレーも9日目になりました。同チームの横本@yokomotodです。 本日はJavaとGoを題材に並行プログラミングまわりの自由研究をしたお話をしてみたいと思います。 3部構成で、パート1では発端となった「排他制御」について、パート2では「メモリの可視化」について、それぞれJavaとGoを比べてみました。 最後にパート3では、それらの動作を規定する「メモリモデル」について、わかりやすく解説されているリソースを紹介します。 長過ぎる！ 3行で！！ パート1: synchronized = 「排他制御」？ Java synchronized vs Go sync.Mutex Goで再入可能なロック？ 仮にGoで再入可能なロックを実装するなら？ Javaが再入可能を選択した理由 パート2. sycnhronized = 「排他制御」＋「メモリ可視性の保証」 Javaの
Go でマルチスレッドプログラミングする際に最低限知っておくべきこと - Cybozu Inside Out | サイボウズエンジニアのブログ
この記事は、CYBOZU SUMMER BLOG FES '24 (クラウド基盤 Stage) DAY 10 の記事です。 こんにちは。クラウド基盤本部の野島です。Go は goroutine やチャネルなどの仕組みが備わっており、簡単にマルチスレッドなプログラムを書くことができる言語だと言われています。しかし、マルチスレッドプログラミングには独特の罠があり、何も知らない人が雰囲気でコードを書くとわかりにくいバグを仕込んでしまうリスクが非常に高いです。 この記事では、マルチスレッドプログラミングに詳しくない人に向けて、そのような罠を避けるための方法を紹介します。この記事は Go の基本的な使い方を知っていることを前提としています。 這い寄るデータ競合の恐怖 まずは以下のようなプログラムを考えてみましょう。これは複雑な計算を行って結果を返すような HTTP サーバーのコードです。 // 複雑
Go言語ビギナーのCREが、Mackerelの途切れ監視プラグインを開発して正式リリースした話 - Hatena Developer Blog
こんにちは、Mackerel CREの id:kmuto です。 9月25日に、Mackerelのエージェント用チェックプラグイン「check-mackerel-metric」をリリースしました。 github.com このプラグインは、クラウドインテグレーションを利用した場合など一部標準の機能ではできない、ホストメトリックの途切れ監視を実現するものです。たとえばcheck-mackerel-metric -H <hostId> -n "custom.ecs.running_task.batch-cluster.count -w 30 -c 60という指定をしておくと、ホストID <hostId>のメトリックcustom.ecs.running_task.batch-cluster.countについて、現在から30分前までの間に何も投稿されていなければWARNING、60分前までの間に何も
強い思想: Go を Web 開発に採用する上で
Go は Web 開発に向いているか？ 最も向いている領域は「CLI ツール」「ミドルウェア」「マイクロサービス」だと思っている。なぜならそれらはコードベースを比較的小さく抑えることを前提としているからだ。 Go は大きなコードベースを抱えやすい設計の言語になっていない。 ミドルウェアとマイクロサービスに関しては小さく作ることが正義。 CLI ツールに関しては単一責務なツールであれば小さくなるが，複数を束ねるツールであっても Web サービス開発に比べれば考えることは少なくて済む。 Web 業界における「一般的な Web 開発」，すなわちモノリスを基本とした中規模以上の開発にははっきりと 向いていない と言うべきだろう。 フラットパッケージは正義か？ 私が SNS で何度か言及した以下の記事がある。 フラットパッケージ戦略は，確かに Go の文化圏においては一定の支持を集めている。Go の
なぜ Go ではロガーをコンストラクタ DI してはならないのか
問題のある実装パターン 共通実装 以下のような applog パッケージ上のロガー実装を考えましょう。ここでは Go 標準の log.Logger をラップしていますが，様々な実装に拡張できることを想定しています。 package applog import ( "fmt" "log" "os" ) type Logger interface { Info(message string) Error(message string) } func NewLogger() Logger { return &logger{ inner: log.New(os.Stdout, "", log.LstdFlags), } } var _ Logger = (*logger)(nil) type logger struct { inner *log.Logger } func (l *logger)
有効期限を過ぎても消えないインメモリキャッシュの謎 - 私が歌川です
tl;dr キーワードは「monotonic clock」です。 あらすじ Goで以下のようなコードを書いていた*1*2。あるAPIを叩くクライアントで、APIコールに必要なアクセストークンを4時間キャッシュしている。c.getToken() で得られたトークンを使ってAPIコールを行えばよい。 type Client struct { mu sync.RWMutex expiresAt time.Time token string } // トークンのキャッシュがあればキャッシュから返し、なければ更新してから返す func (c *Client) getToken() string { if cachedToken, ok := c.getTokenFromCache(); ok { return cachedToken } return c.refreshToken() } // トー
Go言語の不満 - まめめも
ちょっとバイナリ配布したいツール↓があったので、Go言語と戯れました。 zenn.dev ほぼはじめてGoを使ったので、にわかほど語りたがる法則に従って、Go言語の感想を書きます。 新しい言語にふれたときは、できることには気づきにくく、できないことに気づきやすいので、不満が多めです。主な比較対象はRuby、C言語、JS/TS、Rustあたりです。 よかったところ ひとことで言えば「便利になったC言語」という感じでした。結構低レベルなAPIも揃っていてよかった（デーモン化が素直にできなかったこと以外）。 Rustと比べたらストレスフリーです。思った通りに書くだけでとりあえず動いてくれる。すばらしい。 見た目はあきらかに長くてダサいですが、こだわりを捨てて割り切って書けると言えなくもない。 配布しやすいシングルバイナリが作れるのはやはりよい。今回Goを選んだ理由がこれ。 細かいカプセル化がむず
Goでつまづいたところを仕様を見ながら理解してみる - ravineport blog
Go言語デビューしました！🎉 シンプルなのもあってすぐに馴染むことができています。Goよいですね！ さてさて今回はGoを書いていて「これできるんだ」「これはコンパイルエラーなんだ」となったところをGoの仕様などを見ながら（できればそのwhyまで）理解したいと思います。 Go 1.18時点での記事です。 つまづき1：constをポインタとして扱えない 例えばこんなのがあったとして const Ten = 10 type User struct { age *int } 以下のコンパイルが通りません。 func main() { user := User{ &Ten, // コンパイル通らない🤔 } fmt.Println(user) } エラーメッセージを見てみると invalid operation: cannot take address of Ten (constant 10 of
Goにおける型によってSQLインジェクションを防ぐ方法
はじめに 2022年のセキュリティ・キャンプ全国大会に講師として参加しました。その際に、Goにおける脆弱性への対策はどうなっているのか調べました。この記事では、github.com/google/go-safeweb/safesqlがどのようにSQLインジェクションを防いでるのかについて解説します。 なお、@rungさんの文書を多いに参考にしております。また、セキュリティ・キャンプで用いた資料はこちらから閲覧できます。 SQLインジェクションとは？ 独立行政法人情報処理推進機構（IPA）が公開している安全なウェブサイトの作り方を見ると、SQLインジェクションは以下のように説明されています。 データベースと連携したウェブアプリケーションの多くは、利用者からの入力情報を基にSQL文（データベースへの命令文）を組み立てています。ここで、SQL文の組み立て方法に問題がある場合、攻撃によってデータベ
MySQLで発生し得る思わぬデッドロックと対応方法
はじめに この記事は実際の業務で発生した MySQL のデッドロックとそのいくつかの回避方法や対応方法を（テーマは変えて）手元で実行できるコードを用いて解説する記事です。具体的には「トランザクション張っておけば大丈夫」と思ってませんか？ バグの温床になる、よくある実装パターンの記事で紹介されている「1on1 チャットサービス」で紹介されているデッドロックとデータベースレイヤでは同じ状況だったのですが、記事で紹介されている方法とは別の方法でデッドロックを回避する必要があったため、同じ状況に遭遇した人の助けになればという思いで記事を書きました。また、こちらの記事が無ければ私自身も現象を理解するのにもっと苦労したと思うので、この場を借りてお礼申し上げます！ 出金サービス履歴登録サービスを例に考える コードと説明が https://github.com/shuntagami/withdrawal_
Goプログラム実行時間の短縮 - ZOZO TECH BLOG
こんにちは。生産プラットフォーム開発部の中嶋です。生産プラットフォーム開発部はアパレル生産のDXを進めている部門です。具体的には服作りのIT化を含めたアパレル生産の効率化の促進と「生産支援」のシステムを主にGoで開発しています。今回はその運用の中でGoプログラムの実行時間をどのように短縮したのかを紹介します。 目次 目次 学べること・解決できること 背景 エラー発生 調査・対応 インスタンスの変更 原因 実装アプローチの見直し ゴルーチンを使ったタイムアウト処理 サンプルコード チャネルのクローズについて Goのメモリマネジメントについて スタックとヒープ ゴルーチンとメモリについて ヒープについて 問題の仮説 どのように解決したか 実装イメージ 利用したパッケージ サンプルコード 結果 まとめ 最後に 参考リンク 学べること・解決できること Goのメモリエラーに対するアプローチ例 Go視
Goならわかるシステムプログラミング第2版が出たので書評しますね - moriyoshiの日記
少し前になりますが、3月23日に、渋川よしきさんの著された「Goならわかるシステムプログラミング 第2版 」が発売されました。初版と比べてかなり加筆されておりパワーアップしているので、初版をすでにお持ちの方でもさらに興味深く読むことのできる内容に仕上がっている、というのが第一印象です。 残念ながら初版発売時に記事にする機会がなかったのですが、あらためて今回書評したいなと思いましたので、徒然書いていきたいと思います。 この本は実はシステムプログラミングの本ではないかもしれない 「システムプログラミング」とは何でしょう。正直私にもわかりません。その語をはじめに思い浮かべた人は、プログラミングという概念のその中にあえて「システムプログラミング」という分類を作ろうと思い至ったということですから、きっと「非システムプログラミング」というものもあるということでしょう。知らんけど。しかし、これは本書の位
Goで社内ツールを作るならこんなふうに
バックグラウンド 最近企業でにわかにGoの採用が増えているようですね。この流れを受けて実際にうちでも採用してみようと考えている方も多いかもしれません。しかし、Goに限った話ではないのですが、いきなり大きなプロジェクトに未経験の技術を投入するのはリスクが伴います。ですから最初は技術検証とGoの教育を兼ねて、小さな社内ツールなどから導入するのがよいでしょう。幸い、Goは非常に習得が容易な言語ですから、既に他言語の経験があるプログラマーがじゅうぶんに開発できるようになるまでには、数日と掛からないことがほとんどです。 この記事は、そんな小さなツールの導入フェーズにあたって、自らの経験から少し役に立つかもしれない情報をシェアします。 リポジトリの構成 自らの経験上、初めてGoを触れるときによく出る質問の一つは「リポジトリ構成はどうすればいいのか？」です。 結論から申し上げると、 テンプレもルールもな
Go言語が成功した理由
Go言語の作者であるRob Pike氏が「Go言語が成功した理由は何なのか？」というタイトルで2015年に発表をしてる動画を見つけたので、雑に和訳してみたいと思う ちなみに最近Go言語の好き嫌いに関する記事がいくつかバズっており、それに乗っかってるというのは言うまでもない Go言語を嫌う6個の理由 Go言語が好きな理由 良く挙げられる成功要因 Pike氏は以下がよく理由として挙げられると述べている コンパイルの速さ 実行の速さ デプロイの容易性 ツール ライブラリ しかしこれらは全て表面的であって、本質的な理由ではないとも述べている ではGo言語が成功に至った本質的な理由とは一体何なのか？彼は続いて説明している Go言語が成功に至った真の理由 彼は「Simplicity」、シンプルさがGo言語が成功に至った本質的な理由であると述べている そしてこのコンテキストにおける「シンプルさ」とは以下
Go言語が好きな理由
はじめに 私はGoが好きなので、disられている場面に遭遇すると心が痛みます。残念ながらプログラミング言語について深く語れるほどの知識や経験は持ち合わせていないため、世界が平和になることを祈るくらいしかできません。 （元ネタ）Go言語を嫌う6個の理由 - さめたコーヒー それはそれとして、Goが好きな理由を語る人はあまり見かけない気がします。この記事ではGoが好きな理由を視覚に障害のあるユーザーの視点から語ります。読み終えたところで得るものは何もありませんし、長いので覚悟して読んでください。 あなたは誰？ 4年ほど業務でサーバーサイドのGoを書いています。また、業務で使いはじめる前から趣味でGoに触れていました。そのため無意識の内にひいきしているかもしれません。ただし、流行っているからといって理由もなくGoを勧めたりはしません。 視覚障害ならではのコーディング事情 Goが好きな理由と深く関
GoのAPIが厳格でない訳
Windows対応の曖昧なAPIを非難する記事 この記事はGoが曖昧に扱うAPIについて非難していて、より厳格に扱うことのメリットを解説しています。 Goのこれらの指摘の挙動が実際にどの様なものかを解説していきます。 無視する挙動 Goの標準ライブラリのAPIはどちらかというとUnix/Posixに寄せていて、一部のWindowsに無い概念に関する処理（ファイルのパーミッション操作など）は黙って無視したりする。 これはUnix/Posix用の実装が同じソースコードのままWindowsでも動作するために必要なダミーです。ここでそのようなダミー実装をアプリケーション作成側の責任にすると実装やテストが大変面倒になってしまう。 逆に、GoではUnix/Posixにあるforkやthreadに関するAPIをサポートしません。特にforkというAPIはWindowsには全くない概念であり、互換性を取る
Goの苦手な領域
Goの利点を使って実装するコツやノウハウを書くことがコミュニティにとってプラスになると思っているのでそれに専念したいという考えはありますが、Goの苦手な領域にGoを採用してしまってヘイトを溜め込んでしまう事例を見かけたりします。 こういう悲劇の起こる可能性を少しでも減らせたらという思いで、Goの現状の苦手な領域について解説しようと思います。Goを学び始めにこれらの領域に手を出すのは避けましょう。 Cgo is not Go GoはCGO連携でC/C++資産を利用することができますが、メモリアロケータの異なる処理系を繋ぐ関係上、お互いに呼び合う際のパラメータや戻り値はほとんどのケースでコピーが必要になります（Cの型でメモリ確保しCの型のまま受け渡しする場合はOK）。なので高頻度に呼び合うような用途には不向きであるというのはSWIGなどのような複数の処理系を連携させる仕組みと同様です。 また、
Goへのヘイトに対する考え方
https://www.kbaba1001.com/entry/2021/09/17/073149 （該当記事が削除されました） RubyのサービスをGoで置き換えるのは３倍人手がかかる 何するにも機能不足 JSONの読み書きにわざわざ構造体書くの面倒 同僚がGoを選ぼうとしたら愚かな選択ですねと答える サーバーサイド開発にGoを使うのは危険 っぽい内容だったかと。 だいぶGoの特徴や既存の言語との考え方の違いが広まってきてるのかなぁと思っていた矢先だったので十年くらい前のような指摘をあえて今されていてびっくりした。 正直、ここに書かれたようなヘイト項目は既出すぎるので、もし影響の大きい項目を多くの人が同様に嫌っているならばGoはここまでの人気のある処理系になることはなかったと思う。（もしくは多くの人が嫌ってはいるが影響の小さい項目ということ） Goは出た当初、こういうヘイトが世界中のブロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
資料公開:「Golangを使ったバックエンドの実装入門」で DevelopersIO 2024に登壇しました #devio2024 | DevelopersIO
元JavaエンジニアがGoに感じた「表現力の低さ」と「開発生産性」の話 - DMM inside
