タグ

ブックマーク / zenn.dev/nobonobo (5)

  • Goとエラーハンドリング慣習について

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

    Goとエラーハンドリング慣習について
  • Go標準でブラウザにイベントストリーミングする

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

    Go標準でブラウザにイベントストリーミングする
  • Goで軽量なデスクトップアプリ作成

    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のヌル安全について

    「ヌル参照の考案は10億ドル単位の過ち」と語ったホーア氏(Goの並列処理モデルCSPの考案者でもあります)。そしてモダンな言語処理系は「ヌル安全」を持つのが流行です。しかし、Goには完全な「ヌル安全」の仕組みを持ちません。 Goのメモリ安全機能 もちろんGoは完全なヌル安全とは言えないまでもヌルポ参照対策や不正なメモリ参照を防ぐいくつか考慮した仕組みや慣習を持っています。 ポインタの算術移動を許さない言語仕様 確保するメモリは全てゼロ値で初期化済み エラーがnilなら有効な値を返すという慣習 必須のエラーチェックがヌルチェックを兼ねている これらによりGoは完全に「メモリ安全」であり、「ヌル安全まであと一歩」までの仕組みを持っています。それでもヌルポ参照は「ランタイムパニック」という形で現れます。 ランタイムパニック Goでは「ランタイムパニック=コードの不備の通知」です。 多くのコードの

    Goのヌル安全について
  • Goの良さをまとめてみた

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

    Goの良さをまとめてみた
  • 1