Goのローカルパッケージのインポートについて
これでgo mod tidyが通ってしまいます。 が、単純にローカルにあるサブパッケージを参照したいためだけに マルチモジュール化＋go.modにreplace手法を使うのは冗長すぎます。 もちろん、別の公開モジュールを一時的にローカルで参照したいのであればOKな手法でそのように解説しているものは問題ありませんが、初心者がそれらの記事をローカルインポートの手法であると誤解して実践しようとしてしまっているのが厄介なのです。 パッケージとは Goのコードからimport可能とするための概念 *.goファイルを含むフォルダーを「パッケージ」として扱います 同じフォルダ内のGoファイルの先頭にはpackage パッケージ名が統一されていることが必要です パッケージ名の命名が必要でフォルダ名と同じにすることが推奨されています go.modファイルが存在してしまうと単純パッケージではなくモジュールの扱
GoとSvelteKitの組み合わせ
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とエラーハンドリング慣習について
エラー返値が無用な条件 関数ないしメソッドの実装がオンメモリ操作のみで完結 将来も（メモリ以外の）I/O操作は追加されることがない 逆にいうと上記の条件のいずれかが達成できない可能性がある関数やメソッドはエラー返値を付与すべき。 返値エラー型はerrorで統一する 返すエラーがerrorインターフェース型でなければそのエラーは正常にハンドリングできません。またerrorインターフェースを満たす別の返値型で返してerrorインターフェース型で受け取るのも後述のトラブルの元です。 Goの実装方針に「インターフェースで利用するものもコンストラクター相当では構造体ポインタで返す」というものがありますがコンストラクタを呼ぶ側は元型にアクセスすることが多いのでこういう方針になっています。が、エラー値に関しては元型を意識せずに利用可能にするという役割があって、この実装方針は当てはまりません。 エラーチェ
改めて見直すGoの特徴
極力Goならではな特徴をいくつか挙げていく。 依存解決が必要最低限で互換性を考慮しつつ決定的 モジュール単位で依存をダウンロード。コンパイル対象はサブパッケージ単位。 依存の明示方法はコードに埋め込まれ、かつ未参照のインポートはコンパイルエラー。 つまり動作するコードのすべては正確な依存ツリーが明示されていて余計な依存は引き込まれない。 そして持ち前のコンパイルの速さを含め、相当深い依存ツリーでも依存解決にかかる時間は既知の処理系の中でも最速レベル。（唯一勝てるのはプリビルドバイナリが配布されている場合くらい） また、コンパイルやリンクに必要な処理量そのものが比較的少ないため、開発環境負荷も小さい。 かなり巨大なプロジェクトであってもメモリ8GBで困るようなことが無い。つまり、CI環境の維持にもローコストで済む。 ライブラリの提供側では後方互換性が破壊されるような変更はV1->V2というよ
Go標準でブラウザにイベントストリーミングする
WebSocketのツラミ 中継サービスの対応がないと切れる ルーターによっては長時間アクセスがないと切れる 切れたら繋ぎなおすのはクライアントの実装次第 セキュアにつなぐためにはサーバーもクライアントも新バージョンのサポートが必要 接続数が膨れず、安定して接続を維持するのには結構ノウハウが求められる 単純に切れたら即繋ぐでは中継やサーバーに問題が発生することもある そこでEventSourceですよ メジャーブラウザでサポート・互換性も高い プロトコル仕様がただのHTTPロングポール＋アルファ なのでほとんどの接続経路で中継トラブルが少ない JSのEventSource実装がセッション維持を頑張ってくれる サーバーから切断されたら再接続をしようとする 特にGoなら標準機能でさっくりサーバーが書ける クライアント実装 let es = new EventSource("/sse"); es
Goへのヘイトに対する考え方
https://www.kbaba1001.com/entry/2021/09/17/073149 （該当記事が削除されました） RubyのサービスをGoで置き換えるのは３倍人手がかかる 何するにも機能不足 JSONの読み書きにわざわざ構造体書くの面倒 同僚がGoを選ぼうとしたら愚かな選択ですねと答える サーバーサイド開発に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のエラーハンドリングが採ったスタイル 多値返し 直積（関数の返値とエラーを両方返す） try-finallyをdeferという機構でカバー panicはプロセスを落とすためのもの Goはこの戦略でエラーハンドリングを行うとしましたので、「多値はなぜタプルじゃないんだ？」、「直和（返値orエラー）で十分じゃ？」「panic-recoverでtry-catchできそう？」などいう様な他の処理系の風習を持ち込むことは意味がありません。そしてそれらの提案の多くはすでに検討されリジェクトされてきた経緯があります。 「try組み込み関数」プロポーザルなんかも検討されマージ直前くらいまで進んだこともありますが、「Goのエラーハンドリング」にとって一長一短がありました。その欠点課題は解決できずに最終的にリジェクトされました。 「多値返し」は実にCPUフレンドリーな機構で、C言語の関数呼び出し規約にちょ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
