次世代言語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/08/22(日) 09:45:11.46

スレタイの言語はNim以外はどれも現役世代だね

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

永遠に次世代？

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

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

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

>>4
このコピペ難読性が高い

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

>>4
NimはGCがあるからC++やRustの立ち位置には立てないよ

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

NimやるならGoでよくね？ってなる

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

▼スレタイランキング
1位：Rust（21回 Part1～）
2位：Go（15回 Part1～）
3位：Kotolin（14回 Part4～）
4位：TypeScript（14回 Part7～）
5位：Swift（10回 Part7～）
6位：Haskell（7回 Part7～）
7位：Scale（5回 Part1～）
8位：Elixir（4回 Part1～）
9位：Dart（3回 Part9～）
10位：Julia（3回 Part14～）
11位：Erlang（2回 Part1～）
12位：Nim（2回 Part21～）
13位：Crystal（1回 Part14～）
14位：Bosque（1回 Part17～）
15位：V（1回 Part19～）

**ハノン** ◆QZaw55cn4c · 2021/08/22(日) 12:03:30.88

>>8
説明を求めます

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

>>9
このスレのスレタイに入ってる言語はスレを立てる人が次世代だと思う言語を自由に入れていい
このランキングはスレタイに入った言語を集計したもの
○○回は入った回数、Part○～は初出のスレ番号

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

>>970

マクロのシンタックスを別で覚える必要がない
Rust のマクロは構文が全く変わってしまいます。
そしてそれは脳が全力で受付を拒否する素敵な仕上がりとなっております。
公式で自ら「マクロベースのコードの欠点は、組み込みルールの少なさに
由来するそのコードの理解のしづらさです。」と言いのけちゃう代物で
「なんじゃそりゃ」と言う言葉しか出ません。

Nim は構文がそのまま使えます。なので強力なマクロを使いこなすための
障壁の低さは比べ物になりません。

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

>>7
NimのライバルはGoやね

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

>>970

Rust の良いところ
さすがに Rust を批判ばかりしていては公平性に欠ける報道となり官邸から怒られます。
Rust にも良いところはあります。

fn <- 短い！

proc <- 長い！

これはメリットですよ。タイプが2回ずつ減るのは素敵なことです。
しっかしこれだけ馬鹿げた冗長さを押し付けてくる言語のくせして、
何故ここだけすっきりしているのやらさっぱり意味がわからないです。
あ、結局ディスってもうた・・・。

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

>>13
まともなプログラマーはタイプ数を気にすることはない
それよりも目的毎の機能性質で使い分ける
functionと長い言語もあればCやshのように0文字の言語もあるがタイプ数で何かを決めることはない

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

Cで充分

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

func を fn とするだけで開発効率が上がると思ってとかどうしようもない馬鹿だろ。

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

Nimの最新のガベージコレクタARC(Automatic Reference Counting)は参照カウンタ方式でRustのRc<T>やC++のstd::shared_ptr<T>と似たようなもの。
C++のshared_ptrと違ってカウンタはatomic intじゃないので複数スレッドから共有はできないけど高速にカウントを増減できる。
Move semanticsによって余計なコピーが発生しない。
変数が不要にったところに自動的にデストラクタが挿入されるのでメモリが解放されるタイミングは決定論的に決まる。
(他の言語のガベージコレクタのように実行するたびに違うタイミングでメモリが解放されることはない)

前スレで勘違いされていたけど、NimのView typesやRustのボローチェッカーって
スタックから消された変数とか解放されたヒープを間違って参照したり書き込んだりを
防ぐものでメモリリークを防ぐものではない。
Nimはガーベージコレクタ、Rustはスコープから出たらメモリ解放するとか参照カウンタを使って
メモリリークしないようにしている。

NimでARCを使っておけばガベージコレクタのコストは参照カウントの増減だけなので
パフォーマンスに影響することは殆どない。
NimをGC無しで使う必要性はほんどない。

Nimを組み込みに使っている人もいる。

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

NimのARCに関する情報
nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html

Nimを組み込みに使っているプロジェクト
github.com/PMunch/badger
github.com/exelotl/natu
github.com/clj/nim-esp8266-examples

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

結論
NimをGC無しにすることは不可能
つまりC/C++/Rustの代わりに用いることはできない

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

Cはスタックを無しにすることは不可能
つまりアセンブラの代わりに用いることはできない

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

>>17
嘘つき
参照カウンタ方式はコストが高いので、
Rustでは必要最小限の部分でのみ、プログラマーが明示的にRc型(Reference counter型)を指定した時だけ使われます。
Rustでは通常時は参照カウンタなんて使われません。もっと高速に動作します。