次世代言語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/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へ、という流れが多い

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

Rustと他言語の関係も
RDBもNoSQLの関係も同じで
実際は要件に照らし合わせて適材適所で選択していくのが現実

Rust信者は適材適所って言葉を知らないからNoSQLが最強でRDBはゴミ
Rustが最強でGC言語はゴミ

と要件を無視しまるで全ての用途に対し万能であるかのように喧伝する

こういった思考停止したマウント意識の高い妄信者が死滅してくれればRustは日本でも流行っていくだろうw

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

>>551
> スクリプト言語を含む様々なGC言語からRustへ

それってあなたの感想ですよね？なんかそう言うデータあるんですか？
CやC++からRustに移行していくって流れなら一般的に言われてると思うけどそれは初めて聞いたわー
妄信者しか言ってないよね笑

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

>>550
ほら、あなたが狂っていることがこれで完全に証明された
あなたが指しているそれらのスレを見ると
『RDBは不要』との主張などこにもなく
むしろ逆で
『RDBの利用を必要最小限にする』とある
つまりRDBを最小限必要とするとの主張だ
以下ソース引用

>>88
> RDBはコストが高いだけでなくパフォーマンス面でも不利だから利用を最小限にする

>>99
> クラウドが提供するRDBの高コストなど現実を理解していれば
> RDBの利用を必要最小限にした方が有利なことが理解できるだろう

ソース引用以上
あなたが狂っているからあなたは誤読としくは意図的に嘘をつく狂った行動をあなたはとっていると証明された

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

そもそもGC言語ってのは誰でも書きやすいようになってるから流行ってるわけ
CとC++に比べて劇的に楽になっているってのが流行ってる最大の理由

Rustは当然GCがなくなる分自分で管理する必要がありそれなりの難易度があるからGC言語からRustに置き換わるなんて流れはどこにもありはしない
ほんと妄想が酷いんだなw

GCがボトルネックになるケースなんてごく稀であるし、そういったレアな要件で初めてRustに移行することを検討するべき
Rust信者はそう言った要件を無視し脳死でGC言語からRustへだとかほざいているけど
そんな流れはこの世のどこにも存在しない

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

いつものお二人さんw
まぁこの二人のための隔離スレだからいいんだけどさ

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

>>552
その「NoSQLが最強でRDBはゴミ」などの書き込みはどこにあるんだ？

そういう妄想を書き込んで開き直ったり
特定の言語を執拗に批判し続けたり粗探しをして叩いている異常者がここでは問題視されている

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

>>554
不要って言ったのは邪推しただけかもしれないが
問題はそう言う言葉遊びではなくRust信者のコストが減るからあらゆる用途でRustがいいとかいう妄言が完全に矛盾してるから馬鹿にしてるだけだよw

それを運用していく上での人件費は？w

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

早くGC言語からRustって流れのソースを教えてくれよw

仮にPython使ってるとしたらなんでわざわざRustに変えないといけないのよ笑
どこにそんな流れがあるのか教えてくれ

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

GCか否かなんてことよりも
純粋にRustはプログラミングしやすいから
Rustが7年連続で最も愛されているプログラミング言語No.1となった

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

PythonだけでなくRubyからRustへ変えて高速化したCookpadの例もあるね
どの言語からも高速化するならRust一択になりそう

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

Pythonは参照カウントもする中立派
高速化しない者だけが中立になれる

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

プログラミングしやすいらしいがクラウド用途ではGoばかりでRustは全然使われてないな

Rustはtraitとかマクロとか抽象化プログラミング、メタプログラミングの機能がやたらと充実してるけど、逆にそれのせいでプログラミングしにくくなってるのでは？
レベルの高いプログラマーではないとうまく扱えないピーキーさがある

シンプルな言語仕様のGoで書かれた実用的なプログラムがやたらと多いのを考えるとそう言う傾向が見て取れるよね

だからここにいるアホRust信者はRustなんてピーキーすぎて扱えないのが現実
だから他言語にマウントを取るしか能がないわけ

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

こいつRust信者の仮面を被ったアンチRust工作者だな
そうでもなければここまでアホレス垂れ流し続けられないよ

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

>>563
もしかしてRustでプログラミングして何かを作ったことない人なのかな
既存言語と比べてそれらの充実したRustの機能により格段にプログラミングしやすくなってるよ

**デフォルトの名無しさん** · 2022/08/17(水) 05:04:30.24

>>565
「オートマよりもマニュアルの方が機能が充実しているから扱いやすい」ぐらいめちゃくちゃな主張だな。
あるいは「スマホよりパソコンの方が機能が充実しているから扱いやすい」とか。

**デフォルトの名無しさん** · 2022/08/17(水) 06:30:44.49

>>566
逆っぽい
色んなことがコンパイラにより自動化されているRustがオートマに相当かな

例としてヌルポ(事故)を避けることを考えてみると
(1)ヌルポを避ける機構を言語が提供していなくてプログラマーが手動で全て頑張らないといけない言語
(2)ヌルポを避ける機構を言語が提供してるけど適用必須でないためプログラマーが自分でその機構の利用を選択しなければならない言語
(3)ヌルポを避ける機構を言語が提供していて必ずその機構が用いられる言語
と3種類に分けた場合でもRustは自動適用の(3)だよね

他にもこのスレで既出の「データ競合回避」や「自動メモリ解放」なども同様
Rustはコンパイラが全て必ず適用してくれるからプログラマーの責任が激減してるよね
したがってRustがオートマに最も近いっぽい

**デフォルトの名無しさん** · 2022/08/17(水) 06:38:31.18

良い物を作るだけで自動的に売れると思うのがオートマ
ゴリ押しするのがマニュアル

**デフォルトの名無しさん** · 2022/08/17(水) 07:32:06.74

GC言語使ってる人にとってGCがないRustがオートマなわけがないだろう
C++がマニュアルだとしたらRustはセミオートマだ
GC言語はオートマ

**デフォルトの名無しさん** · 2022/08/17(水) 07:51:45.43

>>569
GC言語もRustもメモリ自動解放サポートで同じだからそこはいいとして、
それらの言語の中でもぬるぽ問題やデータ競合問題などもRustはサポートしているから、
Rustはオートマ度が最も高い言語の一つではないかしら。

**デフォルトの名無しさん** · 2022/08/17(水) 08:00:37.20

>>570
GC言語使ってる人は、もぬるぽ問題やデータ競合問題と無縁、考えたこともない人だっているよ。

例えば、私の席の近くでExcelのVBA使ってる人は、用語の説明からしないといけないレベル。

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

>>570
ならNimの方がオートマにふさわしいな。
Rustはせいぜい教官付きの教習車ぐらい。コストもそんなもんだろ。

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

>>571
考えたこともないなら単なるバカだな
データ競合はGC言語か否かに関係なく起きて防ぐ必要がある
ぬるぽもJavaからGoに至るまで多くのGC言語で起きて防ぐ必要がある

**デフォルトの名無しさん** · 2022/08/17(水) 08:34:23.74

>>573
バカで良いけれど、そんなの気にする必要もない要件もあるって事だよ。世の中何でもRustの機能を必要としているわけじゃないさ。

Pythonだと、ジャイアントロック掛けまくってるけれど、困らない事が多いという想定でしょう。