次世代言語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/13(土) 23:40:22.03

重要なものがキャッシュに乗りにくくなるのでは？

**デフォルトの名無しさん** · 2022/08/13(土) 23:54:24.87

そもそもRustもC++も含め、RAIIは何でもスタックに積んでいるわけではない
スタック上の値のように振る舞うように作られているだけで、内部的にヒープにメモリを確保しポインタを保持しているケースが多い

**デフォルトの名無しさん** · 2022/08/14(日) 00:25:46.03

Rustは自動メモリー管理が売りなんだから、C++のように自由に何でも出来たらダメでは？

**デフォルトの名無しさん** · 2022/08/14(日) 00:49:36.36

JavaとHaskellの良いとこ取りのように宣伝されてたけど、悪いところを併せ持ってしまったのでは？

**デフォルトの名無しさん** · 2022/08/14(日) 07:17:26.98

>>396
C++はメモリを自動解放しない。
unique_ptrやshared_ptrを忘れずに利用し間違えずに使用した場合のみ自動解放されるが、
それはその正しく作られたプログラムがメモリを自動解放しているのであり、
C++という言語自体がメモリを自動解放することはない。
一方でGC言語やRust言語などはプログラムの記述と関係なくメモリが自動解放される。

**デフォルトの名無しさん** · 2022/08/14(日) 07:54:47.25

事実上今時のプログラムで生ポインタなんて使わないしアスペの>>401は知らんけど普通のプログラマにとってメモリー解放はC++程度で充分

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

>>402
それはプログラマーの問題。
プログラマーの作ったプログラムにより自動解放している。
C++という言語はメモリを自動解放しない。

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

>>401
一般ユーザーがめったに使わないnewで言いがかりつけるなよ。Rustのunsafeみたいなものだろ。

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

はいはい、アスペは何を指摘されているかも理解できないからどうでもいいわ

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

ムッシュムラムラ

**デフォルトの名無しさん** · 2022/08/14(日) 09:20:45.22

RAIIみたいなありふれたものじゃなくてxor mutabilityをアピールした方が良いのでは

**デフォルトの名無しさん** · 2022/08/14(日) 09:37:16.54

>>407
これ

**デフォルトの名無しさん** · 2022/08/14(日) 09:38:28.08

>>407
実運用としては難しすぎて逆効果だとわかっているから言わないんだよ。
あるいはそもそも理解していないか。

**デフォルトの名無しさん** · 2022/08/14(日) 10:03:55.97

>>409
難しすぎて逆効果ってどういうこと？
ワイRust大好きマンだけど、趣味ってだけで業務ではRust使ってないからよくわからない....

**デフォルトの名無しさん** · 2022/08/14(日) 10:19:19.22

>>410
もちろん難しいことはなくとてもシンプルな原理
そして実運用で非常に大きなメリットをもたらしている
Rustが大手IT各社に支持されている理由の一つ

**デフォルトの名無しさん** · 2022/08/14(日) 10:29:55.69

あくまでもOS開発の用途で採用されてるだけ

**デフォルトの名無しさん** · 2022/08/14(日) 10:38:15.56

>>412
Rustの世界的大規模な調査結果により
Rustの利用対象はサーバーサイド/バックエンドが最多で
以下クラウド、分散システム、WebAssembly/Webフロント、組み込みといった状況になっている

**デフォルトの名無しさん** · 2022/08/14(日) 10:43:52.82

>>413
ソースは？
大手企業は？

**デフォルトの名無しさん** · 2022/08/14(日) 10:48:15.10

>>414
>>413のソースは毎年調査が行われているRust Annual Survey Report

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

>>407
XORじゃないけどな

**デフォルトの名無しさん** · 2022/08/14(日) 11:16:29.29

before == afterのことをimmutableというなら
==の定義とかあるんですか？
まさか、大手企業を観測すれば==の定義が分かると思ってるマッドサイエンティストはいないよね

**デフォルトの名無しさん** · 2022/08/14(日) 11:19:12.35

>>416
一般的にデータ競合を起こさないための条件は
multiple readers XOR single writer
そしてRustも同じくこのシンプルな原則に従っている

**デフォルトの名無しさん** · 2022/08/14(日) 11:47:03.37

現実には複数の状態のストアに跨がる論理的な競合の方がずっと問題で、単一データの読み書きの競合なんてアトミック変数くらいで十分

**デフォルトの名無しさん** · 2022/08/14(日) 11:59:58.73

実行時に同時に読み書きしうるかどうかをコンパイラが厳密に検知することは不可能
Rustがやってるのは大幅に安全側に倒すアプローチで、それでいいんだったら関数型みたいにそもそもミュータブルなデータを共有しない、でも立派に対策になってるよね
実際それで十分なケースが殆どでしょ

**デフォルトの名無しさん** · 2022/08/14(日) 12:04:57.82

Rustはdata raceはふせげてもrace conditionは防げない
銀の弾丸でも何でもない

**デフォルトの名無しさん** · 2022/08/14(日) 12:09:32.20

>>419
アトミック変数を忘れたら競合する
さらにアトミック変数を使ってもそのコストがかかる

Rustでは静的にコンパイル時にデータ競合を必ず排除する
アトミック操作を必要とするならば指摘してくれる
multiple readers XOR single writerを守っていれば当然(コストの高い)アトミック操作を必要とせずにコンパイルが通る

したがってRustは他の言語よりもコストを低くデータ競合の安全性を常に満たせる

**デフォルトの名無しさん** · 2022/08/14(日) 12:11:52.89

並行処理をしてないのにいちいちいらない制約かけられる方がコスト高いわ

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

>>422
いつものキッズかな
単一変数のデータ競合が生じなくても多くのロジックは競合するんだよ

**デフォルトの名無しさん** · 2022/08/14(日) 12:17:06.31

並行処理を安全に実装するのが難しいから、需要があってGoとかRustみたいな言語が登場してるのであって、直列なコードしか書かないなら昔の言語でもよくね

**デフォルトの名無しさん** · 2022/08/14(日) 12:18:16.18

>>425
そうじゃなくて、並行処理をしている場合、現実には競合するタイミングが生じないと分かっていても制約がかかることになるんだよ
コンパイラは静的なスコープを検査することしかできないからな

**デフォルトの名無しさん** · 2022/08/14(日) 12:35:39.15

>>424
そんな当たり前のことで問題のすり替えをするのは行儀がよろしくない
>422では明確にデータ競合の話をしている

どの話であってもまずはデータ競合を起こさないことが必須
しかしこれまでの言語はプログラマー任せであり言語として実行前に静的にデータ競合を防ぐ機能を持たなかった
Rustはそれを実現するとともにコストの高いアトミック操作無しでもデータ競合を避ける形もサポートした

**デフォルトの名無しさん** · 2022/08/14(日) 12:48:55.73

>>427
多くの場合はより高水準の制御や抽象化を必要とするため、君が思っているほどデータ競合可能性の回避は重要じゃないってことだよ
制約に対して得るものが小さい

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

>>428
実際にそれらのプログラミングをしていればわかる
データ競合の回避は重要どころか必須

**デフォルトの名無しさん** · 2022/08/14(日) 13:29:25.97

やっぱRAIIを意識しないと会話が成立しないぞ

読みたい情報が消されたり書き換えられているバグよりも危険なのは
情報を記憶する領域自体が消滅しているバグだから
書き換えを制限する効果よりもmoveやdropを制限する効果を見なければ本質が見えない

**デフォルトの名無しさん** · 2022/08/14(日) 13:35:19.72

>>428
データ競合可能性の回避は重要か重要じゃないかではない
データ競合可能性の回避は必ずすべきこと
Rustを叩きたいからといってこれを重要じゃないと主張するのは頭が狂っている

**デフォルトの名無しさん** · 2022/08/14(日) 13:53:29.77

データ競合可能性の回避をしてないシステムやアプリって存在するの？

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

並列処理しなくてもmutable aliasingにまつわるバグは起こりうるよね
典型的にはコレクションのイテレート中の要素追加とか

これを防ぐ仕組みを整えたらうまいこと並列処理にも応用できたという話であってデータ競合を防ぐことが本質ではない

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

>>432
回避し切れてないシステムやアプリはそこそこ存在するけどw

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

mutable aliasingはGC言語でも防げないからなぁ
これが一度Rustに慣れてしまうと他に戻れなくなる原因の一つかも
他言語も積極的に取り入れてほしいところ

**デフォルトの名無しさん** · 2022/08/14(日) 15:49:07.29

コレクションが変更されたら
影響のあるすべてのイテレータに何か通知するべき

ここで、すべてのイテレータのリストを強参照してるとメモリが解放されないバグを作れる
GC言語でも弱参照大事

**デフォルトの名無しさん** · 2022/08/14(日) 15:56:50.41

Rustはオワコンだろ。

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

>>436
GC言語ってそこまでケアしてくれるのが普通なの？

**デフォルトの名無しさん** · 2022/08/14(日) 16:30:43.31

そういうレベルで設計する人たちだと、RustやReactなんかが良いのかもしれないな。
「レベルが高い」と思ってそうなのがアホだけど。
「弊社はアホが多いから、これで行くしかない」というのが正しい態度では？

**デフォルトの名無しさん** · 2022/08/14(日) 16:41:26.12

すばらしい洞察

**デフォルトの名無しさん** · 2022/08/14(日) 16:46:59.70

実際「自分はアホなのでバグのないC++は書けない」と思ってRust書いてるよ
年とともに集中力も維持し続けられなくなるし、コンパイラに助けてもらわないとどうしようもない

**デフォルトの名無しさん** · 2022/08/14(日) 17:03:40.00

昔の静的型付けvs動的型付け論争思い出すね
開発者は十分賢いと仮定しレビューやテストでバグを見つけられれば十分とする立場と、
実行前に機械的に抽出できるバグは潰しておきたい立場の違い

**デフォルトの名無しさん** · 2022/08/14(日) 17:06:11.09

Rustで「簡単」になるのははチームやコードを管理するリーダーやマネージャーで、実装するコーダーにとっては「簡単」じゃないのにな。

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

そういうレベルだと、なに使っても同じでは？

**デフォルトの名無しさん** · 2022/08/14(日) 17:10:46.46

レビューやテストでなんとかできるなら現世代言語で十分だよね
次世代言語という観点では、実行前により多くの問題点を検出することや、検出できる問題の量を保ったままコード記述の自由度を高めることが期待されてることのひとつだと思う

**デフォルトの名無しさん** · 2022/08/14(日) 17:10:54.70

IT大手企業が揃って同じ主張
人手に頼るC++等ではバグを無くせない
良い人材を揃えているところでもミスをゼロには出来ないから言語による支援がある方が良い
メモリ管理でもデータ競合でも同じ

ソース
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/

Rustは、プログラムに必要なメモリーの確保や解放に関連するバグが生じない「メモリー安全」が保証されたプログラミング言語である。
それに対してこれまでのOS開発に使われてきたC/C++は「大規模な開発においてメモリー安全なコードを記述することがほぼ不可能」
（Microsoftのブログ「We need a safer systems programming language」より）なのだという。

GoogleによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
同様にMicrosoftも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。

**デフォルトの名無しさん** · 2022/08/14(日) 17:12:42.24

イテレータなんてないし、for rangeで回ってくるのは常にコピーだよ。

**デフォルトの名無しさん** · 2022/08/14(日) 18:49:23.51

Rustはモダンとか言っておきながら今時セミコロン入力を強要するゴミ言語
セミコロン省略するとreturnを省略できる？何のメリットがあんのそれ
可読性が悪くなるだけだよね

JSみたいにフォーマッタで自動入力もできないしゴミ

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

>>448
Rustを書いたことないか、チュートリアルレベルでしか触ってなさそう

**デフォルトの名無しさん** · 2022/08/14(日) 21:15:44.48

文法や記述は様々な言語をやっていれば誤差と慣れだけの問題となる
それに文句をつけるのは初心者と異常者のみ

そのRustに関して言えばセミコロンや中括弧(波括弧)は機能面で必要だからある
逆に例えば「 if (条件) 」の丸括弧は不要だから「 if 条件」

**デフォルトの名無しさん** · 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

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