タグ

tipsとgolangに関するko-ya-maのブックマーク (53)

  • Goのなぜ問答

    はじめに Goはできるだけ冗長な機能セットを増やさずに応用の効くシンプルで強力な機能セットに絞り込んだ設計であることを目指した言語処理系です。なのでリッチな機能を持つ言語処理系経験者からするとたくさんの「なぜ?」を感じると思います。 しかし、Goの開発者たちは他の言語処理系にある機能だからGoにも採用しようとは一切考えません。あくまで大きなゲイン(デメリットをメリットが大きく上回る)を示されるまでは採用しません。特に言語仕様についてはより変更を嫌う傾向があります。「Go1の約束」というものがあり、Go1.0向けに書かれたコードはGo1.xでも動くもしくは機械的にコードにパッチを当てることで移行可能にするということをずっと守っています(約9年?)。 最近になりGo2プロポーザルがたくさん書かれ、それらの提案のうち言語仕様に関するものは最終的に2〜3個に絞り込まれ順次採用されていくという計画で

    Goのなぜ問答
  • Go 1.18 の Generics を使ったキャッシュライブラリを作った時に見つけた tips と微妙な点

    GitHub にコードを上げてます。 2021-11-17 時点で Go の Generics の機能を使ったキャッシュライブラリはおそらくないでしょう。Generics を使った例の一つとして参考にしてください。 Star をくれると大喜びします。 記事ではこのキャッシュライブラリを作ってみて Generics に対して気が付いた点と発見した tips や微妙だった点を紹介していきます。 もし Go の Generics って何ができるんだっけ?となっている方は是非こちらの記事にも目を通してみてください。 any でゼロ値を返す これは @syumai さんから教えてもらった tips です。 次のような any と error を返すコードをよく書くことになるでしょう。関数内で error が発生した時に今までゼロ値と error を返すコードを記述していたはずですが、ちょっと頭を捻

    Go 1.18 の Generics を使ったキャッシュライブラリを作った時に見つけた tips と微妙な点
  • Goの苦手な領域

    Goの利点を使って実装するコツやノウハウを書くことがコミュニティにとってプラスになると思っているのでそれに専念したいという考えはありますが、Goの苦手な領域にGoを採用してしまってヘイトを溜め込んでしまう事例を見かけたりします。 こういう悲劇の起こる可能性を少しでも減らせたらという思いで、Goの現状の苦手な領域について解説しようと思います。Goを学び始めにこれらの領域に手を出すのは避けましょう。 Cgo is not Go GoCGO連携でC/C++資産を利用することができますが、メモリアロケータの異なる処理系を繋ぐ関係上、お互いに呼び合う際のパラメータや戻り値はほとんどのケースでコピーが必要になります(Cの型でメモリ確保しCの型のまま受け渡しする場合はOK)。なので高頻度に呼び合うような用途には不向きであるというのはSWIGなどのような複数の処理系を連携させる仕組みと同様です。 また、

    Goの苦手な領域
  • GoはいつGCするのか?

    TL;DR Go(のランタイム)は以下のタイミングで自動的にGCを実行する 前回のGC後に占有していたメモリと同量を新たに確保したとき 前回のGCから2分後 cgroupなどでメモリ制限しているときは、メモリ使用量が制限の50%以上になったらruntime.GC()を呼び手動でGCすべきである 前置き: GoとOOMのこれまで 以下はGo 1.16での調査結果です。Goのバージョンが異なった場合は事情が異なる可能性があります。 Goでプログラムを書く際に、使用メモリ量を気にしなければならないシーンはGCのおかげでそう多くはありません。実際それは間違いではないのですが、運用まで視野に入れるとそうは言ってられないことがあるのもまた現実です。昨今はコンテナの利用が当たり前になったことに伴い、OOMによりプロセスが強制的に終了させられることもあり、それを避けるために一定量以下のメモリで動くことが重

    GoはいつGCするのか?
  • ガードレールを整備して、安心・安全な「Go」ライフを コードをセキュアに保つために解決すべき3つの課題

    Go Conferenceは半年に1回行われるプログラミング言語Goに関するカンファレンスです。米内氏は、Goを使用するときにセキュリティを高める仕組み作りについて発表しました。 日々コードを書く中で起こり得るインセキュアなコード 米内貴志氏:米内です。今日は「Goをセキュアに書き進めるための『ガードレール』を整備しよう」という題で、組織としてGoを使うときにセキュリティを底上げするための仕組み作りについて話をしようと思います。よろしくお願いします。 まず簡単に自己紹介をさせてください。私は米内貴志と申します。株式会社Flatt Securityセキュリティプロダクトの開発、今は特にeラーニング事業の開発をしています。社内でもけっこうGoを使っています。 もともとWebブラウザーとセキュリティが好きで、最近『Webブラウザセキュリティ』というをラムダノートさんから出版しました。気になる

    ガードレールを整備して、安心・安全な「Go」ライフを コードをセキュアに保つために解決すべき3つの課題
  • Goエラーハンドリング戦略

    Goのエラーハンドリングが採ったスタイル 多値返し 直積(関数の返値とエラーを両方返す) try-finallyをdeferという機構でカバー panicはプロセスを落とすためのもの Goはこの戦略でエラーハンドリングを行うとしましたので、「多値はなぜタプルじゃないんだ?」、「直和(返値orエラー)で十分じゃ?」「panic-recoverでtry-catchできそう?」などいう様な他の処理系の風習を持ち込むことは意味がありません。そしてそれらの提案の多くはすでに検討されリジェクトされてきた経緯があります。 「try組み込み関数」プロポーザルなんかも検討されマージ直前くらいまで進んだこともありますが、「Goのエラーハンドリング」にとって一長一短がありました。その欠点課題は解決できずに最終的にリジェクトされました。 「多値返し」は実にCPUフレンドリーな機構で、C言語の関数呼び出し規約にちょ

    Goエラーハンドリング戦略
  • セキュアにGoを書くための「ガードレール」を置こう - 安全なGoプロダクト開発に向けた持続可能なアプローチ - Flatt Security Blog

    The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license. 種々の linter が様々なプロダクトの品質を高めてきた、というのは疑う余地のない事実です。実装の初歩的な問題をエディタ内や CI/CD パイプライン中で機械的に検出できる環境を作れば、開発者はコーディングやコードレビューの邪魔になる些末な問題を早期に頭から追い出し、質的な問題に集中できます。 また、そのような環境づくり(e.g. linter のルールセットの定義、組織独自のルールの作成、…)は、まさに開発組織のベースラインを定義する作業として捉えることができます。一度誰かが定義

    セキュアにGoを書くための「ガードレール」を置こう - 安全なGoプロダクト開発に向けた持続可能なアプローチ - Flatt Security Blog
  • シングルバイナリにこだわる - AWS Lambda編 / Nature Bath vol.6

    Nature Bath vol.6【勉強会】みんなのGo言語 執筆陣による「Go開発・運用の現場」の発表資料です https://nature.connpass.com/event/194611/

    シングルバイナリにこだわる - AWS Lambda編 / Nature Bath vol.6
  • あなたのGoアプリ/ライブラリのパッケージ構成もっとシンプルでよくない? | フューチャー技術ブログ

    2023.10.5追記: Goチームからプロジェクトの目的に応じたディレクトリ構造についてのドキュメントが公式に公開されています。 https://go.dev/doc/modules/layout Goプロジェクトのフォルダ構成どうしよう、とググると見つかるStandard Go Project Layout。とはいえ、これはかなりコード量を増やしてしまう恐れがありますので、導入する場合のデメリットも考えておく方が良いです。 特に、プログラマーは、最初にみたプログラミング言語のフォルダ構成を親だと思う特性があり、Javaや.NETに影響されるとかなり細かくフォルダを切りたくなったり、package privateなど細かく可視性を制御しようとしたりして、なおかつ「privateのテストってどうすべきなんですか?」とか議論を始めたりもしますが、Go先生によればこれぐらいは1パッケージにフ

    あなたのGoアプリ/ライブラリのパッケージ構成もっとシンプルでよくない? | フューチャー技術ブログ
  • 【Golang】VSCodeで自動生成されるテストコードをカスタマイズする - magamingのブログ

    こんにちは。Goのテスト、書いていますか? 私はめちゃめちゃ書いています。 VSCode拡張機能(vscode-go)を入れることで、テストコードを自動生成することができることを最近知ったのですが、これがとても便利です。 使い方は以下の記事でまとめられています。 kdnakt.hatenablog.com これはめちゃめちゃ便利なのですが、デフォルトだと少し物足ないところがあったので、カスタムテンプレートを作成しました。 GitHub - Magaming/gotests-templates vscode-goは内部でgotestsを使っているので、それ用のテンプレートを用意している形です。 具体的には次のようなことをしています。 go-cmpを使う 標準だと reflect.DeepEqualで比較しているが、これだとtime.Time型を含んだ構造体の比較とかで死ぬ go-cmpは、

    【Golang】VSCodeで自動生成されるテストコードをカスタマイズする - magamingのブログ
  • Big Sky :: Go 言語の struct の実体を引数で(なるべく)渡せない様にするテクニック

    Go 言語は struct のレシーバがポインタの場合は実体であってもポインタの場合であっても呼び出せるので、もし struct が参照カウントに従い動作する様な場合は実体でコピーされてしまっては困る場合があります。例えば以下の様なインタフェースを考えます。 package main import ( "fmt" "sync/atomic" "time" ) type foo struct { n int64 q chan struct{} } func (f *foo) Add() { if atomic.AddInt64(&f.n, 1) == 1 { f.q = make(chan struct{}) } } func (f *foo) Done() { if atomic.AddInt64(&f.n, -1) == 0 { f.q <- struct{}{} } } func (f

    Big Sky :: Go 言語の struct の実体を引数で(なるべく)渡せない様にするテクニック
  • Go初心者が気を付けること

    Go初心者がやってしまいがちなやらない方がいいことを書き出してみました。 情報検索や環境構築 golang.jpを見に行ってしまう Golang(ごーらんぐ)と呼んでしまう(by hogedigo) depが最新推奨のパッケージマネージャだと勘違いする(Go標準の「go mod」を使おう) 「GO???」環境変数を理解せずに設定しまくる(わからない場合は一切設定しないのが正しい) しょっぱなからgvm,gobrew,goenvなどのマルチバージョンのマネージャを入れようとしてエディタ連携環境構築に失敗する (複数バージョンのGoの運用は既に標準のGoだけでできるようになっている) エディタにgoimportsやgolintを設定し忘れる OSのパッケージマネージャまかせで古いGoやgccgoをインストールしてしまう エラーハンドリング周り err変数名のバリエーションを増やしすぎる(ほとん

  • nilがnilじゃないのでerrorになるのを静的解析で検出する - Qiita

    Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

    nilがnilじゃないのでerrorになるのを静的解析で検出する - Qiita
  • Go の命名規則 | micnncim

    記事は Go Advent Calendar 2019 11 日目の記事です。 Go はシンプルな言語機能・シンタックスが特徴であり、命名規則にもそのシンプルさが表れています。 記事では、公式や著名な Go エンジニア、OSS などから見られる Go らしい命名規則を紹介します。 今更なテーマかもしれませんが、意外にも公私共々で命名規則が意識されていないコードを時折見かけるので、自戒も込めて記します。 誤った内容があれば Twitter でご指摘いただければと思います。 パッケージ名簡潔にするEffective Go では、short, concise, evocative なパッケージ名が望ましいとされます。 これはパッケージ名に限らずほとんどあらゆる命名において役立つ指針だと思います。 また、「パッケージ名は一言で何をするかを表すエレベーターピッチだ」という Dave Cheney

    Go の命名規則 | micnncim
  • Go1.13以後のエラーハンドリングについて語ろう / Let's talk about error handling after Go 1 13

    Go1.13以後のエラーハンドリングについて語ろう / Let's talk about error handling after Go 1 13

    Go1.13以後のエラーハンドリングについて語ろう / Let's talk about error handling after Go 1 13
  • golangのxoを導入して困った点、どう対応しているかを書いておく - nakamura244 blog

    はじめに 下記の記事でxoを導入してどうやって管理運用しているかについて書いたが、すべてうまくいっているわけではない。 すんなりハマらず、色々と困った点はあった。 このすんなりハマらなかった点やそれに対してどうやって対応しているか等を書いておく。他の人も参考になったら嬉しく思います。 tsuyoshi-nakamura.hatenablog.com 前提的な所 既存に関係なく、まったくの新規の開発ではなく、DB(mysql)は既存で運用されているtableを参照するという制約があった。 まぁこれが原因でうまくハマらない点が出てきたのだが、マイクロサービスへ移行する過渡期などは致し方ない所があると個人的には思います。 困った点 困った点1 : indexの貼り方がちょっと変な場合 歴史的な背景はおいておくとして下記のようなindexが貼られてた場合です +----------+-------

    golangのxoを導入して困った点、どう対応しているかを書いておく - nakamura244 blog
    ko-ya-ma
    ko-ya-ma 2019/09/30
    新規の開発ではない場合に立ち現れやすい課題と対処法について
  • なぜGo言語の正規表現は遅いと言われるの? - Qiita

    はじめに Goの正規表現は遅いと言われていることが以前から疑問だったので調査してみました。 こちらの記事やこちらの記事を拝見する限り ① 現実的なユースケース(例えばURLのパースなど)ではGo言語の正規表現は使うべきではなく、stringsパッケージの標準の関数を利用した方がパフォーマンスとしては良い。 ② Go言語で正規表現を利用するために必要な"正規表現オブジェクト"を並行にアクセスするにはパフォーマンスが問題になるので注意が必要。 とあります。その理由は、それぞれ以下に集約できるようです。 ① Go言語標準の正規表現ライブラリは、正規表現と検査文字列の長さに対して常に$O(n^2)$のオーダーで計算量が増加する安定したアルゴリズムを採用している。 ② "正規表現オブジェクト"を用いたマッチング処理には排他制御が行われている。 調べてみる Go言語のpkg/regexpの公式ドキュメ

    なぜGo言語の正規表現は遅いと言われるの? - Qiita
  • Go 1.13 に向けて知っておきたい Go Modules とそれを取り巻くエコシステム - blog.syfm

    はじめに 今年の 8 月にリリースが予定されている Go 1.13 では、Go 1.11 で導入された Go modules に加え、Go module proxy といった新しいエコシステムが登場します。 そこで、そもそも Go modules は何を行っているのかや、何ができるのか、どういった要素で構成されているのかを紹介します。 また、古い Go バージョンから Go 1.13 へアップデートする場合や、 dep や Glide といったベンダリングツールから Go modules へ移行する際の懸念点も併せて紹介します。 先日発表した "Go Modules and Proxy Walkthrough" はこのポストがベースになっています。 TL;DR な人はスライドを見るのがおすすめです。 speakerdeck.com Go Modules Go modules という仕組みは

    Go 1.13 に向けて知っておきたい Go Modules とそれを取り巻くエコシステム - blog.syfm
  • Goを学ぶときにつまずきやすいポイントFAQ | フューチャー技術ブログ

    他の言語になれた人が、初めてGoを書いた時にわかりにくいな、と思った部分はどういうところがあるのか、難しいポイントはどこか、という情報を自分の経験や、会社の内外の人に聞いたりしてまとめてみました。まだまだたくさんあるのですが、多すぎるのでまずはこんなところで。コンテナで開発することがこれからますます増えていくと思われますし、その時にコンテナとの相性が抜群なGoをこれから使い始める人もどんどん増えていくと思います。 Goは特に言語のコアをシンプルに、何かを実現するときはそのシンプルな機能を組み合わせて実現しよう、というコンセプトです。つまり、他の言語で実現したいこと・できていることに比べて、Goは組み合わせ(イディオム)でカバーする領域が広くなります。そのあたりのとっかかりになる情報を提供することが、これからGoを触る人にとってつまずきを減らすことになると思います。 Go Conferenc

    Goを学ぶときにつまずきやすいポイントFAQ | フューチャー技術ブログ
  • http.ListenAndServe() をインターネットに公開してはいけない - Qiita

    http.ListenAndServe() を使ったサーバーをプロダクションに投入していたのですが、海外からのアクセスが多くなったころにリソースリークが発覚しました。 ListenAndServeのドキュメント ListenAndServeのソースを見るとこうなっています。 func ListenAndServe(addr string, handler Handler) error { server := &Server{Addr: addr, Handler: handler} return server.ListenAndServe() } addr, handler 以外は http.Server のnil値がそのまま使われている事がわかります。この構造体にはいくつかのタイムアウト値がありまが、nil値で初期化されるとタイムアウトなしの状態になってしまいます。 Server型のドキ

    http.ListenAndServe() をインターネットに公開してはいけない - Qiita