次世代言語25 TypeScript Swift Go Kotlin Rust Nim

**デフォルトの名無しさん** · 2022/04/17(日) 17:52:35.38

スレタイ（順番はRedMonk準拠）以外の言語もok

前スレ
次世代言語24 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1647887021/

**デフォルトの名無しさん** · 2022/04/18(月) 05:38:14.77

go とrust が合体した言語があったらいいのに

**デフォルトの名無しさん** · 2022/04/18(月) 06:25:23.07

>>11
vlang

**デフォルトの名無しさん** · 2022/04/18(月) 07:03:56.62

絵に描いた餅を出されても

**デフォルトの名無しさん** · 2022/04/18(月) 07:21:19.73

>>10
リークというかダングリングだけど、人が書いたメソッド中身見ないで使ってると参照切れてたり日常茶判事だよ

**デフォルトの名無しさん** · 2022/04/18(月) 07:25:53.68

>>10
そういう問題じゃないんだよ
スマートポインタ使わないで実装できてしまうことでこれまでどれたけの脆弱性をうんだか、という問題

**デフォルトの名無しさん** · 2022/04/18(月) 07:45:20.51

>>10
・スマートポインタを使い忘れてもコンパイルが通ってしまう
・スマートポインタを間違って使ってもコンパイルが通ってしまう
後者はC++ベテランでも複雑化するとうっかりミスがある
・そもそも毎回unique_ptr指定が面倒かつ無駄なのでデフォルト適用にして欲しい

**デフォルトの名無しさん** · 2022/04/18(月) 07:51:49.28

新しいプロダクトできました。メモリーリークはないです。
なんでいいきれるの？
Rustで、実装してるからです。
ああ、納得。

こんな感じで会話できるかどうかの差はものすごく大きい。

**デフォルトの名無しさん** · 2022/04/18(月) 07:52:22.78

>>11
go要素いらねえだろあんな糞文法
なんどGoogle潰してやろうと思ったか

**デフォルトの名無しさん** · 2022/04/18(月) 08:15:02.57

やはりRustが最強

JavaScript/TypeScriptの高速フォーマッター「Rome Formatter」リリース。Rust製でPrettierより約10倍高速と
https://www.publickey1.jp/blog/22/javascripttypescriptrome_formatterrustprettier10.html

**デフォルトの名無しさん** · 2022/04/18(月) 09:12:25.91

Rustの文法すごい好きだから、c#ぐらいのノリでかけて文法がRustっぽい式指向な言語が欲しい

**デフォルトの名無しさん** · 2022/04/18(月) 09:21:04.84

なんでもその言語はC#のノリで書けるらしい

Goやないかい！

GoはC#のノリで書けるんやから！

俺はなんでもオミトオシやねんから！

Goやそんなもんは！

**デフォルトの名無しさん** · 2022/04/18(月) 09:33:56.22

>>20
Rustの構文や標準メソッド等ほぼそのままに
所有権と借用ルールとライフタイムだけを削除というか無視して処理するGC言語『GC-Rust』を作るとよいかもね
プログラミング初心者入門用にもなるし速さ省メモリを必要としない場でも使えるような
多少遅くてもいいのだからインタプリタ型でも十分かもね
あとは所有権参照借用lifetimeだけ学べば本物のRustへすぐに進める

**デフォルトの名無しさん** · 2022/04/18(月) 09:43:43.33

>>19
ツール系はいくつかrust製があるね。
ripgrepもなかなか良いよ。

**デフォルトの名無しさん** · 2022/04/18(月) 09:46:35.13

>>22
あーそんな感じだな
GC付きのRust欲しいわ

**デフォルトの名無しさん** · 2022/04/18(月) 10:29:24.32

Rcじゃだめなの？

**デフォルトの名無しさん** · 2022/04/18(月) 11:06:57.46

もう調べてるかもしれないけどもっと現実的な話で式志向がいいならF#どうっすか

**デフォルトの名無しさん** · 2022/04/18(月) 11:23:46.03

>>14,15,16
スマートポインタを使い忘れるってことはmake_sharedかmake_unique使わないでnew使ってるってことだからgrepすれば簡単に見つけられる。全ての関数の引数の型とクラスメンバの型に生ポインタが無いようにすれば間違った使い方をして生ポインタがでてきてもコンパイルエラーなる。（もしそれらに生ポインタがあっても正規表現使えば見つけられるだろうし）

**デフォルトの名無しさん** · 2022/04/18(月) 11:32:19.66

>>27
そんな面倒なことをせずとも無指定でunique_ptr相当になるRustを使った方が楽でいいな
Rustなら他にも忘れたり間違えたりすればコンパイラがエラーとして詳しく指摘してくれるし

**デフォルトの名無しさん** · 2022/04/18(月) 11:45:09.21

>>18
アリが象を潰すつもりですか？

**デフォルトの名無しさん** · 2022/04/18(月) 11:47:49.11

>>27
ある瞬間自分の書いたコードだけチェックできればいいってならその通りだとは思う
ただ実際には依存ライブラリや他の人が入れてくるコード全てを常時チェックし続けないといけなくなるし
もし依存ライブラリがnew使ってたとして毎回フォークして書き直すのか？という問題もある

**デフォルトの名無しさん** · 2022/04/18(月) 12:03:53.59

巷に出没するRust信者自分でRustまともに書いてない説を提唱したい

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

そうなるとRustを広めたい勢力に雇われてる工作員の可能性出てきちゃう

**デフォルトの名無しさん** · 2022/04/18(月) 12:27:52.69

>>28
引数渡しがデフォルトmoveじゃなければよかったんだかな。
デフォルトconst 参照で組まれていたらずいぶん学習しやすくなったと思う。

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

所有権のmoveセマンティクスらへんがRustの最大の文法的特徴なのに、そこがいらんとな
最初からKotlinとか使ってればええやんか

**デフォルトの名無しさん** · 2022/04/18(月) 12:42:20.62

>>34
C++以外のユーザーがRustを学習するときの一番の難所でもあるけどな。

実際、不変借用は頻出しそうな気がするけど、性能ペナルティーとかあるのかね？

**デフォルトの名無しさん** · 2022/04/18(月) 12:52:02.32

rustはインストール先がユーザーホームディレクトリの下なのが何だかな。
マルチユーザーで使う場合が手間かかる。

**デフォルトの名無しさん** · 2022/04/18(月) 13:04:30.11

>>33
それはおかしい
一般的に参照を引き渡すということは様々な問題を生じさせるということ
競合の種も産むし参照切れの種も産む
だから参照を引き渡す方が記述コストを増やすことこそ道理
次に
C言語でもポインタ参照渡しは＆を付けて表記する
したがって無印よりも＆前置こそ参照渡しに相応しい

**デフォルトの名無しさん** · 2022/04/18(月) 13:08:07.19

>>30
これ。
見つけたからってどう住んだよ？って話だよな
他社のコードを修正できないし、そもそもそんなチェックを未来永劫担当者に引き継いでいけるのか？ってこと
個人でできることと、組織やプロダクト関係者全体としてできることは違う

**デフォルトの名無しさん** · 2022/04/18(月) 13:33:30.85

>>30,38
そんなこと言ったら、Rustでも他人の書いたコードにunsafeが入ってる可能性もあるでしょ。

>>33
Nim言語だとデフォルトで不変コピー渡しだけど引数のサイズが一定サイズ以上（確かポインタサイズの3か4倍以上）だとポインタで渡すようなコードを生成するんだよね。

>>37
Rustは参照を使ったときの問題が起きないようにコンパイル時にチェックしているんだからデフォルトがconst参照渡しでも問題ないんじゃないの?

Rustって借用したり借用を参照するときに&や*をつけないといけないけどその結果コードの見た目が生ポインタを使ってるCのコードに似てるんだよね。暗黙に借用したり参照しちゃダメって考えでそうなってるんだと思うけど。

**デフォルトの名無しさん** · 2022/04/18(月) 13:42:31.54

>>17
メモリリークは防げないでしょ

**デフォルトの名無しさん** · 2022/04/18(月) 13:51:24.45

>>39
＞Nim言語だとデフォルトで不変コピー渡しだけど
＞引数のサイズが一定サイズ以上だとポインタで渡すようなコードを生成するんだよね。

この議論でそんな話を持ち出す時点であなたは以下の理解が足りない
一般的にプログラミング言語によるセマンティクスと最終的に生成されるコードは全く無関係でありそこに関連があってはいけない独立のものである
完全に独立したものであるが故に最終コード生成オプティマイズを十分にすることが可能となる

**デフォルトの名無しさん** · 2022/04/18(月) 14:04:44.92

>>40
そうですね。スミマセン

**デフォルトの名無しさん** · 2022/04/18(月) 14:09:14.47

やべーアスペおるな

**デフォルトの名無しさん** · 2022/04/18(月) 14:11:19.47

プログラミングを勉強しようと思って
なにを勉強すればいいか先生に聞いたらパイソンっていうから
検索したら大きな蛇の画像とかがでてきたのでやめたわｗ

**デフォルトの名無しさん** · 2022/04/18(月) 14:29:04.41

生成されるコードがプログラミング言語のセマンティクスと無関係じゃだめでしょ。
コード生成はプログラミング言語のセマンティクスと矛盾しない範囲内で生成しないといけない。コンパイラはその中で最適なコードを生成しようとするわけでしょ。
Nimではデフォルトで引数はプロシージャ内で変更不可(変更しようとしたらコンパイルエラー)だから引数の型のサイズに併せて生成するコードをコピー渡しにしたりポインタ渡しにできるわけで。
もし引数が可変参照渡しだと引数の型が1バイトでもコピー渡しでは無くポインタ渡しにしないといけない。関数がインライン展開されると話が違ってくるけど。

**デフォルトの名無しさん** · 2022/04/18(月) 14:44:43.88

>>44
あ、すまん。これ誤爆しました。スミマセン～。

**デフォルトの名無しさん** · 2022/04/18(月) 14:49:14.45

「プログラミング言語によるセマンティクスと最終的に生成されるコードは全く無関係」そんな訳ない、RustはLLVMのIRを前提に
コードが吐かれるし、コードのリンケージをアトリビュート指定できる。C言語だって同様だし、むしろ、ハードウェアよりの低レベルな
システムプログラミングが可能な言語であれば、生成されるバイナリが厳密に言語の「セマンティック」を決める。
例えば今どきのCPUには分岐予測命令があるが、これに対応するstd::intrinsics::likelyのような分岐予測にヒントを与える、
セマンティクスはCPUがサポートされていれば100%生成されるバイナリがそうなる事を望む。無関係などありえない

**デフォルトの名無しさん** · 2022/04/18(月) 14:53:46.39

>>47
Rustをgccと組み合わせて動かす試みあるから
LLVM前提ではないのでは？

**デフォルトの名無しさん** · 2022/04/18(月) 14:57:34.06

>>45
その言語のセマンティクスとしてimmutableで渡すケースでも
値をポインタで渡すか値自体を渡すかはどちらでも構わないから言語のセマンティクスとは別問題

もっと顕著にわかりやすい例
構造体を一つ返す関数があったとする
小さい構造体なら値を返すだろうが
大きな構造体なら領域を用意してそこに書き込んでそのポインタを返すかもしれない
あるいは関数を呼ぶ側が領域を用意してそのポインタを裏引数として渡してそこへ返す値を書き込むかもしれない
このように3種類考えられるが呼ぶ側と呼ばれる側で一貫していれば目的を果たす
プログラマーはその生成コードが3種類のどれになるかを把握する必要はない
つまりそこで明白にレイヤーが分離される

**デフォルトの名無しさん** · 2022/04/18(月) 14:59:44.25

>>33
もし文字列のベクタに文字列を追加する関数があったとき文字列が参照渡しでその関数が実行された後もその文字列が読まれていると、その関数は文字列をmoveすることができずコピーしなくてはならなくなるからじゃないかな。
メモリコピーは遅いから絶対に許さない人にはデフォルトがmoveのほうがいいのかも。

**デフォルトの名無しさん** · 2022/04/18(月) 15:02:16.44

>>48
現状はIR前提でしょ、完成してない未来のものを持ち出すのであれば何とでもいえる。というか上で言ってる本題とはずれる
そんなところに食いついて来てしょーもないわ

**デフォルトの名無しさん** · 2022/04/18(月) 15:06:33.88

>>47
Rustでもセマンティクスと生成コードは独立だよ
例えば>>49の関数が構造体を返す例
生成コードは言語仕様で定められていないしあなたも方法を答えられないでしょう
実際にRustで大きな構造体を返すと所有権を活用して驚きの最適化したコードを生成するよ

**デフォルトの名無しさん** · 2022/04/18(月) 15:10:05.22

>>51
開発中で完成してないとは言っても実行バイナリの
生成もできないという状態ではないから
あなたの話とは違うというか
あなたの主張は間違ってるという例になってますよね

**デフォルトの名無しさん** · 2022/04/18(月) 15:19:05.87

>>52
「生成コードは言語仕様で定められていないしあなたも方法を答えられないでしょう」
え？RustにもちゃんとFFIなどextern "C" {}ブロックがあるでしょ？生成コードは言語仕様で定められているし、このようなデータの受け渡しは
参照や可変参照の制限、ボローチェックなどがOFFになる。C言語やD言語やNimも同様でしょ、これが出来ない言語はシステムプランニングが
できる言語とは言えない。
「Rustで大きな構造体を返すと所有権を活用して驚きの最適化したコード」
どのような驚きのバイナリを生成しようと、例えばゲームエンジンのUnityなどでデータを渡す場合に所有権をRust側で保持したままのような
コードではUnityなどでメモリー管理されるので問題が出る。だから呼び出し間でどのようにデータを受け渡すか当然指定できる

**デフォルトの名無しさん** · 2022/04/18(月) 15:20:54.20

>>53
何を言いたいのか1つも分かりません。。。あなたの勝ちでゴリラのようにマウンティングをしてください、どうぞ

**デフォルトの名無しさん** · 2022/04/18(月) 15:33:12.79

>>54
FFIを理解していないアホですか？
例えばそのextern "C"した時のみC言語の受け渡しインタフェースに従うだけ
どの言語でもFFI使わなければ各言語が自由自在の方法を取る

**デフォルトの名無しさん** · 2022/04/18(月) 15:38:01.47

>>39
引数のサイズが一定サイズ以上だとポインタで渡す

それはそれで他者が変更したときの挙動が変わるから怖いよね。
特に並列作業時。

>>50
const参照をデフォルトにしたら、そのあたりは引き渡し時にmoveを明記するんだろうね。あるいはCOWで実装するか。

もしかしたらRustに「権利を持つオーナーは極力少なく・小さくする」というポリシーでもあるのかな？

**デフォルトの名無しさん** · 2022/04/18(月) 15:47:16.94

>>56
さっきからID変えて絡んでこなくてよいですよ、「extern "C"した時のみC言語の受け渡しインタフェースに従う」セマンティクスと生成コードが決まりますよね。
アホと言えば誰もしもが感情的になるわけではないです。FFI使わなければなんて話をしていませんし、「プログラミング言語によるセマンティクスと最終的に
生成されるコードは全く無関係」という理想論のような現実を知らないコンピューターサイエンス学科の学生のような言葉を否定してるだけです。

**デフォルトの名無しさん** · 2022/04/18(月) 15:50:35.11

>>57
デフォルトで引数は不変が前提なので引数の型の定義を変更してポインタ渡しになったとしても基本的には挙動は変化しない。
引数のアドレスをとってれば挙動が変化するかもしれないけど、Nim言語は明示的に変数のアドレスをとることは危険な行為で自己責任でやれってことになってるから。

**デフォルトの名無しさん** · 2022/04/18(月) 16:01:25.50

>>58
普通のプログラムでC言語FFIなんて使わないです、そして、その特殊ケースはどうでもよい話です
一般的に言語が定めるセマンティクスと生成コードは別階層なので独立しています

**デフォルトの名無しさん** · 2022/04/18(月) 16:06:01.92

>>57
静的型付けで型サイズが定まる普通の言語ならば大丈夫
引数や返り値がポインタ渡しになるか値直接渡しになるか
型サイズ次第で変化しても一貫していれば構わない

**デフォルトの名無しさん** · 2022/04/18(月) 16:44:49.00

>>57
> それはそれで他者が変更したときの挙動が変わるから怖いよね。
> 特に並列作業時。
横レスだけど、明らかにそういう話じゃない

**デフォルトの名無しさん** · 2022/04/18(月) 17:00:59.75

普通にカーネルのシステムコールするだけでC言語のFFI使ってますよ、DBアクセスするにもSQLiteでもMySQLでもPostgresqlでも使用してますし
TCP/IPスタックにアクセスするにもFFI使ってます、もしや特殊なのはあなたなのでは？ガン無視されて独立しているのは、そんな詰まらないことで
言い張るあなたなのでは？

**デフォルトの名無しさん** · 2022/04/18(月) 17:04:14.33

Kotlinみたいな出力先がjvmとjsとネイティブがあるのは
このひとの中でどう解釈するんだろ

**デフォルトの名無しさん** · 2022/04/18(月) 17:15:12.72

>>63
そんなことは誰でも知っているがこの流れとは無関係な話
各FFIはそのFFIの指定に従う
逆に言えば各言語の普通のコードではFFIなんて関係ないので各言語で完全に自由
だから引き数や戻り値のサイズに拠ってポインタ渡しか否か変わる言語もある

プログラマーはそれらを知らなくてもプログラミングできる
各言語が定めるセマンティクスだけ理解すればプログラミングできる
つまりセマンティクスと生成コードは完全に独立した別階層であり無関係

**デフォルトの名無しさん** · 2022/04/18(月) 17:19:02.78

この話の終着点どこ？
「お前はアホだから黙れ」が立証できれば満足するの？

**デフォルトの名無しさん** · 2022/04/18(月) 17:22:10.87

>>33
変数の代入がmoveなのに関数引数の時だけ参照になるのは紛らわしくない？

**デフォルトの名無しさん** · 2022/04/18(月) 17:33:30.39

>>59
あ、不変前提ね。勘違いしてました。

>>67
変数もデフォルトで不変借用にする、とか。戻り値の受けが面倒臭くなりそうだけど。

**デフォルトの名無しさん** · 2022/04/18(月) 17:41:53.44

>>68
Cの(ポインタ)参照が前置＆だから
Rustの(借用)参照も前置＆にした現状仕様がわかりやすいと思うけど、なぜ変えたいの？

**デフォルトの名無しさん** · 2022/04/18(月) 17:58:50.26

>>68
変数の代入をデフォルトで参照にするとmutが絡んできたときにborrow checker周りでとてつもなく面倒になりそうな気がする

**デフォルトの名無しさん** · 2022/04/18(月) 21:11:14.78

rustはライフタイム周りが途方もなく汚く見える
ウンコに触れたくない

**デフォルトの名無しさん** · 2022/04/18(月) 21:16:17.21

Rust「エラーには回復可能なエラーと回復不可能なエラーがあってResult<T, E>を使って~(長文)」
エンジニア「TとEって何だよ」「"?"って何?」「Box<dyn Error>って何?」

Golang「ほぼ
if err != nil {
panic(err)
}
でいい」
エンジニア「そうだったのか！」「やっと理解できた！」「Goって美しい」

何も言い返せんかったは・・・

**デフォルトの名無しさん** · 2022/04/18(月) 21:19:09.66

twitterでイキってるバカをそんなに晒すなよ。

**デフォルトの名無しさん** · 2022/04/18(月) 21:22:52.28

なおイキッテルのはRUSTERのもよう
ＧＯに完全敗北してどんな気持ち？

**デフォルトの名無しさん** · 2022/04/18(月) 21:26:10.80

null安全じゃない言語とかこのご時世にあるんですね

**デフォルトの名無しさん** · 2022/04/18(月) 21:39:04.08

スレタイの言語でも
Goとかnilチェックするコードを書き忘れてもコンパイルエラー出ないね
安全じゃない言語多すぎ

**デフォルトの名無しさん** · 2022/04/18(月) 21:42:30.77

GOはポイント使わなければ安全だぞ
ただし初期値に０と””が入る

**デフォルトの名無しさん** · 2022/04/18(月) 22:25:39.31

>>77
このif文を書き忘れたらコンパイルエラーになるの？

>>72
> if err != nil {

**デフォルトの名無しさん** · 2022/04/18(月) 22:30:25.57

>>74
これってgoありがたがる人を馬鹿にしたツイートじゃないの？

**デフォルトの名無しさん** · 2022/04/18(月) 22:44:34.76

Goはnil安全ではない
if err != nil {を書き忘れたり
return nil, nilしちゃっていると死ぬ

nil以外にも存在しない時の値で死ぬ
例えばstring.Index()は未発見時に-1を返す
返り値が-1かどうかチェック忘れてもコンパイルエラーとならない
そのまま-1を使ってしまい実行時に死ぬ

いずれのケースもRustではコンパイルエラーとなるため安全
Goは危険だらけ

**デフォルトの名無しさん** · 2022/04/18(月) 22:55:48.31

分かりにくい人「円周率は3.141592...と無限に続く数字で、よく近似の3.14が使われます。」
視聴者「何で3桁なの？」「2の後は何なんだよ」「近似って何？」

分かりやすい人「円周率って色々言われてるけど、実は3なんです！」
視聴者「そうだったのか！」「やっと理解できた！」「数学って美しい」

https://twitter.com/zugaaanzubababa/status/1506569845693100035
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2022/04/18(月) 23:02:13.65

Goでは「値が存在しないこと」を安全に表す方法がないことが敗因
RustではOption<T>型のNoneで安全に表せるところ

**デフォルトの名無しさん** · 2022/04/19(火) 00:46:26.38

なおシェアはＧＯが圧勝したもよう
ＲＵＳＴボーイズは一生夢見て低賃金でこき使われる童貞野郎

**デフォルトの名無しさん** · 2022/04/19(火) 01:34:09.77

goはCがシンプルで使いやすいと思う人向けの言語じゃないかと思う

**デフォルトの名無しさん** · 2022/04/19(火) 01:36:19.32

言語機能をモリモリにしたい誘惑に抗ってランタイムを充実させるという判断できる自制心はすごいと思う

**デフォルトの名無しさん** · 2022/04/19(火) 01:53:00.90

Ruby 3.0 のJIT は、MJIT で、
Ruby VM のバイト(中間)コードを、C コードに変換してから、
Cコンパイラでネイティブコードに変換していた

Ruby 3.1 のJIT は、YJIT で、
バイトコードから直接ネイティブコードに変換する。
ただし、x86_64 のみに対応

条件分岐があっても、10回実行した分岐だけを変換する。
実行されない分岐は変換しない

遅延変換・Lazy Basic Block Versioning（LBBV）

これで、Rails のプロジェクトが、20% ほど速くなったらしい

**デフォルトの名無しさん** · 2022/04/19(火) 07:43:43.07

ゴミが20%早くなかったからってどうしたってゆうね

**デフォルトの名無しさん** · 2022/04/19(火) 07:46:59.67

>>81
今さらゆとり

**デフォルトの名無しさん** · 2022/04/19(火) 07:51:59.99

>>87
でもRuby on railsってまだまだ使われてるよね？
有名どころでも、クックパッド、Airbnb、Gunosy、クラウドワークス、
食べログ、価格.com、Twitter、 Hulu、 GitHub

**デフォルトの名無しさん** · 2022/04/19(火) 08:03:56.92

>>81
偽物を「実は」という詐欺師。

**デフォルトの名無しさん** · 2022/04/19(火) 09:17:26.14

>>89
大規模railsを別言語で書き直しましたという
ニュースは時々出てくるけど逆は聞かないからなあ…

**デフォルトの名無しさん** · 2022/04/19(火) 09:29:29.07

>>89
業界や会社によってはCOBOLだって使われてる。
いったんそれでシステム組んじまったら中々移行は出来んもんだよ。

**デフォルトの名無しさん** · 2022/04/19(火) 09:35:08.80

>>80 >>82
Goはなぜそんな危険な言語仕様にしたの？

**デフォルトの名無しさん** · 2022/04/19(火) 10:22:52.12

R○byは業界のSPA移行とPythonブームによって思いのほか綺麗に消えてくれたのは良かった
まあPHPなんかに比べたらまだ「恥を知る」人間が多かったんだろうね

**デフォルトの名無しさん** · 2022/04/19(火) 11:21:50.97

>>94
PHPユーザに失礼なやつだな

お前あれだろ？
刺し身に直接わさびを付けるタイプだろ。醤油でわさびをとかさないで刺し身につけて食べてね？どうよ？

**デフォルトの名無しさん** · 2022/04/19(火) 12:34:56.06

>>94
言語マニアならpythonよりRubyの方がマシだろ。Pythonみたいにメソッドと関数が混在するのは書いててキモい。
python4でNim方式を採用してほしいわ。

**デフォルトの名無しさん** · 2022/04/19(火) 12:39:13.85

もちろんプログラム記述方式としてはPythonは最悪
あれが普及するのは害悪しかない

**デフォルトの名無しさん** · 2022/04/19(火) 13:49:45.55

>>95
直接わさびを口に運び刺身を投入して咀嚼した後に醤油を飲むタイプです

PHPユーザに対し失礼な発言は謝罪して撤回させていただきます。この度は申し訳ございませんでした。

**デフォルトの名無しさん** · 2022/04/19(火) 14:55:17.88

インデントでスコープ区切るのあんまり好きじゃない

**デフォルトの名無しさん** · 2022/04/19(火) 16:35:48.82

Haskellもインデントでスコープを区切ってた気がするけど一応ブレースでくくることもできるんだっけ

**デフォルトの名無しさん** · 2022/04/19(火) 18:18:04.08

>>98
人類最底辺のゴミPHPoorに謝罪など必要ない
奴らに必要なのは死あるのみ

**デフォルトの名無しさん** · 2022/04/19(火) 18:22:33.15

PHP使う人ってなんであんなアヘアヘ君ばかりなの？昔からああなの？

**デフォルトの名無しさん** · 2022/04/19(火) 22:14:20.79

>>96
けっこう同意。

**デフォルトの名無しさん** · 2022/04/19(火) 22:34:55.70

>>102
障害者手帳持ちでも書けるとガイジを集めたから
ガイジが作ってガイジが保守して、真人間は近寄らないか万一深淵を覗いてもすぐに逃げるから
ガイジだけが残った
それがPoopHPoor

**デフォルトの名無しさん** · 2022/04/19(火) 22:35:00.77

言語の良し悪しと普及率はあんまり関係ないってことだな

**デフォルトの名無しさん** · 2022/04/19(火) 23:10:14.27

良し悪しは文法だけでは決まらないしね
全部作り直すとかできないから、まず既存資産との互換性とかがめちゃくちゃ重要だしなあ

**デフォルトの名無しさん** · 2022/04/19(火) 23:14:51.60

Haskellはとてもいい言語だと思うけど、まあ今後も広くは普及しないだろうね

**デフォルトの名無しさん** · 2022/04/20(水) 00:49:02.14

Java(8以前)とPHPとVB.NETは案件も人材もロクなのにあたったことないし関わりたくない

**デフォルトの名無しさん** · 2022/04/20(水) 07:57:17.73

障害者雇用枠だししゃーない

**デフォルトの名無しさん** · 2022/04/20(水) 13:03:13.18

小一時間でゲームをつくる──7つの定番ゲームのプログラミングを体験 (WEB+DB PRESS plus)
https://www.あmazon.co.jp/dp/4297127458

この本面白いね。
コンソールに出すアスキーアートだけでゲームを作るところと最小限の工程ごとに動作確認するところがユニークだ。

誰かこのなかのどれかのゲームをGoやRustに移植してgithubあたりにアップしてくれないか？
その出来栄えでその言語の優劣を競うというのはどうだろうか？