はてなブックマーク

えらく、反響があったのでちょっとまとめてみようかなと。 Taskとは？ ドキュメントホーム： リポジトリ： 特徴 タスクランナーやビルドツールとしてのGNU Makeよりもシンプルに記述 シンタックスはYAMLによる宣言的でトリッキーな記述方法を含まない インストール手順はほとんどの環境むけに整備済みで最悪GoとGitさえあれば簡単にインストールできる Makefileの代わりにTaskfile.ymlを書く Goのtext/template機能がプリプロセッサの役割を担っている どういった用途に向いている？ 主にMakefileをタスクランナー代わりに使っていた人向けです 複雑な依存を少ない行数で記述するビルドツールとしてはGNU Makeのほうが優れています GoやRustでは依存解決しつつビルドするツールを自前で持っているのでこれらのタスクランナーとして向いています（が、Rustには

この記事はGo 言語 Advent Calendar 2023のシリーズ２の４日目の記事です（穴があったので入りました！）。 goroutineの特徴 コルーチンをベースにコルーチンの以下の点を改良 言語組み込みワード「go」にて起動できる M:Nスレッドシステム採用によりマルチコア分散処理が可能 ブロッキングを検出したらネイティブスレッドが独立 プリエンプティブ性を追加(Go1.14以降) 以上により、goroutineスレッドシステムはコードを書く人にとって「ネイティブスレッド」の感覚で実装を書くことができ、「コルーチン」のようにメモリやタスクスイッチ負荷が小さく、「コルーチン」のような面倒な制約（期待するレイテンシ以上にCPUビジーにしてはいけないなど）も無いといういいとこどりのスレッドシステムになりました。 ネイティブスレッドライクによる特性 ネイティブスレッドを使ったプログラミン

循環インポートの問題点 現代のプログラミング言語の多くは１パスでプログラムコードを解釈します。インタプリタ型は当然としてC/C++も例外ではありません。つまり「コンパイル・実行」されるまでにソースコードを２度パースすることはありません。 さらにプログラム言語の多くは多重定義はバグの元なのでエラー扱いになります。なので対策の無いヘッダーファイルをincludeした時、再度同じヘッダーファイルが参照された場合に「多重定義」になってしまいます。 C/C++ではそのような「多重定義」を回避するために「インクルードガード」という対策をヘッダーファイルに施します。C/C++ではプリプロセッサという仕掛けに依存していてコンパイラは重複する定義がそれぞれどこのファイルを読み込んだ結果かを判別できません。なので「インクルードガード」という対策がヘッダーに必要なのです。 しかし、「インクルードガード」は方針が

エラー返値が無用な条件 関数ないしメソッドの実装がオンメモリ操作のみで完結 将来も（メモリ以外の）I/O操作は追加されることがない 逆にいうと上記の条件のいずれかが達成できない可能性がある関数やメソッドはエラー返値を付与すべき。 返値エラー型はerrorで統一する 返すエラーがerrorインターフェース型でなければそのエラーは正常にハンドリングできません。またerrorインターフェースを満たす別の返値型で返してerrorインターフェース型で受け取るのも後述のトラブルの元です。 Goの実装方針に「インターフェースで利用するものもコンストラクター相当では構造体ポインタで返す」というものがありますがコンストラクタを呼ぶ側は元型にアクセスすることが多いのでこういう方針になっています。が、エラー値に関しては元型を意識せずに利用可能にするという役割があって、この実装方針は当てはまりません。 エラーチェ

極力Goならではな特徴をいくつか挙げていく。 依存解決が必要最低限で互換性を考慮しつつ決定的 モジュール単位で依存をダウンロード。コンパイル対象はサブパッケージ単位。 依存の明示方法はコードに埋め込まれ、かつ未参照のインポートはコンパイルエラー。 つまり動作するコードのすべては正確な依存ツリーが明示されていて余計な依存は引き込まれない。 そして持ち前のコンパイルの速さを含め、相当深い依存ツリーでも依存解決にかかる時間は既知の処理系の中でも最速レベル。（唯一勝てるのはプリビルドバイナリが配布されている場合くらい） また、コンパイルやリンクに必要な処理量そのものが比較的少ないため、開発環境負荷も小さい。 かなり巨大なプロジェクトであってもメモリ8GBで困るようなことが無い。つまり、CI環境の維持にもローコストで済む。 ライブラリの提供側では後方互換性が破壊されるような変更はV1->V2というよ

これでgo mod tidyが通ってしまいます。 が、単純にローカルにあるサブパッケージを参照したいためだけに マルチモジュール化＋go.modにreplace手法を使うのは冗長すぎます。 もちろん、別の公開モジュールを一時的にローカルで参照したいのであればOKな手法でそのように解説しているものは問題ありませんが、初心者がそれらの記事をローカルインポートの手法であると誤解して実践しようとしてしまっているのが厄介なのです。 パッケージとは Goのコードからimport可能とするための概念 *.goファイルを含むフォルダーを「パッケージ」として扱います 同じフォルダ内のGoファイルの先頭にはpackage パッケージ名が統一されていることが必要です パッケージ名の命名が必要でフォルダ名と同じにすることが推奨されています go.modファイルが存在してしまうと単純パッケージではなくモジュールの扱

WebSocketのツラミ 中継サービスの対応がないと切れる ルーターによっては長時間アクセスがないと切れる 切れたら繋ぎなおすのはクライアントの実装次第 セキュアにつなぐためにはサーバーもクライアントも新バージョンのサポートが必要 接続数が膨れず、安定して接続を維持するのには結構ノウハウが求められる 単純に切れたら即繋ぐでは中継やサーバーに問題が発生することもある そこでEventSourceですよ メジャーブラウザでサポート・互換性も高い プロトコル仕様がただのHTTPロングポール＋アルファ なのでほとんどの接続経路で中継トラブルが少ない JSのEventSource実装がセッション維持を頑張ってくれる サーバーから切断されたら再接続をしようとする 特にGoなら標準機能でさっくりサーバーが書ける クライアント実装 let es = new EventSource("/sse"); es

Goにはioパッケージにまつわるbyte単位のストリーミング処理機能が素敵なので、その良さを紹介してみようと思います。 io.Reader/io.Writerについて ioパッケージにてReaderとWriterのインターフェースは以下のようになっています。 type Reader interface{ Read(b []byte) (sz int, err error) } type Writer interface{ Write(b []byte) (sz int, err error) } 読める書けるだけのシンプルな定義です。このシンプルさが素敵なんです。 派生インターフェース io.Seeker io.Closer io.ReadSeeker io.ReadSeekCloser io.WriterSeeker io.ReadWriteSeeker io.ReadCloser io

これはGo Advent Calendar 2022の21日目の記事です。 たびたび「Enumイディオム」がGoに欲しいという要望が話題になるのでその話をまとめてみる。 議論の中心はここが詳しい。 「Enumイディオム」が解決する課題 文字列表現がつく 反復処理ができる 偽の列挙値を導入することを防ぐ 名前空間を分離する などがあるらしい。上にあげた課題がGo標準では解決しにくいという理由がよく上がるのですが、Enumイディオムの追加方法は何パターンかあります。 Enum型プリミティブを言語仕様に加える ライブラリとしてEnumオブジェクト実装を提供する 現状の推奨「iotaによる手法＋go-generate」による方法 「Enum型プリミティブを言語仕様に加える」について 言語実装のアップデートが必要 reflectパッケージのアップデートが必要 後方互換のためiota式とEnum式の２

package main import "log" type S struct { value interface{} } func (s *S) Get() interface{} { return s.value } type Value interface { Get() interface{} } func Do() Value { var res *S if false { res = &S{123} } return res } func main() { v := Do() if v == nil { log.Fatal("v is empty!") } log.Println("v is not empty:", v) } 空判定に引っかからず、有意な値を返されたという処理フローになっちゃうという問題。 Typed-nil問題について これは「Typed-nil」問題といっ

[ { "name": "四国めたん", "speaker_uuid": "7ffcb7ce-00ec-4bdc-82cd-45a8889e43ff", "styles": [ { "id": 2, "name": "ノーマル" }, { "id": 0, "name": "あまあま" }, { "id": 6, "name": "ツンツン" }, { "id": 4, "name": "セクシー" } ], "version": "0.10.0" }, { "name": "ずんだもん", "speaker_uuid": "388f246b-8c41-4ac1-8e2d-5d79f3ff56d9", "styles": [ { "id": 3, "name": "ノーマル" }, { "id": 1, "name": "あまあま" }, { "id": 7, "name": "ツンツン"

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

ソフトウェアの品質 通常ソフトウェアの品質を高く保つには以下の手続きを継続する必要があります。 イディオムやアルゴリズムを適切なものを正しく選択してコードを記述する コンパイルにより誤りを検出・修正してコードの正確さを高める 静的解析により誤りを検出・修正してコードの正確さを高める 各種テストの実行により誤りを検出・修正してコードの正確さを高める レビューにより誤りを検出・修正してコードの正確さを高める なぜ継続する必要があるのかというと、ソフトウェアをゼロバグでリリースするのは困難だからです。リリース後実運用にて発覚する問題点があれば上記の手続きをもう一度踏む必要があるからです。 ソフトウェアの品質を下げる要因のひとつが「ポカ」で、ざっくりいうとこれは「うっかり正しくない記述をしてしまったりする」ことです。 実は多くの種類があるポカ ランタイム検出項目のうち、言語処理系によってはコンパイ

andlabs/ui、lxn/walkは簡素なウィジェットセットだけをサポート。fyne、Qtベースは豊富なウィジェットセットを持つ。いずれも少人数でメンテしていることを考えると、コンパクトなツールキットで活発な活動中のものが品質面でおすすめです。 IMEサポートの有無は日本語圏でのGUI提供において重要なファクター 英語圏生まれのGUIライブラリの多くはIMEサポートをあまり考慮していない GLFWはIMEサポートのPRが何年も取り込まれない状況がつづいている HTMLベース（ChromeやWebView）ならIMEサポートを内包している 自作系はどうしてもギョッとする挙動や細かく期待しない挙動にちょくちょく出会ってしまう（例えば日本語のワードラップ未対応など） HTML系はUIを構築していく上でのほとんどのケースで細かい問題に対する解決策がちゃんとある クロス環境対応ということであれば

マルチコア化の未来予測 半世紀前にSF映画「2001年宇宙の旅」に登場するコンピューターHAL-9000が並列コンピューティングの未来を示しました。マルチコアで構成されたコンピューターの物理コアを取り除いてもすぐにクラッシュせずに性能ダウンして処理が継続するという演出がありました。 当時ですらシングルコアコンピューティングの限界が予想されていて、現状のコンピューティングがマルチコア化しているという未来をしっかり予測できていたことがわかります。 演出はコア数に応じてコンピューティング性能がスケールしていることを表現しています。これはマルチコアスケールするソフトウェア実装の未来を示していたと思います。 シングルコア性能向上の頭打ち 2003年以降あたりはCPUの動作周波数が伸び悩み出したところ。 https://queue.acm.org/detail.cfm?id=2181798 より その

Lorca＋SvelteKitでやってみる！ https://github.com/zserge/lorca https://github.com/sveltejs/kit あらかじめ必要なもの go(version 1.17.2以降) nodejs(16.9.0以降),npm(7.21.1以降) Chrome/Chromium/Edgeのいずれか プロジェクトの開始 mkdir sample-gui cd sample-gui go mod init sample-gui npm init svelte@next frontend // Choice "Svelte app template" is "Skelton Project". // Choice "Use TypeScript" is No. // Choice "ESLint" is No. // Choice "Prett

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

Kryptonのスマホアプリの配布が終了してしまいました・・・事実上この仕組みの利用はできなくなっていくでしょう。残念です。 SSH/U2F認証をスマホで代行する「Krypton」というツールが便利でとても気に入っています。その使い方と良さをご紹介します！ 以前は「Kryptonite」という名前でSSH認証の代行の仕組みだけをサポートしていましたが、現在は「Krypton」という名称でU2F認証の代行をメインにおいているようです。 オープンソースでZeroTrustインフラにおいてセキュアを保つ仕掛けがウリで、一昨年Akamaiに吸収されました。 機能 一般ユーザー向け U2F認証代行 開発者向け SSH公開鍵認証代行 Gitのコミット署名代行 いずれも、「秘密鍵で署名をする機能」の応用です。 概念的にはU2Fドングル内にあるセキュアチップと呼ばれる「耐タンパー性の秘密鍵保持・署名ハード

https://www.kbaba1001.com/entry/2021/09/17/073149 （該当記事が削除されました） RubyのサービスをGoで置き換えるのは３倍人手がかかる 何するにも機能不足 JSONの読み書きにわざわざ構造体書くの面倒 同僚がGoを選ぼうとしたら愚かな選択ですねと答える サーバーサイド開発にGoを使うのは危険 っぽい内容だったかと。 だいぶGoの特徴や既存の言語との考え方の違いが広まってきてるのかなぁと思っていた矢先だったので十年くらい前のような指摘をあえて今されていてびっくりした。 正直、ここに書かれたようなヘイト項目は既出すぎるので、もし影響の大きい項目を多くの人が同様に嫌っているならばGoはここまでの人気のある処理系になることはなかったと思う。（もしくは多くの人が嫌ってはいるが影響の小さい項目ということ） Goは出た当初、こういうヘイトが世界中のブロ

CGOフリーなSQLiteドライバーmodernc.org/sqlite は 以下のC記述をGoにトランスレートする仕組みで作られたPure-GoなSQLite3ドライバーです。 https://gitlab.com/cznic/ccgo https://gitlab.com/cznic/libc これを利用して型安全なORM「ent」でつかう方法をまとめてみます。 ドライバーラッパー entがsqliteドライバーに要求するForeignKeysフラグがmodernc.org/sqlite では標準でスイッチできないのでそこをサポートするコードを差し込みます。幸い、ドライバー名はsqlite3ではなくsqliteで重複していないのでsqlite3で登録することでentがサポートするドライバー名に合わせることができます。 sqlite_driver.go package main impo

Windows対応の曖昧なAPIを非難する記事 この記事はGoが曖昧に扱うAPIについて非難していて、より厳格に扱うことのメリットを解説しています。 Goのこれらの指摘の挙動が実際にどの様なものかを解説していきます。 無視する挙動 Goの標準ライブラリのAPIはどちらかというとUnix/Posixに寄せていて、一部のWindowsに無い概念に関する処理（ファイルのパーミッション操作など）は黙って無視したりする。 これはUnix/Posix用の実装が同じソースコードのままWindowsでも動作するために必要なダミーです。ここでそのようなダミー実装をアプリケーション作成側の責任にすると実装やテストが大変面倒になってしまう。 逆に、GoではUnix/Posixにあるforkやthreadに関するAPIをサポートしません。特にforkというAPIはWindowsには全くない概念であり、互換性を取る

go mod init sample npm init svelte@next frontend // Choice "Svelte app template" is "Skelton Project". // Choice "Use TypeScript" is No. // Choice "ESLint" is No. // Choice "Prettier" is No. cd frontend npm install npm i -D @sveltejs/adapter-static@next // +build !release package main import ( "log" "net/http" "net/http/httputil" "net/url" ) func init() { u, err := url.Parse("http://localhost:3000

Goには「なぜ三項演算子がないの？」という意見を時々見かけます。言語開発側の意見と僕の見解をまとめていきますー。 FAQ その回答はGoのFAQに明瞭に書かれています。 Goに?:演算子がないのはなぜですか？ Goには3項テスト操作がありません。 同じ結果を得るには、次を使用できます。 Goに?:がない理由は、言語の設計者が、操作が頻繁に使用されて不可解な複雑な式を作成するのを見ていたためです。 if-else形式は、長くなりますが、間違いなく明確です。 言語に必要な条件制御フロー構造は1つだけです。 ネストを許す GoもPythonもif-elseが文であり、式として扱えない方針を採りました。式として扱えないということは、一定の構文でのみ記述が可能ということです。三項演算子はその性質上式として扱えることになります。 式として扱える場合なにが書けるようになるのかというと、各項や条件に式が書

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

この記事はGoのコードをいくらか書いていてもっとGoらしい書き方に興味を持ってからみてね！（Go初見で読んでも響かない内容です） Goは「シンプルで迷いなく書ける」というのが売りではあるのですが、 実際書き始めると、「あれ？これどうやって書くほうがいいの？」ってポイントにちょくちょく巡り合います。そのようなポイントを思い出しながら今思うベターな書き方を紹介しようと思う。 err変数束縛について err変数の受け取りを複数回繰り返していると「:=」だけで書けないという状況に出会うでしょう。 err := funcA() if err != nil { ... } err := funcB() // <- コンパイルエラー： "no new variables on left side of :=" if err != nil { ... }

Goのプロジェクトをどの様なファイル構成で配置すれば良いか読み物が少ないという指摘を見たのでまとめてみようと思う。 GOPATHについて Go1.16がリリースされたことでGo-Moduleによるプロジェクト構成が標準で推奨されることになりました。（Go1.11までさかのぼってGo-Moduleは使える様になってます） Go-Moduleモードでは「GOPATH配下にプロジェクトを置かなければならない」という制約からは解放されています。なので、実質GOPATHはどこを指していても構わないし設定されていなくても「ユーザーホーム/go」というデフォルトの場所が決まっているので開発できます。 おすすめの環境変数設定は以下の２つだけ。 「GOPATH=~/.go」（WindowsはGOPATH=％USERPROFILE%\.go） 「PATH=＄GOPATH/bin:$PATH」（Windowsは

この記事はGo 2 Advent Calendar 2020の２１日目の記事です。 はじめに こどもがショッピングモールに展示してあるようなモニタに映る自分自身のジェスチャーで何かすると反応がえられるという仕掛けに夢中になっていたのでいつでも自宅でできるように自作してみた。 必要なモノ フロントカメラ（Webカメラ外付けでもOK）付きのPCやスマホ 成果物 ゲーム内容と遊び方 タイトルでスタートを押す カメラに全身が映る程度に十分離れる ３秒カウントダウンの後風船がどんどん飛んでいく カメラに映る自分の手首を風船に当てると風船は割れる ３０秒以内にできるだけ多くの風船を割る 結果表示のスコアをみんなで競い合うと楽しい 使われているノウハウ PoseNet/TensorFlow-JS WebAudio 2D-Canvas SpaGo/Go ソースコード つまづいたところ 映像を表示用とPos

よく知られる良さ ネイティブコード出力で実行効率が良い コードの可読性を重視している 開発でよく使うツールがバンドル クロスビルドが簡単にできる コンパイルが遅くない（LLライクにrunできる） 並行処理の抽象化を組み込み言語仕様にもつ メモリ安全である 上記の一部に解説を加えつつあまり言及されない良さを以下にまとめます。 依存解決が最小限で決定的 ここにも書きましたが、Goの依存解決は常に 最小限のダウンロード 最小の範囲でのみビルドを実行 だけが走ります。これを一度体験すると、従来のパッケージ依存管理が冗長で余計なものをビルドしすぎることに気づくでしょう。これらに相当の時間を奪われているのです。 また、Goモジュール機構によりそのバージョン選択は決定的に安定動作するバージョンに決められます。このことのメリットは数ヶ月後のリビルドで安定してビルドできることで実感できるでしょう。 開発環境