タグ

golangに関するilyaletreのブックマーク (5)

  • golangとDockerとOOM — KaoriYa

    golangで書いたプログラムをDockerで動かしOOMが発生した際になるべく情報を残して殺される方法を紹介します。 2020/08/16追記: この記事の内容はgolangに関してはやや現実的ではなくなってしまいました。 詳しくは続編を参照してください。 TL;DR golang製のプログラムは仮想メモリ(VSZ)の確保に失敗するとgoroutineのダンプを吐いて死ぬ DockerのOOMはRSSベースで検出時にSIGKILLを投げてくる Docker利用時にVSZで制限をかけるスクリプトを書いた golang製のプログラムはlinux-amd64において最低でも101MBのVSZを要求する VSZの制限がそれより小さいと当然起動できない 実際のRSSは3MB程度で起動する Background コンテナ内で動いているプロダクション上のgolang製のプログラムが時々OOMに殺されて

    ilyaletre
    ilyaletre 2020/01/19
    確かにdockerを使ってプロセス管理する側からするとランタイムの特性把握してVSSで制限するよりRSSで制限する方が分かりやすいなぁ。(今回のような要件でなければ)
  • Go の channel 処理パターン集 | Hori Blog

    Hori Blogフリーランスでバックエンドエンジニアとして活動している Ryota Hori のブログです。 最近はテック系記事より雑記ブログ気味。 この記事は Go Advent Calendar 2017 の 1 日目の記事です。 Go の長所に goroutine による非同期処理がありますが、どうしても channel の取り回しで黒魔術化しがちです。少しでも闇を減らしていきたいので、 channel らへんの取り回しについてパターンをまとめました。チートシート的に使えれば嬉しいです。 Go の channel の基礎 入門資料として使いたいので、題に入る前にざっくり基礎を。 定義のパターン channel には capacity という概念があります。 capacity は channel 内でバッファリングしておける容量のことで、 capacity に空きが無い場合は送信側

    Go の channel 処理パターン集 | Hori Blog
  • Go にジェネリクスがなくても構わない人たちに対する批判について - methaneのブログ

    なんども繰り返される話でうんざりなんだけど、繰り返されるたびに反論するのもアレなので、URL貼れるように記事にしておく。 Goが頑なにジェネリクスいらないというだけ他の言語勢から失笑買ってるというのは自覚して— {{alert()}} (@mizchi) 2017年9月19日 頑なに要らないと言ってる人が具体的にどの発言のことを差してるのか分からないけど、コア開発者たちはツールチェインやランタイムの進化を優先していただけで頑なに拒否してたりはしません。今はツールチェインやランタイムが大分進化したから、Goの適用範囲を広げるためにジェネリクスを含めて機能追加も検討し始めようかっていうフェーズです。 あとどの言語にもちょっと公平的な見方ができなくなった痛いファンはいるもので、そういった人たちをいちいちあげつらってこういう言い方で失笑するのは、別に止めはしないけど自分の格を下げるだけだと思う。

    Go にジェネリクスがなくても構わない人たちに対する批判について - methaneのブログ
    ilyaletre
    ilyaletre 2017/09/20
    golangは今でも充分問題解決できるけど、ようやくもう少し便利になりそうなジェネリックを導入するステージに入ったよやったー。 という事実認識だけで充分だと思ったけどそうではないのか。
  • Go並行処理パターン

    https://classmethod.connpass.com/event/55140/ の発表資料 Goの並行処理に必要な幾つかの機能と、それをつかったサンプルをご紹介

    Go並行処理パターン
    ilyaletre
    ilyaletre 2017/05/18
    読んでよかった。chanを色んな角度で眺められたおかげで、少しモデルを頭の中に描きやすくなった。参考になった。
  • なぜGo言語 (golang) はよい言語なのか・Goでプログラムを書くべき理由 | yunabe.jp

    結論としてはGo言語には以下のようないくつかの長所があり、現実路線で非常にバランスがとれた言語だと思います。 これらの長所のために失われたメリットも当然いくつもありますが、一定程度以上の規模のプロジェクトで利用する言語の選択肢としては現存するプログラミング言語の中では一番か二番目によいのではないかと思います。 コンパイルが速い (vs. C++) GCとメモリ安全性 (vs. C++) 妥当で現実的なレベルの型安全性 (vs. Python/Ruby) 実行時パフォーマンスが良さ (vs. Python/Ruby) 現実問題、ある程度の規模と期間のプロジェクトになると型検証があるとリファクタリングなどがだいぶ楽になるのでありがたい。 型があるので自然と実行時パフォーマンスも良い 標準ライブラリが整備されている (vs. C++) むしろ標準ライブラリにjsonのparserすら存在しないC

    ilyaletre
    ilyaletre 2017/03/17
    確かに大きなプロジェクトで採用するにはGoは良い選択肢に思える。Haskellの言語仕様が複雑かというとちょっと疑問ではあるけど。
  • 1