Go language part 5

**デフォルトの名無しさん** · 2022/02/27(日) 07:43:20.04

Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式
https://golang.org

公式ドキュメント
https://golang.org/doc/

公式外パッケージドキュメント
https://godoc.org

ブラウザ上で試し書き
https://play.golang.org

※前スレ
Go language part 4
https://mevius.5ch.net/test/read.cgi/tech/1605467680/

**デフォルトの名無しさん** · 2022/12/10(土) 19:27:57.88

ちなみにChatGPTはセッション的に一連の会話を一時的に覚えててくれるらしいから、
二回目には同じ関数のコメントが省略されてる
関数の名前を明示すれば、「○○のテストコード書いて」でやってくれたかも
まあスレチだな

**デフォルトの名無しさん** · 2022/12/10(土) 22:11:37.20

>>703
テストケース考えるときの助けによさそうだな
たいしたもんだ

**デフォルトの名無しさん** · 2022/12/11(日) 20:52:12.36

Go言語はこの先生きのこれるのか？聞いてみたら面白いかもな。

**デフォルトの名無しさん** · 2022/12/11(日) 22:00:53.37

あとゴーファーくんがキモいかどうか聞いてくれ

**デフォルトの名無しさん** · 2022/12/11(日) 23:59:02.05

https://i.imgur.com/XeXqmNB.png

**デフォルトの名無しさん** · 2022/12/12(月) 00:36:12.57

やはりChatGPTだめだな！
"かわいらしい外観が特徴で愛される存在となってる"
こんな回答では人類の知性にまだまだおよばない！
ただしい知性ある回答はこうだ!
"きもかわいい外観で一部のマニアックなgo開発者に愛されています"

**デフォルトの名無しさん** · 2022/12/12(月) 05:06:40.93

地元のマイナーなサッカーチームについて聞いたら「日本でも見逃すことのできないチームの一つ」とか適当に答えたぞコイツ
IT系以外は知ったかする

**デフォルトの名無しさん** · 2022/12/12(月) 10:35:46.50

>>710
ITでも知ったかするよ
N88BASIC書いてもらったら大嘘な奴が出てきた
ちゃんと下げ親指ボタン押して運営にレポートするとよろし

**デフォルトの名無しさん** · 2022/12/12(月) 14:23:40.21

真面目な話、わからんことを素直に「それについてはわかりません」と言ってくれないのはかなりタチがわるいな
新入社員だったら要注意人物だよ

**デフォルトの名無しさん** · 2022/12/12(月) 15:22:25.27

>>712
わかりません　と答える場合もある
AI君がわかった気になってるだけ
更にタチが悪いけどもｗ

スレに沿って書くなら、エンジニアの仕事はまだまだ安泰だが、使いようによっちゃ楽はできる
って感じね

**デフォルトの名無しさん** · 2022/12/27(火) 22:42:29.20

rainu/go-command-chain: A go library for easy configure and run command chains. Such like pipelining in unix shells.
https://github.com/rainu/go-command-chain

**デフォルトの名無しさん** · 2022/12/28(水) 10:01:43.96

CLIの引数の読み取りするライブラリーは何がおすすめ？

kingpinは最近更新されてないからkong試してみたが
なんか使いづらい
ここに挙がってる他のやつ試そうかと思う
https://www.reddit.com/r/golang/comments/9uybnt/choosing_a_library_for_cli_application/

Neither, personally I like https://github.com/jessevdk/go-flags. I like the declarative approach a lot more than the imperative one used for many other options, and it's extremely feature-rich.

**デフォルトの名無しさん** · 2022/12/28(水) 10:02:39.35

https://github.com/jessevdk/go-flags

**デフォルトの名無しさん** · 2022/12/28(水) 10:04:18.11

https://github.com/spf13/cobra
これ

**デフォルトの名無しさん** · 2022/12/28(水) 10:25:06.75

>>717
Cobraはこんな感じのこと書かれてるけど
どんなコードを指してるのか分からん

kingpinは直感的に使える気がするけどメンテナンスされてない
問題なければこのまま使えば良いか？

Both cobra and urfave/cli both enforce a globals-heavy, inversion-of-control architectural pattern that's difficult to maintain.
IMO, Kingpin is the only widely-used CLI library that takes an appropriate architectural approach.

**デフォルトの名無しさん** · 2022/12/28(水) 18:14:44.71

>>718
読んできて判断すればいいじゃん。そんなに読めないものじゃないし使い方も難しくない。アーキテクチャはたしかに理想的ではないと俺も思ってるけど、利用面からの意見としては、、
実戦で使用されていて信頼できる
機能面でも多言語の相当品と同じことがまあまあの書きやすさで書ける。ただしやや歴史的機能があったりして隅々まで洗練されてるとは言い難い印象
コマンドラインの補完などほかの言語では少々保守が面倒な機能があって便利

っと思ってる。でもとにかく評判より自分で確かめたらいいよ

**デフォルトの名無しさん** · 2023/01/03(火) 22:07:17.76

cobraはサブコマンドを無限に生やすような大規模向け、Kubernetes/dockerで使用されてる。
そこまで拡張する予定がない場合はgo-flagsかもっとシンプルな mitchellh/cliかな？ちょっとオプションがあるだけなら標準?のflagsだろうけど、普通に*nixのfindぐらいオプションがあるならやっぱりgo-flagsがおすすめだわ
大した関連性がないのに１つのバイナリのサブコマンドになってるより、別プログラムのほうが設計もメンテも楽だしcobraが**とても**メンテしやすいという話だけど、それは変らない。
本当にそこまで多数のオプションで動きが変わるようなプログラムを作るのか？という自問自答が必要だと思う、いやcobraは良いと思うけどね

**デフォルトの名無しさん** · 2023/02/02(木) 11:00:03.89

https://go.dev/blog/go1.20

**デフォルトの名無しさん** · 2023/02/02(木) 22:07:10.87

正式版リリースされたんだろうね。

**デフォルトの名無しさん** · 2023/02/05(日) 14:04:47.63

ジェネリックスって、有名どころのOSSのライブラリで活用されたりしてるの?
それとも手遅れ?
ORMあたりでこねぇかな

**デフォルトの名無しさん** · 2023/03/03(金) 19:04:29.44

Go言語でマイクロサービスの実装を解説してる書籍はありますかねえ？

**デフォルトの名無しさん** · 2023/03/13(月) 22:26:20.80

>>475
今まさに使ってるよ

**デフォルトの名無しさん** · 2023/04/05(水) 05:10:28.93

>>724
以下は、Golangを使用してマイクロサービスを開発するための書籍です。

"Goで学ぶマイクロサービス設計入門" - 田中充史著
　　この本は、Golangを使用してマイクロサービスを設計する方法を解説しています。サンプルコードを使用して、マイクロサービスの作成、展開、スケーリングなどを実践的に学ぶことができます。

"GoによるWebアプリケーション開発" - 佐藤幸一著
　　この本は、Golangを使用してWebアプリケーションを開発する方法を解説しています。マイクロサービスの設計と開発に必要な概念と技術を学ぶことができます。

"Goマイクロサービスパターン" - マテウス・カルステンス著
　　この本は、Golangを使用してマイクロサービスを実装するためのパターンを紹介しています。パターンに従って実装することで、マイクロサービスの堅牢性、柔軟性、スケーラビリティを高めることができます。

以上の書籍は、Golangを使用してマイクロサービスを開発する際に役立つ情報が含まれています。どの書籍も、実践的なアプローチを採用しており、Golangの基礎から応用まで幅広くカバーしています。

**デフォルトの名無しさん** · 2023/04/24(月) 17:12:53.41

Go言語入りユニクロTシャツ、Akamaiが提供　コードを動かしてみた人も=ITmedia

**デフォルトの名無しさん** · 2023/06/09(金) 20:38:28.47

1.20.5リリース

**デフォルトの名無しさん** · 2023/06/25(日) 22:02:04.84

ビルトインmin,maxやっときたか

**デフォルトの名無しさん** · 2023/07/26(水) 21:01:05.26

今期の公式調査が来たからみんな答えよう

以前の発表通りエラー制御に本腰入れ始めるのかまたもや意識調査が含まれてた
AIについての質問もあったし標準で組み込まれる未来もあるのかしら

**デフォルトの名無しさん** · 2023/07/26(水) 23:19:31.81

Goはこの中途半端な立ち位置のまま
この限られた用途以外で一般的に使われる言語にはならないと思われる

**デフォルトの名無しさん** · 2023/07/27(木) 08:50:36.21

昔Rubyがブイブイいわせていた時、私はPythonを選びました
本物には本物が分かります、そして私は静的言語としてGoを選択します
そうです、これが本物の回答なのです
いえ、これは私が優れているということではありません
Goが優れているということなのです

**デフォルトの名無しさん** · 2023/07/27(木) 13:33:27.28

goもこのまま衰退してしまうのだろうか。
今からならrust覚えた方がいいかな。

**デフォルトの名無しさん** · 2023/07/27(木) 22:38:03.18

そういえばジェネリクスはもう実装されたんだよな。もうinterface{}地獄じゃないのかな。

**デフォルトの名無しさん** · 2023/07/29(土) 17:37:17.23

まだ地獄やろ、
そんなはやくライブラリに取りこまれないんじゃないか
ORMとかどうなったのかな

**デフォルトの名無しさん** · 2023/07/31(月) 00:39:34.75

agoutiのかわりのライブラリでないかなー

**デフォルトの名無しさん** · 2023/08/18(金) 16:42:15.53

かなり早い段階で翻訳が出たな
原著公式レポがあるから動かす手間を惜しまなければ何がダメなのか分かるけどね
https://github.com/teivah/100-go-mistakes/blob/master/09-concurrency-practice/68-string-formatting/main.go

“開発の失敗学”から生産性とコード品質を高める。『Go言語 100Tips ありがちなミスを把握し、実装を最適化する』
Goプログラミングの間違いを網羅的に解説した一冊
https://forest.watch.impress.co.jp/docs/bookwatch/news/1524131.html

https://www.アmazon.com/100-Mistakes-How-Avoid-Them/dp/1617299596
翻訳者ご本人柴田芳樹 5.0 out of 5 stars The equivalent of "Effective Java"
>However, please note that there are many minor errors in the book, so if you can read Japanese, I recommend the Japanese version that I have translated.

なおreadme翻訳募集中
README: Japanese translation 🇯🇵
https://github.com/teivah/100-go-mistakes/issues/30

**デフォルトの名無しさん** · 2023/09/03(日) 01:50:02.49

最近goはじめたけど、例外処理になれないわ

今まで安易にスローしてきたつけが出てる感じ

**デフォルトの名無しさん** · 2023/09/17(日) 01:24:19.14

身内に不幸があったので

**デフォルトの名無しさん** · 2023/09/28(木) 18:02:19.03

みんなgoに帰ってくる

**デフォルトの名無しさん** · 2023/09/28(木) 18:30:24.70

女性がイクときは3パターンある
1.come(欧米)
2.go(日本)
3.end(日本ではあまり知られていない)

**デフォルトの名無しさん** · 2023/11/27(月) 22:53:28.32

mattnさんのGo本半額だったのに買い忘れた…
昨日でセール終わってた

**デフォルトの名無しさん** · 2023/12/31(日) 23:28:43.30

もっと盛り上げてもらっていっすか？

**デフォルトの名無しさん** · 2024/01/10(水) 20:53:52.31

goいいよな
わかりやすい

でもpythonのあほみたいな量のライブラリ使った後は自分で作んなきゃいけないんかとなる

**デフォルトの名無しさん** · 2024/01/10(水) 21:15:00.66

マイクロサービス向けの言語だから
APIサーバーとか小さな特化したものを
サクッと作るのに適してる

それ以上のことやると死ぬだけ
まさしく適材適所

**デフォルトの名無しさん** · 2024/01/11(木) 20:28:02.09

コピペ地獄

**デフォルトの名無しさん** · 2024/01/15(月) 10:36:24.87

勉強がてらGoでwebサービスやってるけどLaravelで良いじゃんって気がしてしょうがないw
PHP Laravel再評価の時代来そう

**デフォルトの名無しさん** · 2024/01/15(月) 11:07:21.77

> PHP Laravel再評価の時代来そう

こない。

**デフォルトの名無しさん** · 2024/01/16(火) 00:18:43.14

プロの労働市場は、Ruby, AWS Solution Architect だけ。
Java は多重請負構造のIT 土方

米国年収でも、Rubyは、Go/Rust/Elixir の3大言語を超えた！

Ruby, Elixir : 9.3 万ドル
Go : 8.9
Rust : 8.7

多くの言語 : 6.5～7

PHP : 5
Dart : 4.4

PHP, Dart は、コンピューターサイエンスを勉強していない高卒用言語

フレームワークは、
Ruby on Rails : 9 万ドル
Django : 6
Laravel : 3.8

YouTube で有名な雑食系エンジニア・KENTA が言ってる。
初心者のキャリアパスは、Rails → Go のみ

Ruby/Goの神・HashiCorp のMitchell Hashimoto がそう。
Ruby製のVagrant → Go製のTerraform。
今は、Goプログラマーしか求めていない

PHP, Scala はKENTAがオワコン認定したので、絶対にやってはいけない言語です！

**デフォルトの名無しさん** · 2024/01/17(水) 20:06:14.83

なるほど尊師様がおっしゃるのなら間違いないw

**デフォルトの名無しさん** · 2024/01/19(金) 05:11:59.56

地雷原を歩かせるスパルタ…！

**デフォルトの名無しさん** · 2024/01/28(日) 11:18:59.19

Goしか勝たん

**デフォルトの名無しさん** · 2024/02/07(水) 17:22:45.49

Googleがプログラミング言語「Rust」に100万米ドルを助成
「C++」との併存・置き換えを図る
https://forest.watch.impress.co.jp/docs/news/1566662.html

**デフォルトの名無しさん** · 2024/02/07(水) 17:32:10.04

スレ違い

**デフォルトの名無しさん** · 2024/02/13(火) 21:58:15.14

.22 のmuxのパラメタさぁ

**デフォルトの名無しさん** · 2024/02/14(水) 13:09:52.21

mux使ってないけど、なんかあったん？

**749** · 2024/02/14(水) 20:05:40.85

米国年収でも、Rubyは、Go/Rust/Elixir の3大言語を超えた！

2022 -> 2023

Ruby : 9.3 -> 9.9 万ドル
Elixir : 9.3 -> 9.6
Go : 8.9 -> 9.3
Rust : 8.7 -> 8.7

多くの言語 : 6.5～7 -> 7.3～7.8

PHP : 5 -> 5.9
Dart : 4.4 -> 5.6

**デフォルトの名無しさん** · 2024/04/03(水) 16:01:02.02

>>753
GoogleはGoにしたいのか、Rustにしたいのか

**デフォルトの名無しさん** · 2024/04/03(水) 16:23:26.97

したいって現状用途が全然違うのに

**デフォルトの名無しさん** · 2024/04/03(水) 16:40:24.82

>>759
確かに現状用途が異なる。GoがWeb、Rustがシステム記述
しかし、本来はGoもRustと同じところを狙っていたのではないかと

**デフォルトの名無しさん** · 2024/04/03(水) 16:51:21.63

goとrustじゃあ全然言語機能違いすぎるよ
goは言語自体くそシンプルでだからバックエンドのマイクロサービスみたいな
小さなサービス自体を実装するのに使われてる(用途)
goでそれ以上のことをやると死にかけると思う

GoとRustはC#とJavaみたいなにたもんじゃないと思う

**デフォルトの名無しさん** · 2024/04/03(水) 17:00:55.33

逆にRustでバックエンドのWebサービス実装する
フレームワークあるけどコンパイル時間長すぎて
Webとか時間の流れ速い分野ではこれはこれで地獄だし

GoとRustは色々比較して別物だからな
用途も現状すみわけられてると思う

**デフォルトの名無しさん** · 2024/04/03(水) 17:16:01.43

本来についてはどうなんだろうね
Goはシステム記述を最初から狙ってたの?
システム記述がどこを指すのかにもよるけど

**デフォルトの名無しさん** · 2024/04/03(水) 17:37:49.09

でも実際GoogleはGoで書かれたものもRustに移行してる
生産性は同程度だけど不具合の数が圧倒的に少なくなったらしくかなり前向きっぽい

**デフォルトの名無しさん** · 2024/04/03(水) 19:14:38.98

RustはC/C++の代替言語なわけで結局メモリ管理のための記述が必要な低級言語なんだよ～
ガベージコレクションの無い低級言語なんか触りたくないぽよぉ～、Goしか勝たん！

**デフォルトの名無しさん** · 2024/04/03(水) 19:19:11.96

シンプルな言語機能でコードの保守性を高めることがGo言語の目的で、それはRustと真逆のような

**デフォルトの名無しさん** · 2024/04/03(水) 19:21:07.80

Rustが人気な理由は
完全にメモリ自動解放しかも必ず安全
を実現しつつC言語と同等の速さで動く点

**デフォルトの名無しさん** · 2024/04/04(木) 22:12:02.80

つかメモリ管理が～とか中級者まででしょ
普通の頭があれば25歳までに卒業してるわ

**デフォルトの名無しさん** · 2024/04/04(木) 23:05:06.38

javaがウケたのもcがウケたのも
シンプルだったからなんやろねえ
実際のプログラミングってのはどうしたってクソみたいな
状態の山、依存の山みたいなもんに取り組んでいくわけで
余計な複雑さを持ち込まないでほしいってのは現場のリアルな声だと思う

もちろんgoも、それをわかってて、それを押さえてる

**デフォルトの名無しさん** · 2024/04/04(木) 23:26:31.09

>>769
Cが受けたのは他が糞だったから。勿論Cの完成度は超高いにしても。
あとその当時はCPUが非力すぎて軽くないと話にならなかった。
Javaが受けたのはCで鬼門だったポインタを廃止してGCも導入し、馬鹿でもバグが出にくくなったから。
その後スクリプト言語が受けてるのは富豪プログラミングの方が断然楽だから。
ただ効率を考えたらポインタを直接扱える方が断然有利なので、Goは簡単な範囲でポインタを使える言語の位置づけだと思う。

**デフォルトの名無しさん** · 2024/04/04(木) 23:40:17.98

ただしJavaは敷居を下げすぎて業界にバカが多数流入した
ポインタを取り扱える/扱えないがハードルとして機能していた
Go関係ない話ですまん

**デフォルトの名無しさん** · 2024/04/05(金) 00:59:31.65

>>762
初老のおっさんのyoutubeで見たけど
actix-web使ったプロジェクトのビルドに10分位掛かってた。
もうちょっと頭使って環境作ればいいのに

ちなワシの環境なら10秒程度

**デフォルトの名無しさん** · 2024/04/27(土) 20:42:50.26

こんばんは

Goってネームバリューあるけどそんなに盛り上がってる感じじゃないよね
javaの後継になるかと思ってたけどそうでもないし

**デフォルトの名無しさん** · 2024/04/27(土) 21:13:07.86

言語仕様が簡素な点が特徴だけど
Javaのような大規模開発には向いてないかな
ガベージコレクションがあるからC/C++の分野も不向き
守備範囲が意外に狭い

**デフォルトの名無しさん** · 2024/04/27(土) 23:58:02.43

Goはもう衰退傾向に入った

**デフォルトの名無しさん** · 2024/04/28(日) 10:43:50.01

>>774
Javaが大規模開発に向いてるのは「文化」であって、「言語機能」ではないだろ
Goで技術的に出来ない事はない。ただしやる意味もないが
Goが糞なのは「全部書け」という言語ポリシーだが、これはJavaも同じだし

>>773
Javaの代わりにGo使うメリットってポインタが使える事くらいか？
ならJavaの連中はポインタが使えない(使わなくて済む)からJavaに行ったのだから、
> javaの後継になるか
これ自体が間違いだな

ただまあ、GC付きCの需要は以前からあったし、この分野ではそこそこ生き残り続けるのでは？

**デフォルトの名無しさん** · 2024/04/28(日) 10:57:35.16

javaの代わりにGo使うメリットってネイティブコード吐き出すことだと思うけど
処理速度が早くなればそれだけマシンのリソースが少なくて済む

**デフォルトの名無しさん** · 2024/04/28(日) 11:46:19.27

>>777
ああその点は完全に失念してた。
ただなんつーか、今時鯖代より人件費の方が高いので、Web鯖なんて物理で殴る方が安いというソリューションになってしまってる。
Javaも同様の状況だと思う。
Webに比べて製品寿命は長いので、状況異なるかもしれんが。

処理速度が絶対的に必要なのは物理で殴って逃げられないケースで、
これは例えばディスコードやFPS等のゲーム、つまりユーザー間でのデータのやりとりが大量にある状況で収容数を増やしたい場合で、
現在はRust/C++ということになっている。この分野でJavaを選択する奴は居ない。

Javaが使われてるのは大概インフラ、つまり銀行の送金システムや自治体の戸籍管理等だが、
負荷がかかって物理で殴って逃げられないのはDBであってJava記述部分ではないので、
最大でも精々2倍程度にしか速くならない現状で、Goに書き直す事はない。
それよりも書き直す際のバグを嫌うはず。

つまり、Rustが存在せず、鯖代が今の10倍くらい高ければ、JavaをGoに書き直す需要は発生してたはずだが、そうではなかった、ということ。

**デフォルトの名無しさん** · 2024/04/28(日) 13:33:28.92

3行で

**デフォルトの名無しさん** · 2024/04/28(日) 13:57:24.88

> Javaの連中はポインタが使えない(使わなくて済む)からJavaに行ったのだから、

アマチュアさんからはそう見えるんだね
職業マにとって言語なんて案件次第なんよ

**デフォルトの名無しさん** · 2024/04/28(日) 14:28:40.83

>>779
速度面も機能面も、GoはJavaの後継ではない

>>780
ゆとり乙

顧客次第というのなら、現時点でのJava案件は今後ともJava案件だろうよ
顧客は公務員かお堅いところで、「もし何かあったら誰が責任を取る？」しか考えない連中だから
C++しかなかった時代ならともなく、現時点でJavaを「安全」とする技術的意味はないが、
顧客はそれを理解出来ず、また、責任逃れの為に誰も先陣を切らない
ただオラクルが妙な動きを見せ始めてるから、その辺どうなるかだが、それでも公務員連中は金払って終わりだろうよ
所詮は税金であって、自分の金ではないから
そういえば三菱銀行は10-15年前にC++で書きました、Haskell使いました、とかやってたが、続報は聞かないね

**デフォルトの名無しさん** · 2024/04/28(日) 14:52:46.56

素人ならではの発想ほほえましい

**デフォルトの名無しさん** · 2024/04/28(日) 15:24:23.74

しょうもないマウント合戦

**デフォルトの名無しさん** · 2024/04/28(日) 15:26:16.67

>>782
ゆとり引きニート乙

>>773
一応捕捉しておくと、773がGoを「速いJava」と『個人的に』考えたのは間違いではない。
ただし『言語として』なら完全に間違いだ。

Javaはビルジョイが「Cでのバグの大半はポインタがらみで、ポインタ使用ケースの9割がStringだった。
だからStringを言語がサポートすればポインタをなくせると考えたんだ」とリーナスに語ったとおり、
ポインタを無くしてバグを減らす為の言語として作られてる。
そして実際、大受けして天下を取った。(なお「大半」と「9割」は逆だったかも)

ただ、速度チューンにはポインタでの効率化が必須で、この意味でGoは「速いJava」として『個人レベルでは』使える。
ただしJavaにはそもそもポインタがないのだから、
この発想、つまり「ポインタを使えば速くなる」とはJava使いは考えないし、実際、出来ない。
(個人レベルなら出来るのは混ざってるだろうが、Java流の開発方針だとチーム全員が出来ないと意味がなく、機能しない。
そしてポインタにまつわる問題をデタラメに吹聴してる震源はJava使いであって、具体的に言えば「メモリリークガー」だが、
C使いがメモリリークに悩まされる事はない。それはCの使い方を知らない馬鹿がデタラメやってて勝手にバグってるだけ。
この意味で ID:vlvoJs2w は正しい事を言ってる。なお俺は ID:Chhm4gg1)

**デフォルトの名無しさん** · 2024/04/28(日) 15:55:49.27

そのようにC/C++を自分は使いこなせると思い込んでいる多くの人たちによってセキュリティホールが生み出し続けられている
結局C/C++を使用禁止にするしか解決策はない
アメリカでは政府レベルで決断して声明を出したので日本も後を追うだろう

「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

**デフォルトの名無しさん** · 2024/04/28(日) 18:01:20.89

AIによるコンパイラによってC/C++は復活する、コンパイル時にメモリ安全がAIによって保障されるのだ
さらにAIコンパイラがはくエラー＆提案によって誰もがC/C++マスターとなる
つまりRustの人間にメモリ安全を強制する構文ルールは瞬く間に錆ついてしまうのさｗ

もちろんAIの恩恵はガベージコレクションにも及びGo、Pythonなどの実行速度も劇的に上がる
つまりRustはすぐに錆びついてしまうのさｗ　AIという母なる海によってね

**デフォルトの名無しさん** · 2024/04/28(日) 18:22:25.79

めちゃくちゃ頭の悪い妄想だな

**デフォルトの名無しさん** · 2024/04/28(日) 18:41:43.21

>>785
そう思う人がC/C++を使わなければ済むだけ。

> そのようにC/C++を自分は使いこなせると思い込んでいる多くの人たちによって
なお、これはただのコンプレックスで、
ポインタの概念を理解すら出来ない馬鹿はお引き取り下さいではあるが、
ポインタを理解できたがリークするのは、やり方を知らないだけ。
(そしてここはGoスレであり原則後者だから、前者は死ねでいい)

ただ問題は、Javaの連中が「メモリリークガー」とデタラメに吹聴してるのに騙され、
文法にて縛ってしまうRustに逃げてしまってる事。まあ初心者は文法しか見えないから致し方ないが、
実は定番の手法があり、踏襲すれば絶対にリークしないだけ。
賢いからリークしないわけではなく、知ってるか知らないか、守るか守らないか、でしかない。
そしてRustは実際はC->C++->Rustと来ないと意味もメリットも理解出来ず、
「RustのおかげでCを入門する奴が増え、現在RustよりCの入門者の方が多いじゃねえか！」とか2019頃に言われてた気が。
RustはCを駆逐したいようだが、間抜けな話だ。

そして、Javaが「安全」とされていたのは、
・ポインタにまつわる問題が無い
・配列の境界チェックあり　(←これGoはどうだったっけ？忘れた)
・GCありなのでリークしない
・サンドボックス
だと思ったから、技術的に見れば確かにGoはJava＋ポインタ＝高速版Javaとしての側面はあるのだろうよ。
ただ、マーケティング的に(781)、また技術者リソース的に(784)、当面は無いが。

この意味では俺はRustの方が詰んでると思うよ。AIで出来るとは思って無いが、(>>786)
・動的な境界チェックをやってる限り、Cの速度に勝てない
・静的な境界チェックが出来るようになれば、C++にも導入されるだけ
で、出口が無い。
そして意味もなくマウントを取って来た780が言う様に、現在のJavaプログラマはポインタを扱えるのなら、
Java->Goへの大移動は起きるのかもしれんよ。この意味ではRustよりGoの方がワンチャンある。
(けどまあ、普段やってないことがいきなり出来るわけも無く、ゆとり引きニートの言い分なんてお察し、だが)

**デフォルトの名無しさん** · 2024/04/28(日) 20:18:11.49

童貞が女の口説き方教えてくれてるような長文

**デフォルトの名無しさん** · 2024/04/28(日) 21:47:54.49

例え方がキモすぎる

**デフォルトの名無しさん** · 2024/04/28(日) 23:14:08.57

そんな心配しなくてもAIが進化すればGOもC/C++もRustもなくなって別の高級言語が生まれるよ、もう会話してればプログラムができちゃうような感じになる

**デフォルトの名無しさん** · 2024/04/28(日) 23:51:58.46

>>788
配列の境界チェックは任意に与えられたインデックス値に対してはC言語であろうとなかろうと境界チェック必須
一方で配列の内部であると確認されているなら不要(にすることができる)

例えば配列の内部であると確認されているならその配列内部へのポインタとして持ってしまえば
読み書きアクセスのたびに境界チェックは不要となる

よく使われる配列の全体もしくは一部分の範囲を順にシーケンシャルアクセスする場合もポインタにすれば境界チェックを不要にできる
なぜならその範囲の終端条件に達するまでは内部であると確認されてるため個別の境界チェックは不要

RustがC/C++と同じ速さで動くのもこの原理のため

**デフォルトの名無しさん** · 2024/04/29(月) 00:43:52.99

>>792
言ってる事は知ってるが、そうではなく、

> 任意に与えられたインデックス値に対して
の時に実際どうしてるか聞いてる。

C言語の場合は、境界チェックして無い。
Rustの場合はするらしい。だからこの部分でどうしてもCより遅くなる。
Javaは勿論やってる。だから馬鹿が書いて添字範囲をオーバーしたら、例外が返されたはず。
Goはどうだったっけ？という事。

で、Javaが792の手法でゴリゴリに高速化し、C比3倍遅かったのが1.8倍程度まで盛り返したのも知ってる。
そしてC#の方はJavaが6,7で留まってた際にも言語自体が進化してたので、高速化がまだJava程には至ってない。

あと、ついでに言うと、（別人かもしれんが)
> セキュリティホールが生み出し続けられている
> 結局C/C++を使用禁止にするしか解決策はない
これも間違いで、C/C++の場合は788に書いたとおり、
・（プログラマの技量により)バグを生みやすい
・ベアメタルなので問題があった場合に直撃する
だが、アプリとしてはバグが無い（上記上側がクリアされてる)、という前提なら、RustはC/C++と比べて安全ではなく、同程度でしかない。
セキュリティホールは設計上のバグだから、言語関係なく発生する。
(だからLinuxをRustで書きなおそうという馬鹿は居ないし、居てもポシャる。
そういえば10-15年程前はLinuxをC++で書き直そう、という連中が居たはずだが、消息聞かないところを見ると、完全にポシャったようだし)
ただ、Javaの場合はセキュリティホールを突いてもVMだから、さらにVMのセキュリティホールを突く必要があり、この意味では安全。
Goの場合はランタイムだから、VM程ではないにしても、ベアメタルよりはまし。ランタイムの実装によっては、VMと同等の堅牢さも確保できる。

ただ、言っちゃ悪いが、Rustの連中がやたら布教に熱心なのは、所詮はその程度の言語なんだと思うよ。
JavaScriptなんて悪口しか聞かないが、蔓延る一方だろ。プログラマに支持されてる言語はこうなるという例だよ。
Rustは精々ポリコレがんばってください。俺はRustは死ぬと予想してるし、そう望んでます。

**デフォルトの名無しさん** · 2024/04/29(月) 01:08:13.38

>>793
配列の境界チェックをしなければどんな言語でも範囲外アクセスで続行となり致命的な穴となります
だからC/C++以外はどんな言語でも境界チェックが行われています
C/C++でも自分で境界チェックを行わなければ致命的な穴となります
したがってそこで速度差は生じません

**デフォルトの名無しさん** · 2024/04/29(月) 05:43:48.04

なんかスレが進んどる。半分は読んでない。
けど大規模開発になると些細なパフォーマンスは関係なくなることには同意した。
それを差し引いても自分はGoが好き。

**デフォルトの名無しさん** · 2024/04/29(月) 08:46:16.16

>>794
Cで境界チェックしてる奴なんて、世界中でも誰もいない。
境界オーバーは純粋にバグであり、プログラマの責任でデバッグしておけ、というのがCの文化。
そしてずっとそうやって来てる。

だから動的に境界チェックをしてる限り、RustはCよりも原理的に遅く、実際そう。
この意味ではRustは補助輪付きCであり、補助輪の分だけ遅い。
Rust＝馬鹿向けC、といえば分かりやすいか。
そして、C/C++でなんら問題なかった連中からすると、
Rust？記述がウザくなるがリークがなくなって境界チェックしてくれる？
いやリークなんて元々しないし、デバッグもちゃんとやってるから間に合ってるよ、であり、
何もメリットが無いからRustなんて使わない。

**デフォルトの名無しさん** · 2024/04/29(月) 08:47:08.70

とはいえ数は力である。
Cの場合は「リークや境界オーバーするような馬鹿がコード書くな」であり、
コードを募る場合は中～上級者だけに対象を絞る大前提だが、

**デフォルトの名無しさん** · 2024/04/29(月) 08:47:32.78

Rustの場合は「文法に従ってさえすればリークは防げます、境界オーバーは動的チェックしてます」らしいので、
大多数の馬鹿からもコードを募れる。これが今の時代には向いているのも確か。

ただ、馬鹿向けCなら、Goの方が上だと思うよ。境界チェックしてたかは忘れたけど。

**デフォルトの名無しさん** · 2024/04/29(月) 09:45:04.56

>>798
Goももちろん正しく配列境界チェックをしていてindex out of rangeのランタイムエラーが出るよ
Cだけが基本的なこともできない古い失格言語で範囲外をアクセスしてしまう

**デフォルトの名無しさん** · 2024/04/29(月) 11:03:19.56

>>799
なら馬鹿向けCはやはりGoで決まりだな。

そして、「僕は馬鹿だから補助輪ください」か、
「俺はちゃんとデバッグするから補助輪なんてイラネエ、100%の速さをくれ」か選べる。
それでいいのでは。
(というかこの辺グダってるのはRustだけで、Go使う連中は最初から100%の速度なんて求めてない。
Rustが原理的にCより遅いのは回避しようも無い事実なのに、嘘ぶいてるからおかしなことになる。
そしてこの手のことを「選択肢を絞り、政治的に解決する」のがパヨクの常套手段で、典型的には>>785
パヨってるRustは当然嫌われてるだけ)

ただまあ、もう一度整理すると、Goは
・ポインタにまつわる問題はそれなりに対策されてる
・配列の境界チェックあり
・GCあり
・ランタイム
だから、経緯とか界隈の文化とか技術者の状況を無視して、単に純粋に言語の技術的側面だけを見ると、Goは
> javaの後継 (>>773)
は言えてるのかもしれんね。
そういえばJavaは「元祖馬鹿向けC」、Goは「２代目馬鹿向けC」と言われてたし、自然な発想なのかも。
ただ「安全」に関しては、一度保険をかけたら二度と戻れないものだから、Javaの連中がGoを「安全」と見なす事はなかなか無いとも思うが。
(ランタイムエラーを吐いてくれる環境で動いているソフトは、
ランタイムエラーで誤魔化せてるから動いているのか、
そもそもバグが無いからランタイムエラーは絶対にないのか、区別付かない。
だから、ランタイムエラーがある環境でどれだけ動かした実績があっても、『保険』をはずしてベアメタルに持って行くことは出来ない)

**デフォルトの名無しさん** · 2024/04/29(月) 11:07:50.34

Cと違ってGoは賢い

str := "01234"
a := []byte(str)

fmt.Println(a[3]) // → 51 (3のascii code)
fmt.Println(a[3:5]) // → [51 52] (3と4のascii code)
fmt.Println(a[3:7]) // → [51 52 0 0] (範囲外の値は0になる)
fmt.Println(a[3:9]) // → panic: runtime error: slice bounds out of range [:9] with capacity 8

**デフォルトの名無しさん** · 2024/04/29(月) 11:37:52.73

>>801
> fmt.Println(a[3:7]) // → [51 52 0 0] (範囲外の値は0になる)
これはランタイムエラーのほうがいいのでは？

**デフォルトの名無しさん** · 2024/04/29(月) 12:54:08.59

キータにでも行ってくれ

**デフォルトの名無しさん** · 2024/04/30(火) 23:59:10.31

>>802
なぜ？