次世代言語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/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だと、ジャイアントロック掛けまくってるけれど、困らない事が多いという想定でしょう。

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

>>573
考える必要が無いからオートマなんだろ。オートマ使いはギアチェンジとかエンストとかほとんど意識しない。
問題を回避するためにコンパイラの指示に従う必要のあるRustはオートマじゃない。やっぱり教官付きマニュアル教習車だな。

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

>>574
ここは次世代言語スレ
それら色々な機能がついている言語がメイン対象
だからRustが何歩かリードしてる感じ

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

>>573
並列処理を始めてやっと起きるのでは？
例えばNodeだとデータ競合は発生しないよ
シングルスレッドで行単位では処理が入れ替わらずawaitって書いてあるところ（コールバック単位）でスイッチングするから
競合状態はもちろん発生する、で、競合状態に関してはRustでも防ぐことは不可能

だからNode使ってる人にとってデータ競合はそもそも発生しないからその観点でRustに魅力を感じることはないよね

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

>>575
その、問題を回避するためにコンパイラの指示に従う、のが正しい解決方法で合ってる。
例えば、ぬるぽ問題回避(Null安全)は、KotlinでもSwiftでもRustと同じく別の型とする対応策。
Null安全でないコードが書かれると、コンパイラにより型不一致エラーとなり、コンパイラの指示に従いプログラマーがコードを修整して解決。

このように、ぬるぽ問題回避にしても、データ競合回避にしても、自動対応は無理なので、コンパイラが静的に検知してエラーとするのが正しい解決方法。
型システムの強化により、様々な問題に対応できるようになっていく。

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

>>577
サーバーサイドをやってる周りではこういう状況
Node.jsはもちろん(Workerを除き)シングルスレッドで安全にasync/await並行処理できる
それだけで十分なところもあるけど次第にCPUコア活かして並列処理も加えて高速化したいところも増加中
その時にWorkerでは使い勝手の限界があるのはご存知と思う
すると今まで同様に安全にasync/await並行処理＋新たに並列処理を加えて高速化をできる環境を考えるとRustが筆頭候補
実際に移行したところも出てきているし少しずつサーバーサイドRust化の流れが今後主流になりそうな雰囲気

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

>>579
サーバーサイドでRustとか何のギャグなの？って思うんだけどｗ
Goですらイマイチ伸びないのにｗ

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

Rustはサーバーサイドでもやらないとこのまま消えて無くなるから必死なんだろ

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

>教官付きマニュアル教習車だな。
これは言い得て妙だな

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

静的型付け言語は全てそのパターンだから
実行前にコンパイラに全てを静的にチェックしてもらい指導に従うパターンがプログラミング言語の最高峰なのではないかな

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

最高峰ww

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

ろくに準備をせずに登頂を試みると命に関わります

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

めんどくささでは最高峰だよなぁｗ

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

>>586
本気か？
静的型付け言語をめんどくさいと言うやつはプログラマーに向いていない

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

かまちょ！

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

>>587
ものによるだろｗ
頭悪い奴の方が型に依存しないと物を作れ無さそうだしｗ
全く逆だなｗ向いてないのはお前ｗ

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

その件は昔からはっきり答えが出ている
まともにプログラミングするならば静的型付けが必須
動的型付けだと実行時にムダにデバッグ時間を奪われて効率が悪い
いずれそのことを学習すると動的型付け言語から静的型付け言語へ移っていく
典型的な例がJavaScript(動的型付け)からTypeScript(静的型付け)へ

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

俺は型が無いとコードかけないな
メソッドの名前の一部しか覚えてなくてサジェスト機能に頼りまくってるわ

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

>>590
ウェブのフロントエンドしかやってない人はその辺理解できない人多い印象
動けばオッケーなんだろね

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

>>592
逆じゃね？
むしろフロントエンドに型とかいらんだろｗ元々javascriptなのだし
JavaとかC#とかだとjsonをデコードする為にもクラス用意したりとか逆にめんどくさく感じるわ
ほぼ一人のプロジェクトでクライアント側はUnity(C#)とかだったりするから仕方なく用意しているが
管理画面(vue等)でフロントも書いてるけどjsのままで不便だと思った事すらないし
TypeScriptなんか導入する気にもならんｗ

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

>>593
一人でやってるからじゃね？

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

状況に合わせて使う道具を変える判断力すら持ち合わせてないやつは自称プログラマーでも最底辺だからな
適性はないよ

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

>>594
彼は趣味グラマだから涙
チーム開発の苦労とは無縁なのだ。

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

このスレでRustなどを叩いている>>593氏ってやっぱりレベルがかなり低い人だったんだな

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

>>593
デバッグが手間だから静的型付けが必要、という文脈なんだけど？
結局あなたが言ってるのは動けばオッケーってことでは？

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

動的型とは端的に言えば値に型情報が付属していることであり、おそらくお前らは何か誤解している。
型を指定しないことが動的だと思っているんじゃないか？
図星じゃないか？

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

実行時の値とソースコードの変数の違いは重要だけど、この違いを意識しているプログラマーは少ないよね。

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

実行前にコンパイル時点で静的に型も確定する静的型付け言語がベストだな

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

>>572
Nimはダメだよ
例えばref objectな変数は初期化も何もされないからヌルポ状態となり実際にSIGSEGVで落ちる

もちろんNimでもRustｂﾆ同様のoptionｂgえばヌルポｂﾅきるけｂﾇ
Nimでは前述のようにoptionを使わないコードも許されるからヌルポが起きてしまう

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

Kotlin Rust Swift ← Null安全な新世代言語
Go Nim ← Null安全ではない旧世代言語

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

Swiftって将来性あんのかね
アップル依存大きすぎな時点で知れてると思うんだけど

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

>>559
多くのcli コマンドが go, rust で再実装されつつあるのは perl, python, ruby のようなスクリプト言語から go, rust といったちょうどよいモダンさのあるコンパイル型言語への大きな流れがある気がしている。

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

>>600
値と変数じゃなくて昔はデータ構造とアルゴリズムの違いを意識していた

どのような演算を想定しているかという型情報を
被演算子の側に付属させるというアイデア自体が
演算子と被演算子を一体化させ、両者を分けて考えない原因になった

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

動的型付け言語のメリットてなんだ？
(習得が容易とか書き心地とかを除いて理論的なメリット)

**デフォルトの名無しさん** · 2022/08/18(木) 08:38:35.77

>>607
処理系の実装が容易
型検査いらないしホストの実装が直接的に実行時の動作を記述するため圧倒的にシンプル

**デフォルトの名無しさん** · 2022/08/18(木) 08:39:41.85

>>607
インスタンスの型判定を実際のインスタンスで行うことができるので、コードの適用範囲が広くなる。

C++を理解しているなら、dynamic castの適用事例を考えればいい。総称型で保管して具象型で使用するようなケースが代表的。

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

>>608
> 型検査いらないし
実行時にやるだろ
なので動的型付け言語の多くはインタープリタ
ネイティブコンパイル言語だと逆に結構大変だよ

**デフォルトの名無しさん** · 2022/08/18(木) 09:44:19.64

実行時の型検査なんて、存在しないメンバにアクセスしようとしたらエラーとかオペランドが特定のデータ型でなければエラーといったルールを、演算子やオブジェクトの実装に組み込むだけだよ
ホストとの間で実行モデルやオブジェクトモデルを共有してるから楽勝
JITの場合もオブジェクトモデルは共有するから比較的簡単

**デフォルトの名無しさん** · 2022/08/18(木) 09:50:57.04

そんな言い方するなら静的型付け言語もコンパイル時にやるだけで似たようなもんだろ

**デフォルトの名無しさん** · 2022/08/18(木) 09:55:55.60

全然違うよ
ホスト言語で直接実装すりゃいいだけだからな
JITの場合も極限のパフォーマンスを求める静的型とは違ってホスト言語で書かれたランタイムの呼び出しを多用するのが普通だから、
インタプリタと大差ないし徐々にランタイムを使わないように改良していくアプローチが採れる