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

**デフォルトの名無しさん** · 2022/08/05(金) 08:26:38.87

スレタイ以外の言語もok

前スレ
https://mevius.5ch.net/test/read.cgi/tech/1655771266/

**デフォルトの名無しさん** · 2022/08/14(日) 22:57:09.94

関数型のElixir は、データを書き換えられない。immutable。
新規作成しかできない

だから、並行処理に強い

**デフォルトの名無しさん** · 2022/08/14(日) 23:52:55.91

>>448
こういう議論も地味に重要だと思う
セミコロンなしでreturn必須な言語の方が可読性高いのかな？
returnを書くことで読み手にとって何が明確になるんだろうか

フォーマッタでの自動入力って何？

**デフォルトの名無しさん** · 2022/08/14(日) 23:58:23.93

>>451
すなわち値を書き換えるたびにガベージを撒き散らしGC
さらにElixirにはGCされず溜まる一方のAtomがあり枯渇すると死ぬ

**デフォルトの名無しさん** · 2022/08/15(月) 00:30:10.08

文法はフォーマッタやコード生成、静的解析などのツールの作りやすさ影響してくるからあまり馬鹿にしない方が良い

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

日本人は一部はセンスあるが
RustやElixer等メタプログラミング言語が理解できないやつが多すぎる

**デフォルトの名無しさん** · 2022/08/15(月) 01:17:24.43

外国人でも抽象的な概念についての難易度は同じだゾ・・・

**デフォルトの名無しさん** · 2022/08/15(月) 09:39:59.10

セミコロンを省略するとreturnになるわけではないぞ
・Rustでは式にセミコロンをつけると文になる
・ブロック({stmts}のこと)の最後の式が、そのブロックを評価したときの式となる
この二つのルールが原則で、関数のブロックの最後のセミコロンを省略すると、関数を評価した値になるってだけ

let a = {
let mut b = Builder::new();
b.add(foo);
b.add(bar);
b.build()
};
このルールのおかげでこのようなコードが書けるようになる(return文は関数から抜けるためにしか使えないので、ブロックの評価には使えない)
一時変数のスコープを最小限に抑えることができるし、mutableで宣言した変数を、スコープを抜けたらimmutableに戻すこともできる
慣れれば見やすいし、意味的なメリットも多い

**デフォルトの名無しさん** · 2022/08/15(月) 10:33:46.88

>>456
ウィキペディアの英語版と日本語版比べてみて、
メタプログラミングについて書かれている事が全然違うから。

日本は本当に遅れてる

**デフォルトの名無しさん** · 2022/08/15(月) 10:41:42.04

>>457
その意味不明な記法が可読性が悪くてゴミなんだが？
信者以外からはメリットを対して感じないよね。

この恩恵を受けるためだけにセミコロン全てにつけないといけないのめんどいんだけど。

**デフォルトの名無しさん** · 2022/08/15(月) 11:14:59.57

バカはバカを呼び寄せる

**デフォルトの名無しさん** · 2022/08/15(月) 11:41:54.68

>>459がどの言語の文法を理想と考えているのかが気になる
golang?

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

なぜRustに対する批判が具体的なものじゃなくて、「意味不明」とか「不要」とか主観的で何を指しているのかわからないような言葉ばかりなんだろう

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

文末のセミコロンが必須な主なプログラミング言語
C　C++　Java　Perl　PHP　など

この状況でRustのセミコロンを叩いているのはこれらの言語を知らない初心者？
しかもRustは文と値の区別のためセミコロンの有無を活用して意味付けしている

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

>>463
最近の言語が一切なくて草
モダン言語はない方が普通でそれと逆行してるから批判してるんだが

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

Python Ruby JavaScript Scala Kotlin あとなにがあったっけなぁ

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

>>457
逆にセミコロンなしをデフォルトにしてセミコロンとかつけると式になるとかでもいいのでは？

その書き方ができると便利なのは否定しないけど、その恩恵を得るためだけに全てにセミコロン付けるのを押し付けるのは余計なコストだっていいたいわ

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

セミコロンを省略可能にしたプログラミング言語は色々と苦しんでいる
昔からJavaScriptのセミコロン省略により起こる問題は有名だが
Goなどもセミコロンを省略可能な言語なので問題がよく起きている

例えばGoでは
foo := 111111111 + 222222222 + 333333333
が何らか長い行として長いので改行して書こうとして
foo := 111111111
　　+ 222222222
　　+ 333333333
と書いてしまうとこれは以下のセミコロンの省略と解釈されてしまう
foo := 111111111;
　　+ 222222222;
　　+ 333333333;
つまりエラーとなる

他にもGoでは
bar := []int { 111111111, 222222222, 333333333 }
が何らか長い行として長いので改行して書こうとして
bar := []int {
　　111111111,
222222222,
333333333
}
と書いてしまうとこれは以下のセミコロンの省略と解釈されてしまう
bar := []int {
　　111111111,
222222222,
333333333;
}
これもエラーとなる

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

>>467のようにGoは「セミコロンが必須だけど、省略可で、自動セミコロン挿入される言語」であるため
うっかり改行すると自動セミコロン挿入により文法エラーとなってしまう

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

Rustで文と式が混在するのは最適化のため？文でエラーが発生したときはどうなるんかね？

resultとかの戻り値用変数があると自然だけど、末尾呼び出し最適化が面倒になるので痛し痒し。

**デフォルトの名無しさん** · 2022/08/15(月) 13:06:38.69

>>467
それの何が問題なの？
文法エラーになるなら何の問題ではない、エラーにならずにコンパイルされて変な挙動をするとかだったら問題だけど

**デフォルトの名無しさん** · 2022/08/15(月) 13:10:39.72

>>466
文にセミコロンをつけると式になるって文法を整合性を保ったまま定義できるとは思えない....
1とかtrueみたいな一つの値は式として扱う
ifやmatchはデフォルトで文として扱い、セミコロンをつけると式になるって文法にすると
let x = f(if cond { ... } else { ... };)
みたいな文で、どこが文でどこが式なのか曖昧さを持ってしまう気がする

**デフォルトの名無しさん** · 2022/08/15(月) 13:14:43.30

構文解析の簡単さってかなり大事なことだと思う
language serverも軽くなるしコンパイルも早くなる
適当に書いてフォーマッタで整形するって書き方もできるようになる
セミコロンをつけるのが面倒なのは分かるけど、それ以上の恩恵があるのは事実

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

文法エラーになってからわざわざ直すのは面倒くさくないの？
JS/TSでもASIの罠にはまらないように考えるほうが面倒だから基本セミコロン付けているな

**デフォルトの名無しさん** · 2022/08/15(月) 13:19:28.24

>>466
言語設計した事ある？
a = b の b は式だからお前の仕様だと ; が必要になるんだけどw

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

>>469
Rustでは文は
Item(関数の定義や構造体の定義など)
LetStatement(let文)
ExpressionStatement(式にセミコロンつけたやつ)
MacroInvocation(hoge!();みたいにマクロの使用にセミコロンつけたやつ)
しかないから、そもそも文はエラーを生成しない
文の中の式がエラーを生成することはあるけど、文法上はハンドリングも式の中で行われる
https://doc.rust-lang.org/stable/reference/statements.html

**デフォルトの名無しさん** · 2022/08/15(月) 13:23:00.24

>>474
したことねえけど、式として表現できるようにしたいからセミコロンを全てに強要するとかうんこだなって言いたいだけ

利用者にとっては面倒なだけ

**デフォルトの名無しさん** · 2022/08/15(月) 13:32:10.82

>>476
式の全てにセミコロンが強要されているわけではないぞ
Block(ifとかmatchとかの{}を使うやつ)を含む式であるExpressionWithBlockではセミコロンの省略が可能とされている
だから、式を文として扱うべき場所で必要最低限のセミコロンが強制されている
https://doc.rust-lang.org/stable/reference/statements.html#expression-statements

**デフォルトの名無しさん** · 2022/08/15(月) 13:36:40.79

>>476
だからお前の方法だと余計面倒になるだろw
問題提起はまあいいとして解決策がアホすぎる

**デフォルトの名無しさん** · 2022/08/15(月) 14:50:27.64

セミコロンは面倒だし書かなくていいならそれに越した事ないけど
JSみたいに罠に嵌るくらいなら明示的に書くのでも別にいい
Rustはじめた当初はセミコロンの有無で戻り値が変わるのはめちゃイライラしたけど2週間もすれば慣れる

セミコロン不要言語ではRubyやSwiftは縛りが少なくて扱いやすい
Pythonは改行できるケースがかなり限定されてるから扱いにくい(そのくせ1行80文字にしろとかアタオカ)

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

話題か全然次世代言語っぽくないな
次世代言語は人間の考えを忖度して良い感じにコードを解釈して欲しい
セミコロンとか些細な文法レベルじゃなくて、自動的に最適なアルゴリズム選んでくれるとか

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

どういうトレードオフの上に成り立ってるかを理解しようとしない人とは技術的な議論はない立たないわな

**デフォルトの名無しさん** · 2022/08/15(月) 16:06:15.48

長い行を途中で改行したくなったらどうなるか？

・JavaScriptだと正しく333333333と出力
let foo = 111111111
+ 222222222
console.log(foo)

・Goだとエラー(+222222222が使われていない)となる
foo := 111111111
+ 222222222
fmt.Println(foo)

・Pythonだと111111111と出力
foo = 111111111
+ 222222222
print(foo)

・Rubyだと111111111と出力
foo = 111111111
+ 222222222
p foo

・Kotlinだと111111111と出力
var foo = 111111111
+ 222222222
println(foo)

セミコロンがある言語ならば長い行を自由に改行できる

**デフォルトの名無しさん** · 2022/08/15(月) 17:19:36.40

foo = (111111111
+ 222222222)
print(foo)

1つの評価式としたいのに途中改行を入れることを利点だと主張するなんてバカげている....
素直にC/C++の古めかしい記述を引き継ぎたい人が多いだけというのは、公式も認めてるのに

**デフォルトの名無しさん** · 2022/08/15(月) 17:58:11.91

セパレータ無しで改行を無視するようにしたいなら、yamlのブロックスタイルぐらいが妥当かと。

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

セミコロンが面倒とは言っても、インデントのタブと同じで頭使わないから楽だと思うんだがなぁ。
そんなに毛嫌いするようなことなんだろうか。

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

もうここら辺の話は好みの問題もあるからこっちが正しいとか言っても揉めるだけ
>>483にしても無駄なカッコはヤダって奴が出るかも知れんし
foo = 111111111 +
222222222
で正しく処理できる言語もあるけどプラスの位置が気に入らんとか言う奴がいるかも知れんしな

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

セミコロンがいるいらないなんてそんなに気にする事なのかな？
Cスタイルで無い書き方する言語の方がよっぽど見にくいんだよねぇ

**デフォルトの名無しさん** · 2022/08/15(月) 19:05:59.41

Dartもそうだけどセミコロンなし言語に慣れてると忘れる時にいちいちエラーになってうざい
JSはprettierで自動入力できるけど、エラーになるのがめんどくさい

まあただの慣れの問題だけど

**デフォルトの名無しさん** · 2022/08/15(月) 19:17:14.24

PowerShell（; 不要）と C#（; 必要）使ってるとたまにあれ？って思うことあるけどたいして混乱しないよ
そんなのにいちいち引っかかってたら他にもっと引っかかるところあると思うが

**デフォルトの名無しさん** · 2022/08/15(月) 19:17:50.21

Rustはセミコロンレスにする実装が面倒ってだけやろ
エルゴノミクス的にはセミコロンなしのほうがいいに決まってる

**デフォルトの名無しさん** · 2022/08/15(月) 19:34:59.12

むしろ482のような何も考えられない熟練者が、他の多くの言語を全否定してるのであって、Cスタイルを否定しているわけではない。
Cスタイルで無い書き方する言語の方が見にくいというのはよほど経験が足りないか、組み込みかシステムプログラミングでC/C++の
沼にどっぷりハマってるか....いまどきbashもTypescript/JSもLuaも書くだろうし、DeepleanningしたいならPythonぐらい触るでしょう？

**デフォルトの名無しさん** · 2022/08/15(月) 19:42:50.19

フリーフォーマットスタイルになったのだって、B言語の毛の生えたC言語初期がブロック表す{}でさえ、当時の多くのコンピュータのキーボードで
打てなかったのに採用しており明らかにパーサーを簡単にしたいがためだけで、確かに欠陥は無いが、他の言語を否定する有益な要素には
全く成り得ない。「頭がCスタイル＝だから個人的にはそれが一番見やすい」という理論なら分かるが、一般化できるものではない

**デフォルトの名無しさん** · 2022/08/15(月) 19:46:40.39

フリーフォマットスタイルってウケる言いまわしだね

**デフォルトの名無しさん** · 2022/08/15(月) 19:51:28.75

些細なことで盛り上がってるな
昨日のRust叩きがすぐ論破されてRustは高機能で優秀だと決着してしまったから
今日のRust叩きはセミコロンと波カッコがテーマなのかい？

**デフォルトの名無しさん** · 2022/08/15(月) 20:17:06.88

>>494
「誰にとって」高機能で優秀なのかを考えんとな。
リーダーとかマネージャーとかの管理者にとって、Rustはルールを強制して一定の安全性と性能を担保できる便利なルール。
その裏返しになるけど、コーダーみたいな実装者にとって、Rustは窮屈な制約や複雑な概念を押し付けられる不便な扱いづらいツール。

優れたプログラマーはコーダーであるとともにマネージャーでもリーダーでもあるからRustの利点は分からんでもないけど、普段使いにはしたくないツールだよなぁ。
今の複雑さじゃHaskellとかc++とかと大して変わらんから、そのうちもっと洗練された言語が出てくるんじゃない？

**デフォルトの名無しさん** · 2022/08/15(月) 20:32:42.70

ルールは強制じゃないんだよなあ
税金を払ってない金持ちがいるのと同じ

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

>>495
複雑な概念を押しつけられるというよりも、現実の複雑さを処理系が覆い隠さずそのまま見せている、ただしデフォルトでは安全装置付き、というのが自分の感覚には近いかなぁ

カジュアル用途にはshared xor mutabilityを採用したGCあり言語があれば良いと思うんだけどそれでも敷居高いと言われてしまうのかな

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

>>495はrustのチェックが過剰と言いたいのか、プログラムがエッジケースでクラッシュしても良いからプログラマーの自由にさせろと言いたいのか、どっちなんだろう

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

>>491
>>482はべつに全否定なんかしていないだろう。
セミコロンを省略できることが無条件で優れているかのような主張に対して、そこにはやはり
トレードオフが存在することを示しているだけだと思うが。

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

>>497
shared reference, mutable reference, ownedの3種類を常に分けるのは作る側も使う側も面倒でしょ
GC言語でdata raceを避けるためだけに許容できる面倒臭さではないと思う

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

>>499
>>482はサンプルが悪い
エアプじゃなければもう少しマシなの持ってきなよ

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

>>501
全否定とサンプルが悪いのと全然関係ないが。
それはそうとして>>482はセミコロンを省略できる言語で改行するのに構文を意識しなければならない例として
わかりやすいと思ったが、どこがどうダメだと思った？

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

>>497
コーダーにとっては押し付けられるのも覆い隠さずむき出しなのも同じ。
運転するならマニュアルよりオートマの方が楽に目的地に行けるからねぇ。

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

>>500
まともなプログラマーならば
mutableかimmutableを必ず区別するしスクリプト言語にすら区別がある
GC言語だからそんな面倒な区別をしないなんてことはない
更にそのもの自体かreference (pointer)かの区別をする言語も多い

**デフォルトの名無しさん** · 2022/08/15(月) 23:36:07.11

>>504
immutableかmutableかの区別とはまた別

例えばPythonのiter()やC#のGetEnumerator()に相当するメソッドを
Rustではshared reference用のiter(),
mutable reference用のiter_mut(),
owned用のinto_iter()と3つ用意してその3つを使い分ける必要がある
他にも3種類の構造体を用意したり3種類ずつtraitをimplしたりする必要がある

Rustで3つを使い分ける主目的はメモリ安全性であってdata raceを防ぐのは副産物
メモリ安全性が確保されてるGC言語で副産物のためだけにやるほど価値があるとは思わない
data race detectorみたいなので十分

**デフォルトの名無しさん** · 2022/08/15(月) 23:43:36.56

>>505
書き換えるのか書き換えずに読み取るだけなのか必ず区別する
プログラマーならそこは絶対に意識するところ
参照なのか実体なのかも同様に区別する
例えばcall by referenceなのか否かで変わってくるから常識

**デフォルトの名無しさん** · 2022/08/15(月) 23:44:00.49

>>502
挙げてる言語が全てセミコロンのようなものが無ければ、改行をパースできない言語だけを挙げておいて
サンプルが悪くないと考えられることはセミコロンを入れる言語を優先したいだけでしょ？
そして482がいってるのはトレードオフなんて一言も言ってないし→同一人物だとすればサンプルも悪い

**デフォルトの名無しさん** · 2022/08/15(月) 23:59:03.56

>>505
噓つき

まず、使い分けと言っても間違って使っていたらRustコンパイラが指摘してくれるから、他の言語のようにプログラマーに責任と義務を押し付ける形で使い分ける必要は全くない

次に、今まで様々なプログラムを書いてきて、そのための3種類の構造体やimplを用意する必要になったことは一度もない
プログラムでやりたいことは一つなのだからどれか一つに決まる
その選択を仮に間違えていてもRustコンパイラが指摘してくれるので必ず正解を選択できて楽勝

Rustはプログラマーへの責任圧力や負荷が非常に少ない
間違えてもコンパイラが賢くて教えてくれるし次第に慣れて間違いも激減

**デフォルトの名無しさん** · 2022/08/16(火) 00:25:36.99

>>506
>>505に書いてる事を理解してないでしょ
それだとRust的なaliasing xor mutabilityを実現するためにどういう言語機能が必要で
開発者にはどういうデメリットがあるのかわかんないよ

**デフォルトの名無しさん** · 2022/08/16(火) 00:31:52.46

>>505
全部refcell相当にしてランタイムでよしなに処理できないかね？

**デフォルトの名無しさん** · 2022/08/16(火) 00:45:43.29

>>509
デタラメを書いている>>505の文章をよく読め
Rustに無知な>>505が妄想でデタラメを書き並べて無意味なRust叩きをしているだけだぜ

**デフォルトの名無しさん** · 2022/08/16(火) 01:34:09.32

RefCellは無視してCellを使うのがコツかなと思ってる

**デフォルトの名無しさん** · 2022/08/16(火) 01:41:29.91

>>510
実行時のチェックのみでよければborrow checker無しの実装も可能かもしれないが
常にborrow済みでborrow_mutができない状況が量産されそう

**デフォルトの名無しさん** · 2022/08/16(火) 02:21:22.55

Rustは便利でプログラミングしやすくて良いね
間違えてもコンパイラが必ず阻止して親切に教えてくれる
他の言語だと同じように間違えていても見かけの文法さえ合っていればコンパイラが通してしまう

**デフォルトの名無しさん** · 2022/08/16(火) 05:56:45.08

とにかくRustさえ使っとけば安心安全だよね

**デフォルトの名無しさん** · 2022/08/16(火) 06:08:59.99

いやRustはプログラミングしやすいことが感想
たまたま安全も付いてきた
あとなぜか高速も付いてきてラッキー

**デフォルトの名無しさん** · 2022/08/16(火) 06:09:39.15

xor mutabilityを実装するとライフタイムの解析みたいなことが必要になるから結局GC要らなくね？みたいなことになりそう

**デフォルトの名無しさん** · 2022/08/16(火) 06:47:45.38

3種類あると言ってたのに
xorとかいって2種類を意識してるのは違和感がある
意識の外にあるmoveの方が実は革新的だったりして

**デフォルトの名無しさん** · 2022/08/16(火) 07:59:13.38

>>508
コンパライラが指摘出来るのに、勝手に使い分けてくれずに、使い分けをさせようとするのが、納得いかない。

勝手に解決できることは、出来るだけ勝手に解決をしてしまって欲しい。

**デフォルトの名無しさん** · 2022/08/16(火) 08:09:09.89

>>519
コンパイラは神や予知者じゃないのだから
どちら側へと解決すべきかまでは分からない
だからコンパイラによるアドバイスを受けてプログラマーがその方向性を確定させる

**デフォルトの名無しさん** · 2022/08/16(火) 10:10:30.02

>>507
>>482はみんな「セミコロンを省略できる言語」の例だと思うんだが。
いったいどの言語ならいいというんだろう？FORTRANかshかあるいはLISPとか？

**デフォルトの名無しさん** · 2022/08/16(火) 11:21:12.43

そもそもRustとかの新しい言語は演算子の途中とかで改行できるようにするためにセミコロンを用意したわけじゃないし…

**デフォルトの名無しさん** · 2022/08/16(火) 11:34:08.30

;ない言語(例えば
python)で途中で改行したいなら(
)

**デフォルトの名無しさん** · 2022/08/16(火) 12:15:04.38

>>518
値の受け渡し方法の種類とmutabilityの違い

利便性を無視すれば可変参照をサポートしないようにして2種類に減らす事は可能

**デフォルトの名無しさん** · 2022/08/16(火) 13:22:47.54

>>522
まさにそう。見る角度によって美点を見出すのは人それぞれだがセミコロンなんてものを挙げて長い行が複数行で書けるなどと
長大なくだらない例を別言語叩きにしようとする腐った根性がまず気に入らない。公式すら見えてない白痴

**デフォルトの名無しさん** · 2022/08/16(火) 13:53:44.58

うむ
セミコロンの有無で気に入らない言語を叩き出したやつはキチガイ
それぞれにメリットはあるしプログラマーにとってもどうでもいい誤差

**デフォルトの名無しさん** · 2022/08/16(火) 14:40:34.16

分類するとこんな感じかな。

1. 改行を文デリミタとして、文を途中で折り返したい場合には行継続を明示する　(FORTRANなど)
2. 改行に空白以上の文法的意味を持たせずに文分離記号、終端器具を用いる (ALGOLなど)
3. 1.の変形で、構文解析と組み合わせることで行継続の明示を不要とする (Pythonなど)

当然ながらどれも一長一短あるわな。

**デフォルトの名無しさん** · 2022/08/16(火) 14:55:33.84

セミコロンが有ったり無かったり些細なことで各プログラミング言語を批判する人は間違いなくキチガイ

**デフォルトの名無しさん** · 2022/08/16(火) 15:00:16.01

技術的な話が理解できないからセミコロンくらいしか口出しできないんだろ

**デフォルトの名無しさん** · 2022/08/16(火) 17:28:09.35

言語を作る側と使う側の視点が噛み合ってないように見えるし、なんかマニアックな方向に議論が進んでるな

**デフォルトの名無しさん** · 2022/08/16(火) 17:59:37.32

ASTとプレゼンテーション層としてのテキスト表現でしかないから内容と見た目の分離をすれば…みたいに考えてしまうが、htmlとcssの関係みたいにすぐそばに地獄の例もあるからなぁ。

**デフォルトの名無しさん** · 2022/08/16(火) 18:09:52.12

>>524
可変とか不変とかいう代わりに
swap可能とかswap不可能とかいえば良いのでは

swapって確かに何か変化はするが
もう一回swapすれば元に戻るという意味では何も変わってない

**デフォルトの名無しさん** · 2022/08/16(火) 18:11:37.15

なんで母国語の文法でプログラミングできないの？
っていう質問と大差ないぐらいにはナンセンスなんだよなあ

**デフォルトの名無しさん** · 2022/08/16(火) 18:32:26.44

>>527
その分類だとRustのセミコロンの特殊性が埋没する

**デフォルトの名無しさん** · 2022/08/16(火) 18:53:59.07

>>534
Rustのセミコロンは実質的に「式の結果を捨てる演算子」だからなぁ。
あえて文としているのは最適化のためかね。

**デフォルトの名無しさん** · 2022/08/16(火) 19:09:03.56

>>534
構文的には特殊なことなどなくPascal等と同じ.だろう。評価結果が違うだけ。

**デフォルトの名無しさん** · 2022/08/16(火) 21:15:03.57

プログラム言語の長短を議論したいなら、最低限、構文解析と型理論ぐらいは勉強しなよww
自分の使えるプログラミング言語の表層だけ見てあれこれ言っても仕方がない
せめて基礎知識ぐらいは身につけないと、自分の得意な言語こそが最強！レベルの話し合いにしかならない

**デフォルトの名無しさん** · 2022/08/16(火) 21:27:16.28

マイナス金利政策みたいに
何かを変えたいという目標が達成されるまで全く同じことを続ける人が一定数いる

**デフォルトの名無しさん** · 2022/08/16(火) 21:55:08.25

このスレ、次流行る言語について考察するスレだと思ったらなんか違う感じか

**デフォルトの名無しさん** · 2022/08/16(火) 22:17:21.80

>>539
Rustが覇権したから推進派とアンチとの攻防戦の場となっているｗ

**デフォルトの名無しさん** · 2022/08/16(火) 22:22:22.73

プログラミング言語のアンチをしてる人は精神的に何か病があるんじゃないか

**デフォルトの名無しさん** · 2022/08/16(火) 22:23:06.14

NoSQLの謎の信仰で無知が露呈したRust信者w

**デフォルトの名無しさん** · 2022/08/16(火) 22:25:20.93

>>541
他言語を貶めるRust信者のことだね
大半はRustじゃなくて信者を批判してるわけだが

**デフォルトの名無しさん** · 2022/08/16(火) 22:34:52.91

別にRustを批判しているわけではない
どんな用途でもRustが最強で他の言語はゴミとかほざいてるRust信者を批判しているだけ
NoSQLは万能でRDBは不要とかほざいてるようにただの無知で適材適所という言葉を知らない馬鹿ってのが証明されてるわけだが

だからRustは低レイヤーには適しているがバックエンドやWebといった用途ではさほど適していないので流行らないってのに反論できずに発狂しているのが現実
やたらクラウドのコストガーメモリ効率ガーだとか主張するが運用する上での人件費のことを一切考えられないキチガイ

**デフォルトの名無しさん** · 2022/08/16(火) 22:39:39.43

プログラマーは社会不適合者しかいないんだから仲良くせいや

**デフォルトの名無しさん** · 2022/08/16(火) 22:42:24.87

簡単に言うとRustはCやC++を置き換える言語

だからCやC++が通常使わなれない用途で流行ることはまずない
これが現実、いくら信者が発狂しても現実は変わらんよ

**デフォルトの名無しさん** · 2022/08/16(火) 22:43:33.40

>>543
言語の良さを語り合うのは問題ないと思うぜ
特定の言語を執拗に批判し続けたり粗探しをして叩いている異常者が問題視されている

**デフォルトの名無しさん** · 2022/08/16(火) 22:45:57.82

ID:8YjBNSEW が自分のことを棚に上げて藁人形を持ち出した

**デフォルトの名無しさん** · 2022/08/16(火) 22:48:22.06

>>544
調べてみたが『RDBは不要』と主張している人はこのスレに一人もいない
あなたが狂っているから全く存在しないものをあなただけが見えているのだろう
あなたは自分が狂っていることにそろそろ気付くべきだ

**デフォルトの名無しさん** · 2022/08/16(火) 22:53:09.15

>>88
>>99
コストの観点でRDBは論外って言ってるから不要って言ってるようなもんじゃんw

コストを気にしてRDBを使わないって初めて聞いたんだが笑
どんだけここにいるRust妄信者って無知なんだよw

コスト気にするから全てのプログラムにおいてRDBを減らしつつRustを使えってwwwww

何で人件費のこととかは他のこと考えられないの？w

**デフォルトの名無しさん** · 2022/08/16(火) 22:53:32.19

>>546
そういう嘘はよくないなあ
流れとしては明らかに2系統あって
『自動メモリ解放で安全なのに、C言語と同じ省メモリ＆同じ速さが出る言語』として
スクリプト言語を含む様々なGC言語からRustへ、という流れが多い