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

**デフォルトの名無しさん** · 2021/08/22(日) 08:59:03.31

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2021/10/31(日) 13:50:44.46

落ち着いていて品のよいさま。上品。優雅。エレガン。
（考え方や手法などが）簡潔で要を得たさま。手際のよいさま。明快なさま。

抽象度は高めたほうが優雅なのでは？

**デフォルトの名無しさん** · 2021/10/31(日) 13:56:01.91

昔のperlみたいにならないよう糖衣構文やそれに類するモノはどちらかに振った方がいい(エレガントな)こともある
結局は好みだけどなｗ

**デフォルトの名無しさん** · 2021/10/31(日) 14:23:30.67

中置記法をユーザー定義する構文糖を否定したやつは失敗
PythonとC++は少なくともその失敗をしなかった

**デフォルトの名無しさん** · 2021/10/31(日) 15:04:58.04

Nim言語では最近特定のunicode文字を2項演算子としてオーバーロードできるようになりました。
unicodeにある文字を演算子として使うのは文字を入力し辛いとか∪∨がアルファベットのUVと似ていて紛らわしいとかで反対派もいるようですが。

https://nim-lang.org/docs/manual.html#lexical-analysis-unicode-operators

proc `*` (x: Dollar, y: int): Dollar =
result = Dollar(int(x) * y)

みたいな感じで'*'演算子を定義できます。

https://nim-lang.org/docs/manual.html#procedures

**デフォルトの名無しさん** · 2021/10/31(日) 15:42:26.32

Nim言語にはtype classというのがあって、これを使うと特定の種類の型のみに限定されたgeneric procedureを簡単にかけます。
詳しくは
https://nim-lang.org/docs/manual.html#generics-type-classes

Nim言語ではprocedure/template/macroを呼び出す方法が複数あって、
foo(arg1, arg2)という普通の書き方に加えarg1.foo(arg2)というオブジェクト指向のメソッドぽく呼ぶMethod call syntaxと括弧を省略してコマンドラインぽくfoo arg1, arg2と書くcommand invocation syntaxがあります。
https://nim-lang.org/docs/manual.html#procedures-method-call-syntax
https://nim-lang.org/docs/manual.html#procedures-command-invocation-syntax

**デフォルトの名無しさん** · 2021/10/31(日) 15:50:59.21

実に表現豊かでエレガントですねぇ…☺

**デフォルトの名無しさん** · 2021/10/31(日) 16:18:17.43

>>353
type classは関数型言語Haskell発祥
そのNimのページを見る限りその貧弱なおもちゃ版に見える
例えばNimと同じ手続き型言語のRustのtraitも用語は違えどtype classなので比較するとわかりやすいが機能面でも型付け面でも強力

**デフォルトの名無しさん** · 2021/10/31(日) 17:04:32.64

>>348
言ってる事はその通り。goで構文上、覚える事の少なさは”非常に良い”が、上の簡潔で要を得たさまを借りて
言えば、finallyに相当するdeferはあるのに、?演算子が無いだけでerrが2番目というルールでifを多発させる。
これはRust/Swift/HaskellのResult/Option/Either標準伴うルールとほぼ同じだが、?演算子が無いだけで
if err != nil { return nil, err }を書かなくてはならない。あるいは(panicではなく)exceptionに対する
try/catch/finallyとも言い換えることが出来る

**デフォルトの名無しさん** · 2021/10/31(日) 17:32:36.81

https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
このドラフトでもRustの?演算子とかが言及されてるけど、そういうのはやっぱ欲しいわ

**デフォルトの名無しさん** · 2021/10/31(日) 18:15:22.28

演算子なら
∩∪⊕
あたりは欲しい

**デフォルトの名無しさん** · 2021/10/31(日) 18:21:20.58

>>355
最初に実装されたのはHaskellだがコンピュータサイエンスではもっと早く提唱されていた。NimはAdaから影響で
Haskellからも影響は当然あるが、範囲型の実装などはAdaから来ていると一般的には言われる。逆に、Rustは
機能面でHaskellのType classはフルセットでサポートしていない。traitは別の概念でType classを一部限定して
サポートしているに過ぎない。範囲型すら無いし、type c = a or cなんて出来ない、それとコンパイラ言語で
型付け面が強力では無い言語なんていまどきの言語なら珍しい、ランタイムが無くnative-compileなら尚更。

**デフォルトの名無しさん** · 2021/10/31(日) 18:42:57.86

Goに関して言えばユーザー定義のiteratorは何度もproposalされて撥ねられてるがいずれ入るちゃうかな？
演算子に関して言うならinや->,=== ,<>,instanceofなんていうものが世の中あるので、UTF-8/16で
関数名が書ける言語なら、uniform-func-callが出来る言語ならなおさら出来ないのはおかしかった

**デフォルトの名無しさん** · 2021/10/31(日) 20:07:49.45

>>359
typeのorならばRustでも色んな複数の方法で様々なアレンジ付けて出来るよ
例えばi32と&strのorをそのtraitを用いてするのも可能で
trait I32OrStr {}
impl I32OrStr for i32 {}
impl I32OrStr for &str {}

fn print<T: I32OrStr + std::fmt::Display>(x: T) {
　println!("{}", x);
}

fn main() {
　print(100);
　print("abc");
}
これでi32と&str以外の型は受け付けないprint()関数の出来上がり
あとtraitとimplの中身が{}で空なところにアレンジを書いたり

**デフォルトの名無しさん** · 2021/10/31(日) 20:24:12.66

例えば素朴な例だけどこんな感じ？
trait I32OrStr {
　fn info(&self) -> String;
}
impl I32OrStr for i32 {
　fn info(&self) -> String {
　　format!("{} <-- i32", self)
　}
}
impl I32OrStr for &str {
　fn info(&self) -> String {
　　format!("{} <-- &str", self)
　}
}

fn print<T: I32OrStr>(x: T) {
　println!("{}", x.info());
}

fn main() {
print(100);
print("abc");
}
これで>>361と同じくprint()関数はi32と&strしか受け付けないけど
実行結果は>>361と異なり型毎に別表示
100 <-- i32
abc <-- &str

**デフォルトの名無しさん** · 2021/10/31(日) 20:38:03.38

trait利用でなくもちろんenum利用で型のorも可能ですね
使い勝手が異なるのでRustでは両者を使い分け用いることが出来ます
enum I32OrStr<'a> {
　I32(i32),
　Str(&'a str),
}

fn print(x: I32OrStr) {
　match x {
　　I32OrStr::I32(n) => println!("i32: {}", n),
　　I32OrStr::Str(s) => println!("&str: {}", s),
　}
}

fn main() {
　let n = I32OrStr::I32(100);
　print(n);
　let s = I32OrStr::Str("abc");
　print(s);
}

**デフォルトの名無しさん** · 2021/10/31(日) 22:21:09.61

>>356
それくらい書けやとしか思わんわ。
まあパターンマッチで変なnullチェック減らすとかは入れてもいいと思うが。

**デフォルトの名無しさん** · 2021/10/31(日) 23:58:11.44

rustってデフォルトだと共用体みたいな形になるんだっけ？

**デフォルトの名無しさん** · 2021/11/01(月) 08:07:15.03

だからそれはtraitでありtype classじゃないでしょ。どっちが”貧弱なおもちゃ”やねん。こんな単純な事を
表現するためにクダラナイ事を何度も何行も貼り付けるなよ。もう一つについてはTagged Unionだが、Adaも
Swift/Nim/Pythonも出来るし、”両者を使い分け用いる”なんて必要ない。そもそも単純に書こうとしたら
or表現や、Typescriptのようにtype C = A | B;部分型だし、このように表現するのが限りなく一般的で
一行でシンプルです。Rust唯一教徒の話は回りくどい上にキモ過ぎる、別にRustそのものを否定している訳じゃ
無いし、traitは他にあまり無い十分に柔軟性がある特性なんだから、奇妙な信仰的な推し方をすんな

**デフォルトの名無しさん** · 2021/11/01(月) 08:14:17.55

go2もgenericsと関連して、Tagged union的なType set/Type list/Sum typeが入るはず

**デフォルトの名無しさん** · 2021/11/01(月) 10:40:50.02

めっちゃ早(ry

**デフォルトの名無しさん** · 2021/11/01(月) 11:40:40.03

趣味・嗜好は昇華して信仰になる！
実際に共用体になるのとポインタだけ入るのを同じに分類したら何でもありな気はするｗ

**デフォルトの名無しさん** · 2021/11/01(月) 23:50:22.01

>>366
それは君の理解が浅く、君が間違っている。

まず、Rustのtraitはいわゆるtraitとは異なる。
つまりシェリルのtrait論文に従う他の言語のtraitとは異なっており、
複数traitでメソッドの名前衝突重複が起きたときに、メソッドの排除や名前の変更利用などのtraitが満たす条件を備えていない。
一方でRustのtraitでは重複自体は許して、メソッド呼び出しは一意性がないため許さず、関連関数呼び出しが自由に許される。

次に、Rustのtraitはいわゆる(Haskellの)type classに基本的な部分で合致している。
一番重要なところでいうと、Rustのtrait境界はHaskellのtype class制約である。
もちろん一般的なtraitにはこのような概念機能はない。
つまりRustのtraitはtraitではなくtype classであることがわかっていただけると思う。きちんと理解しているならば。

**デフォルトの名無しさん** · 2021/11/02(火) 01:20:08.88

そもそもB | Cのようなad-hocな型制約をRust開発者が好まないというだけのことだと思う
関数オーバーロードもC++のテンプレート特殊化みたいなのも無いし

**デフォルトの名無しさん** · 2021/11/02(火) 01:42:04.85

はあ…基地外が一生懸命調べて反論してるって感じだな、何が論文だ？気持ち悪りぃ

”一番重要なところでいうと、Rustのtrait境界はHaskellのtype class制約である”
Type classは制約だけではありません、アドホック多相を実現するための機能です。概念だけなら20年前の
Haskellから影響を受けているのは近代的な言語なら当然ですが、RustのtraitはHaskellのType classではなく
実装はSubtypingです。そもそも”貧弱なおもちゃ”に負けてるRange typeとかSum typeとか、Typescriptに
すらあるのに無い事、無理やりコードを書いて実現しようと自己弁護している事、Rustの書き手が減るような
非常に醜い弁護行為なので止めなさい

”つまりRustのtraitはtraitではなくtype classであることがわかっていただけると思う”
日本語でも、英語でも理解してますか？他の言語のtraitとは同じだと誰も主張していませんよ？そもそもこれも
因果関係が逆転しています。type classの「ほんの一部」を実現するために(rustの）traitを用いているだけです。

きちんと日本語と英語を理解しているならば、このような「間違い」は起きないはずです。それは君が理解が
難癖を付けたい基地外であり、おまえのような態度が気持ち悪い奴らRustの発展を阻害しているのです。

**デフォルトの名無しさん** · 2021/11/02(火) 02:02:23.69

ググってみたがRustのtraitは普通のtraitではない話がたくさんあるな
あとRustのtraitはHaskellの型クラスだという話も多数あるな
世間での認識は>>370で合ってるんじゃね？

**デフォルトの名無しさん** · 2021/11/02(火) 02:15:11.25

ID変えてまた自己弁護、市ね基地外

**デフォルトの名無しさん** · 2021/11/02(火) 07:36:44.59

ようはCommon Lispみたいなマクロ使える言語が最強って事だろ？

**デフォルトの名無しさん** · 2021/11/02(火) 08:27:57.62

>>372
Rustで実装できない具体例を挙げたら？
そっちの方が早い。

**デフォルトの名無しさん** · 2021/11/02(火) 08:34:53.92

>>375
せや、あんたが優勝や

**デフォルトの名無しさん** · 2021/11/02(火) 08:39:57.46

このクズは誰も言って無い事を言い出す、「他の言語のtraitとは同じ」「Rustで実装できない」
こんなことは誰も言ってない。
おまえはさ、Rustの発展にも、会社にも、社会にも邪魔だから消えろよ？おまえみたいのは、まだ技術が
浅く新しい人が入ってくる障害だからね

**デフォルトの名無しさん** · 2021/11/02(火) 10:07:28.88

>>378
お前は>>372？
じゃあ、「無理やりコードを書いて実現」についてのHaskellとの具体的なコードの比較でいいよ。
あと、「type classの「ほんの一部」を実現するために(rustの）traitを用いているだけです。」について、Rustのtraitで実装できないtype classのHaskell実装例。

まずはそれについて>>370に反論させりゃいい。
コードもないんじゃ傍から見ててつまらんよ。

**デフォルトの名無しさん** · 2021/11/02(火) 11:09:50.76

人の話を聞くのは正しいことかもしれないが
つまらない話を禁止したり面白い話を強制するぐらいなら人の話を聞かない方が正しい

**デフォルトの名無しさん** · 2021/11/02(火) 11:15:37.18

両方とも気持ち悪いなと思ってたら
もう一人気持ち悪いのが出てきたww
いつもの次世代wスレ

**デフォルトの名無しさん** · 2021/11/02(火) 11:48:12.43

また違う人物のふりして出現か、傍から見てる人が「お前は」なんてイキナリ怒り心頭顔真っ赤で言うかよ。
おめーがつまんねえから

**デフォルトの名無しさん** · 2021/11/02(火) 12:12:25.90

C++のtemplate引数はダックタイピング
ダックタイピングは気持ち悪い
HaskellとRustは気持ち悪くない

マクロ引数の問題はtemplate引数よりも更に気持ち悪い

**デフォルトの名無しさん** · 2021/11/02(火) 12:29:54.01

Haskellを悪く言うやつを見たことがない
もう全部Haskellでいいよ

**デフォルトの名無しさん** · 2021/11/02(火) 13:43:18.32

C++もね、conceptでだいぶマシになったんだけどね
そもそもどれだけの環境でC++20が使えるんだという話をされるとぐうの音も出なくなる

**デフォルトの名無しさん** · 2021/11/02(火) 14:57:01.19

>>384
俺は毎日のように悪く言ってるよ
数学オタクが作った非実用的な言語だってな

**デフォルトの名無しさん** · 2021/11/02(火) 15:36:03.35

3人いようが4人いようがそれ以上でも
描き込み全部気持ち悪い事実は変わらない

**デフォルトの名無しさん** · 2021/11/02(火) 16:14:12.44

お前らが気持ち悪さに敏感なのは良いことだと思う
気持ち悪さの応酬をして平気なツラしてるような地獄のスレもある

**デフォルトの名無しさん** · 2021/11/02(火) 18:13:46.42

Nim言語にもconceptがあります。(まだexperimentalだけど)
https://nim-lang.org/docs/manual_experimental.html#concepts

conceptやtype classを使ってgenerics(c++のtemplateに相当)の引数に指定できる型を制限すれば気持ち悪さを軽減できるか思います。

けどNimのseq[T](C++のstd:::vector<T>、Rustのstd::Vec<T>に相当)のようなコンテナ型にはコピー可能な型なら何でも指定できるわけですが、こういうのが気持ち悪いと言われても指定できる型を限定すれば不便になるだけだと思うのですが。

**デフォルトの名無しさん** · 2021/11/02(火) 22:59:17.06

Nimの並列ってどうなん？何か特徴有ったりする？

**デフォルトの名無しさん** · 2021/11/03(水) 11:54:22.69

ポケモンしか見つからんのですが

**デフォルトの名無しさん** · 2021/11/03(水) 12:42:45.74

キミに決め・・・られないｗ

**デフォルトの名無しさん** · 2021/11/03(水) 15:41:03.34

言語が気持ち悪いんじゃない
俺も含めおまいらが全員気持ち悪いんです。次世代言語と銘打ってるのにあの言語はこの機能がないからゴミだ
あの言語は（高尚な）Haskellが元だ、などなど。ポジティブな意見ではなく、ネガティブ丸出し全開なんです。

RFC for anonymous variant types, a minimal ad-hoc sum type
https://github.com/rust-lang/rfcs/pull/2587

高速ゼロコスト言語の次世代言語Rustだってこういう提案はされて、別言語の悪口なんて出てこないんです

**デフォルトの名無しさん** · 2021/11/03(水) 15:54:38.31

ネガってるのとそのレスに極端な反応してるのは他人を基地外呼ばわりしてる1人しかいないと思うんだけどｗ
他の人は他言語と正確に比較してるだけで否定的な論調もなく他人の趣味・嗜好を尊重してるｗ

**デフォルトの名無しさん** · 2021/11/03(水) 21:11:03.58

バグ報告したら不正アクセスだって言われるのと似たような現象

**デフォルトの名無しさん** · 2021/11/03(水) 23:58:41.87

まあ仕事で使う上では言語の強みより弱みや落とし穴を知っとく方が価値あるわな。
どうせ選ぶ権利ない場合がほとんどだし。
その辺が学生、アマチュアなんかとの差だろうね。

**デフォルトの名無しさん** · 2021/11/04(木) 03:09:20.83

>>390
Nimでは競合状態を防ぐためにスレッド毎にガーベージコレクタで管理されたヒープメモリを持っていて、
グローバル変数以外スレッド間で共有できなくなっています。
そのおかげでガーベージコレクタが効率よく動きます。
コンパイル時にスレッド間でヒープメモリを共有していないかチェックします。

詳しくはこちら
nim-lang.org/docs/manual.html#threads

Channelを使ってスレッド間でデータのやりとりができます。
nim-lang.org/docs/channels_builtin.html

試験段階ですがthreadpoolモジュールにあるParallelとSpawnを使って並列処理できます。
nim-lang.org/docs/manual_experimental.html#parallel-amp-spawn
nim-lang.org/docs/threadpool.html

Nimの標準ライブラリじゃないのですがWeaveというパフォーマンス重視なライブラリもあります。
github.com/mratsim/weave

**デフォルトの名無しさん** · 2021/11/04(木) 07:19:03.96

>>397
スドップザワールドもスレッド単位でしか起こらんということなん？

**デフォルトの名無しさん** · 2021/11/04(木) 08:00:34.54

>>385
現場で使えわせてくれるのはあと2,3年はかかりそうだな

**デフォルトの名無しさん** · 2021/11/04(木) 08:47:03.06

>>398
基本的にはストップザワールドは発生しないマーク＆スイープガーベージコレクタが今はデフォルト(refc)
ガーベージコレクタを選べるのでARC(rustと同じ)を選べばストップザワールドは無いが循環参照はリークする。
(これはrustも同じ）循環参照をガーベージコレクションするARC+サイクルコレクターがORCなって、ストップ
は起こらないが、少しパフォーマンスが落ちる。C系と相性の良いboehmとか、dllを作ってgoとリンクさせる
ようならストップザワールドが発生するガーベージコレクタを使用する場合がある

Multi-paradigm Memory Management Strategies（中段当たりの表）
https://nim-lang.org/docs/gc.html

**デフォルトの名無しさん** · 2021/11/04(木) 10:57:37.34

何を見ても聞いてもnimには一切興味がわかない・・・
なんというか特徴がなさすぎる

**デフォルトの名無しさん** · 2021/11/04(木) 11:41:59.42

Haskellとかもそうだけどオタクの中のオタクの間だけで持て囃されてる言語には近寄らない方が吉

**デフォルトの名無しさん** · 2021/11/04(木) 12:00:51.59

Rustこそ至高の言語、NimとHaskellなんて糞、GoはまあGoogleがやってるから認めるけど
言語的にはジェネリクスも無い90年代の時代遅れ
NimだとかHaskellだとか、糞気持ち悪いオタクの匂いがする。どっちもゴミ
SwiftとKotlin、そしてTypeScriptともにスマホで使う

**デフォルトの名無しさん** · 2021/11/04(木) 12:19:18.72

rustはこれからjavaになるんだろ

**デフォルトの名無しさん** · 2021/11/04(木) 13:07:01.54

>>403
Nimも悪くないとは思うけど
欲しい基本がまだexperimentalなど多いのと人口の少なさ
あと競合しているRustがコンパイル通ればメモリ安全性保証してるので
結論はRustでいいじゃんとなりました

**デフォルトの名無しさん** · 2021/11/04(木) 13:17:36.87

Goが良いのは、関連エコシステムと、あと強いていうなら並列処理らへんぐらいかな。
プログラミング言語としてはさすがにしょぼすぎるけど、エコシステムが優れてるからなんだかんだ便利。
PythonとかJavaScriptとかはエコシステムが最強な言語の一つだよね。
逆にD言語とかはエコシステムがウンコすぎて使い物にならなかった。

**デフォルトの名無しさん** · 2021/11/04(木) 13:19:04.19

Nimはなんか中庸って感じがする
そこにピッタリはまる人にはいいんだろうけど
もっと楽に書きたい人はGo、ちゃんと書きたい人はRustに流れてしまって
あまりユーザが増えないのではないかな

**デフォルトの名無しさん** · 2021/11/04(木) 15:00:22.37

オタク臭いやつと臭くないやつの違いは一般人でもわかる
TypescriptとGoとNimの違いがわかるのは重度のオタクだけだろ

**デフォルトの名無しさん** · 2021/11/04(木) 15:11:34.22

やっぱ言語の普及には有名企業の後押しがいるんか？でもrustってなんか後押しあったっけ？
まあ案件レベルだと全然ないけどｗ

**デフォルトの名無しさん** · 2021/11/04(木) 15:13:41.91

Nim少し見てみたけどインデントか、ちょっと苦手かも

**デフォルトの名無しさん** · 2021/11/04(木) 15:18:21.88

大企業の後押しは必須ではないだろうけど、後押しあると強い、というか、やっぱエコシステムが育ちやすいと思う。
すぐに潰されない言語だ、って思って他の企業とかも投資できるからかな。
TypeScriptが人気あるせいか、Dartはなんかイマイチ広まりきれてない感じだったけどね。

Rustは新規ミドルウェアを作るような現場では需要あるんじゃないの？

**デフォルトの名無しさん** · 2021/11/04(木) 15:26:36.67

いまRust推しの大企業といえばAmazonだな
MozillaからリストラされたRustコミッタを相当取り込んでるし
影響力が強すぎるんじゃないかと不安視されるくらい

**デフォルトの名無しさん** · 2021/11/04(木) 15:26:54.42

これは他のコンパイル言語にはあまりない特徴だと思うけど、Nim言語はスクリプト言語のように使うこともできる。
Nimはコンパイル時に実行されるコードをNimに埋め込まれたvirtual machine上で実行するんだが
このVMを他の用途にも使うことができる。

コンパイルに使う設定ファイルやnimble(RustのCargoのようなもの)ファイルをNimScriptで記述できる。
nim-lang.org/docs/nims.html
github.com/nim-lang/nimble

Nimのコードを拡張子がnimsとなるようにファイルに保存してnim myscript.nimsと実行すれば
実行ファイルを生成せずに実行される。
NimScriptにはFFIが使えないとか制限があるがファイル操作や他の実行ファイルを呼ぶことができるので
shellスクリプトやバッチファイルの代わりに使うことができる。

C/C++だとプログラムにスクリプト言語を埋め込むときはPythonとかLuaを使うことが多いと思うけど
Nim言語ではNimScriptを埋め込むことが可能。
github.com/beef331/nimscripter

**デフォルトの名無しさん** · 2021/11/04(木) 15:32:39.45

>>410
どの言語を書く時でも基本的にはインデントするから
インデントでコードブロックを作ることによってソースコードの中に
{}とか;が頻繁にでてこないようにしたほうがソースコードがすっきりして読みやすくなると思うんだけどな。

**デフォルトの名無しさん** · 2021/11/04(木) 15:46:29.06

>>414
ルールで言うならyamlみたいなインデント or カッコの両対応がいいんだけどねぇ。そんなの無いけど。

**デフォルトの名無しさん** · 2021/11/04(木) 15:47:23.54

行頭に } って書いてあると終わった感がある

**デフォルトの名無しさん** · 2021/11/04(木) 15:51:50.87

Rubyみたいな do end もそんなに悪くなかったし、エディタのサポートがあれば慣れの問題かなあ、って気がしてしまう

**デフォルトの名無しさん** · 2021/11/04(木) 16:30:26.61

>>414
それをすっきりして読みやすいと思うか、必要な情報が欠落していて読みにくいと思うかは個人差あると思う
個人的にはインデントの戻り量が視覚的に判断しづらいから } がないと読みづらく感じる

**デフォルトの名無しさん** · 2021/11/04(木) 16:40:09.48

int hoge = 1;
int hage = 2;
if ... {
　　hoge += 3;
hage = 4;
}
理論上は見た目とコンピューター的なパース処理を一致させる考えがPythonやNim、CoffeeScriptなどの
オフサイドルールという書き方。
上記の例でCなどから、主流で余分な空白を無視して波括弧 { と } でブロックを表すという記法が、C#や
Java、Rust、Javascriptなど。もう１つは、begin-endでブロック的なスコープを表す記法で、これは
Pascal/Delphi、Ruby、PL/SQL・TSQLなど。他は純関数言語でErlangやHaskellなどはこの限りではない。

Cなどの記法は、空白あるいはタブがどのような形でも{}が対応していて、;が１手続きの終わりであり
プログラマの好みによって、字下げ・字上げ・空白することが可能であるという利点がある。しかしながら
上のように書く人は居ない。{}の対応するかっこを上下位置で揃える古いK&R的な書き方をする人はいるが
近年のgolangのように、きっちりフォーマットする（goだとエラーになる場合もある）

Python的な見た目に拒否感が起こる人は、「空白字下げの入れ忘れがバグにつながるのでは？」と言う。
for ... :
　　hoge += 6
hage = 7
しかしながら、上のように書く人は存在するがあまり読みづらく、ループに入れるなら字下げすべきだし
入れないのであれば、forの終わりに１行空行を入れる。Rubyは厳密にはxxx-endだけではなく、{}も
あって意味が違うのだが長くなりすぎるので説明しない。
もう１つはIDEなどがソースコードを勝手に整形するので、スペースではない明確な表示文字で区切りたい
という人もいる。当然このようなことを言い出したらキリがないが、最終的には好みで言語を選ぶわけで
無く仕事なら無条件であり、慈悲も和解もない。

**デフォルトの名無しさん** · 2021/11/04(木) 16:51:58.52

>>414
インデントはフォーマッターに任せる温い環境に慣れすぎて自分でやるのは辛ぽよ

**デフォルトの名無しさん** · 2021/11/04(木) 17:02:13.15

そしてなぜPythonのようなCとC++の、ある意味で伝統を受け継がない物が出来たかと言えば演算子の順序で
a = b + c * dと書いた場合、c * d が優先されるのだが、ニワカは a = b + ( c * d )と書いたりする。
これをプログラマは冗長、あるいはダサいと言う風潮が出来て、「余計なカッコはカッコ悪い」となった。

ここから、whileやifに普通の丸カッコを付けない言語が多くなる。v = if true { 5 } else { 6 };
このように評価式にはtrueで、()を付けない、これが長い評価式の行になったとしても同じ

いわばカッコ言語と称される言語は、Pythonから見るとカッコ（悪い）言語になり、逆に伝統的なプログラマから
見ると、空白がブロックを左右するいい加減な言語に見える。よって又しても慈悲も和解もない

**デフォルトの名無しさん** · 2021/11/04(木) 17:14:28.06

{ } な言語ばかりやってきたので
インデント言語について素朴な質問です

スコープブロックはどのように作るのですか？
例えばスコープブロック作成のために数行だけを { } の中に閉じ込めたりするのですが
インデント言語では括弧も何もなく数行だけを深くインデントするのですか？

**デフォルトの名無しさん** · 2021/11/04(木) 17:15:03.57

>>406
>>411
NimはC, C++, pythonで書かれた豊富なライブラリを簡単に使うことができるようにすることで
ライブラリの少なさを補っている。
Cのライブラリを使える言語は結構あるけどNimはバックエンドにC++コンパイラを使うこともできるので
C++で書かれたライブラリも使うことができる。

c2nimを使えばC/C++のヘッダーファイルを自動的にNimのコードに変換してくれる。
C/C++のコードを完全にNimのコードに変換できるわけではないが
NimからC/C++のコードを呼び出すのに必要なコードを出してくれる。
github.com/nim-lang/c2nim

ここにあるコードのようにimportcppプラグマを使えば
C++のstd::mapやstd::vectorのようなテンプレートクラスをNimのgenericsのように使うことも可能。
nim-lang.org/docs/manual.html#importcpp-pragma-importcpp-for-objects

NimからPythonの関数を読んだりNimでPythonモジュールを作れるようにするライブラリ
github.com/yglukhov/nimpy

Nimのコードをマクロを使ってコンパイル時にGLSLのコードに変換するライブラリ
github.com/treeform/shady

**デフォルトの名無しさん** · 2021/11/04(木) 17:36:48.75

>>422
Pythonだと、PEP340という、Anonymous Block Statementsの提案がなされていたが
block expr as x: # expr as x はおそらく省略できる
　　...
このように書ける提案だったがリジェクトされて、PEP343となりwithブロックになった。
with open(path) as f:
　　...
ほかの言語だとこのblockという無名または名前付きのスコープが作れるものが多いと思う
block "A sealed": # 文字列は名前で省略できる
　　...
そうはいっても、以下のようにすればブロックは勝手にできるあまり意味はない。どこかでBLOCK = true
if BLOCK:
　　...

**デフォルトの名無しさん** · 2021/11/04(木) 17:40:02.16

他にもlabel（？だったか）として名前付きのものもあったな、これは、多重のforなどのbreakで名前が指定できる

**デフォルトの名無しさん** · 2021/11/04(木) 17:40:29.24

bindingはどの言語でもあるし簡単に作れるよ
ただ純正コードで書くのと同じくらい適切に運用させるのが困難な場合が多いので、誰もそれが簡単だとは言わない
個人的には正直nimアピールいらんｗ何か書かれる度にどんどんnimから離れて行きたくなるｗ

**デフォルトの名無しさん** · 2021/11/04(木) 17:40:46.86

>>422
Nimではblock文/block式というのがあります。
nim-lang.org/docs/manual.html#statements-and-expressions-block-statement
nim-lang.org/docs/manual.html#statements-and-expressions-block-expression

変数aはblock:の下のインデントされたブロッグ内のスコープ内でのみ使えます。
block:
　　let a = 1
　　echo a

こんな感じでblockに名前を付けてbreak文を使っていっきにblockから抜けることもできます。
var found = false
block myblock:
　　for i in 0..3:
　　　　for j in 0..3:
　　　　　　if a[j][i] == 7:
　　　　　　　found = true
　　　　　　　break myblock #forループの上にあるmyblockから抜ける。
echo found

block式を使うとblock文と同じように新しいスコープを作りますがblock内の最後の式がblock式の値になります。
let a = block:
　　var fib = @[0, 1]
　　for i in 0..10:
　　　　fib.add fib[^1] + fib[^2]
　　fib # fibの値がこのblock式の値になってaに代入される。
echo a # @[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144] が出力される

**デフォルトの名無しさん** · 2021/11/04(木) 17:44:36.59

nimアピールすごいな。
宣伝したいならQiitaとかでいっぱい記事書いたほうがいいんじゃないかな・・・。

**デフォルトの名無しさん** · 2021/11/04(木) 17:50:32.91

言語なんて日本だけで流行っても、しょーがないし、流行るとしたら海外で流行らないと、Pythonだって
海外で流行っていて、Rubyの作者が日本人だから、日本ではRubyというかRoRが一色になりかけたのに
Pythonなんて誰もやってなかった（言い杉か）

**デフォルトの名無しさん** · 2021/11/04(木) 17:54:52.55

pythonで
a = b*c + d
というスペースの空け方を推奨してて、なるほどと思った

**デフォルトの名無しさん** · 2021/11/04(木) 18:01:05.24

>>427
ブロックも式になって最後の値を返すとか
ブロックで変数スコープがあらたにつくられるとか
Rustなどと一緒だね

あとはRustみたいに変数スコープブロックを抜けると(または変数のライフタイムが尽きると)
ファイルオープン変数だった場合に自動クローズとかもあるのかな？
具体的には、Pythonだとwith、C#だとusing、Goだとdefer、などそれそれ必要なところ
Rustはそういう特殊構文なくて
変数が解放されると自動closeされる

**デフォルトの名無しさん** · 2021/11/04(木) 18:13:51.03

>>431
defer文でcloseできます。
nim-lang.org/docs/manual.html#exception-handling-defer-statement

コードを書けばデストラクタからcloseできるようになるけどNimにデストラクタができたのが最近なんで
標準ライブラリのFileはdefer文使うか自分でcloseを呼ぶ必要があります。

**デフォルトの名無しさん** · 2021/11/04(木) 18:30:25.81

Rustはファイルディスクリプタ類を関数を超えて持ち回ったり複雑化しても使い終わると即座に確実にクローズが自動的にされるのが凄いよね

**デフォルトの名無しさん** · 2021/11/04(木) 18:37:46.92

それは標準ライブラリがDropトレイとで成り立ってるだけの話で、openとcloseが完全対になるような
リソースならそれで良いがBufWriterの場合とかflushしなければならないし、何回もopen呼んでも良い
ようなリソース管理は、結局は自分で実装しないとならない

**デフォルトの名無しさん** · 2021/11/04(木) 19:00:18.43

>>433
即座に着実安全にメモリ解放が自動でなされるRustにとって
その程度はオマケのついでの楽勝なだけにすぎない

**デフォルトの名無しさん** · 2021/11/04(木) 19:33:56.36

その分とっつきにくいけどな

**デフォルトの名無しさん** · 2021/11/04(木) 19:53:06.80

>>436
え？他の言語よりはわかりやすくてとっつきやすい

**デフォルトの名無しさん** · 2021/11/04(木) 20:10:30.05

「rust 難しい」とかで検索すれば出てくるけど、残念ながら世の人々はそうは思わんのだよ
比較的進歩的な人でもそういう意見をよく聞くし、所有権は理解しないわけにいかない基礎だから端折れない

逆にgoではほとんどそういうことがない

**デフォルトの名無しさん** · 2021/11/04(木) 20:22:55.80

Goはガベージコレクション言語だから比較の土俵が違うような
さらにGoはプログラミング言語として様々な機能を失いすぎてプログラミングしにくいのが辛いですね

**デフォルトの名無しさん** · 2021/11/04(木) 20:26:36.52

比較的守備範囲の近い、とっつきやすい言語の例ｗ

**デフォルトの名無しさん** · 2021/11/04(木) 20:33:45.40

失い過ぎたｗ
意図して実装してないだけだがｗ

**デフォルトの名無しさん** · 2021/11/04(木) 20:42:10.69

>>440
Goは守備範囲が狭すぎて違う
Rustの元々の守備範囲はC/C++が使われている領域
その領域に加えてGC無くメモリ安全性の保証によりJavaなどの置き換えにも使われつつある
さらに加えてイテレータ等の現代的なプログラミングスタイルがメインとなってコーディングしやすいためスクリプト言語を含めた幅広い方面からの移行/兼用が起きている
いずれもGoは満たせない要件

**デフォルトの名無しさん** · 2021/11/04(木) 20:55:34.08

だからこれからのコーディングの奴隷はRustで決まりってことなんだろ

**デフォルトの名無しさん** · 2021/11/04(木) 21:00:15.23

goとrustならrustの方が守備範囲狭いよｗ
ひとえに難しいからｗ

OS周りならC/C++でいいし
現状ではweb周りのごくごく一部の超高速領域を除きrustには置き換わっていない
javaからの置き換えならgoでいい

**デフォルトの名無しさん** · 2021/11/04(木) 21:09:43.64

>>442
その3種類ともGoは対象外なことに驚きました
実はGoとRustは領域あまり被っていなくて競合していないのかもしれませんね

**デフォルトの名無しさん** · 2021/11/04(木) 21:16:55.71

他rust向きの領域だとdatabaseかなぁ・・・
ただ既存のDBを置き換えるのはなかなか厳しそうｗ
何かに特化したやつならいいかもねｗ

**デフォルトの名無しさん** · 2021/11/04(木) 21:31:58.67

RustがJavaの代わりってマジか
Scalaみたいな負債の再来か

**デフォルトの名無しさん** · 2021/11/04(木) 21:36:42.56

>>447
Meta (旧Facebook)が基幹システムをJavaからRustへ移行した
IT業界ではそういう流れ