[過去ﾛｸﾞ] Go language part 3 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
100(1): デフォルトの名無しさん [sage] 2019/11/23(土) 22:02:32.31 ID:5HHeTBXj(5/10) AAS
>>95ん、off？空指定とは違う挙動になるのかな？
179(1): デフォルトの名無しさん [sage] 2019/12/30(月) 09:38:05.31 ID:QVGDKUrk(1/3) AAS
標準パッケージのjsonのUnmarshal
なんでReaderインターフェースでなくてバイト配列を引数にしたんだろ？
DecoderはSAXみたいなトークナイザだしなぁ
329: デフォルトの名無しさん [sage] 2020/03/08(日) 03:17:31.31 ID:HYkfeWN3(1) AAS
どうでもええわｗ
333(2): デフォルトの名無しさん [sage] 2020/03/12(木) 09:34:07.31 ID:Ebv8j1sh(1) AAS
Kotlinは使えば使うほど良いなと思う
サーバーサイドもKotlinの世界になればいいのだ
400: デフォルトの名無しさん [sage] 2020/04/15(水) 19:49:21.31 ID:pyZsKR91(2/2) AAS
>>399それが何で遅くなるのか理解して言ってるか？
ポインタが無駄な処理になるからじゃなく、メモリアクセスとメモリ管理を最適化するため
実体配列のニッチな需要があるかぎりは実体は廃止できないという意見
正直、そういう需要なんて切って捨てていいと思う
Javaみたいに
480: デフォルトの名無しさん [sage] 2020/05/09(土) 19:27:11.31 ID:CUL9xwyE(1) AAS
開発陣のモチベーションはどうなんだろう。
なんかrubyと同じような臭いが。
495(1): デフォルトの名無しさん [sage] 2020/05/15(金) 01:28:18.31 ID:kU/eypzI(1) AAS
>>493493(1): デフォルトの名無しさん [sage] 2020/05/14(木) 17:27:46.77 ID:ljUxN++I(1) AAS
>>447
ものすごく遅い話なんだけど
そっかー、インタフェース定義とファクトリの実装が同じパッケージにある必然性って全くなかったんだな
io.Reader の実装が到るところにあるように、定義と実装を分離させれば済む話だった
あーでもない、こーでもない
いつの間にかそうリファクタリングしていて、アレ？となった
ていうかinterfaceを返すファクトリというもの自体があまりGo的ではない
その辺は思想がJavaなんかと大きく違うところで、Goでは戻り値には具象型を使うのが基本
interfaceは関数の引数に使うもんで、その関数を使う側のパッケージが必要に応じてinterfaceを実装するんだよ
それに従えば結果的にファクトリとinterface定義は別パッケージになる
874: デフォルトの名無しさん [sage] 2020/11/03(火) 22:33:55.31 ID:OQJ1TfTq(9/11) AAS
ただこれは「後付」であって、ここまで解明していればNodeでも対策は簡単に出来るわけだが、
実際はここまで解明するまでに時間がかかる。
AmazonS3がそういった類の、
つまり「timeoutのエラー処理を優先的に処理しないとその後の処理も遅れます？」みたいな特性を持っているとすると、
スペック上からは見えない落とし穴であり、Nodeなら嵌るがGoなら(知らなくても)嵌らない、というのはあり得る。
それはやっぱりNodeのシングルスレッドアーキテクチャの方が世間（他言語）からは特殊で、
Nodeだけ嵌り得る落とし穴も世の中には存在するということ。
こういうのに遭遇したくない場合、Goの方が安牌、というのはその通り。この点はNodeだけが特殊だから。
勿論この人が最初からGo使ってたら一番幸せだったろう、というのもその通り。
937: デフォルトの名無しさん [sage] 2020/11/06(金) 16:04:25.31 ID:vuRZSDYg(1) AAS
だれのために？
977: デフォルトの名無しさん [] 2020/11/14(土) 15:50:35.31 ID:QzputhfI(1) AAS
>名前が糞
同意せざるを得ない
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.041s