次世代言語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では通常時は参照カウンタなんて使われません。もっと高速に動作します。

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

>>4

技術書典に出会っていなかったら俺はNimをさわってないと思う

背景
俺たち「そろそろ技術書典に参戦するか」
俺たち「何書く？」
俺たち「マイナー言語を触ってみよう。言語選択は早い者勝ちね」
ワイ「(マイナーの定義はさておき)Nimでオナシャス」
ワイ「(アドカレあるし、記事まとめておくかぁ...)」

Nimとは？
Nim はアンドレアス・ランプフ氏によって設計・開発された命令型、マルチパラダイム、
コンパイル言語という特徴を持つプログラミング言語です。

アンドレアス・ランプフ氏は3DICC社に所属するエンジニアです。彼はNim開発以前に様々
な言語を触っていたようです。が、どの言語も満足せず、自身で作成することにしたようです。
それがNimプロジェクトの始まりで、2005年頃のようでした。

当初NiｍはNimrod(旧約聖書の登場人物)という名前でしたが、マーケティング上の理由から
2014年12月29日にリリースされたバージョン 0.10.2 からNimに変更されました。

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

Nim ARCは全て参照カウンタ方式になってしまうからパフォーマンスに影響が出て不利だね

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

Rustでグラフ構造を作れないとか言いそうな奴に
ARCでグラフを作らせたら駄目だろ常識的に考えて

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

>>20
ちょっと意味が分からない

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

つまりレジスタだけ使ってのプログラムってことだろ。
そんなんやる必要ほとんどないが。

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

本当に知らない人のために言うと、全部ブログ記事のパクリ
なので相手にしてもマトモなレスが返ってこない。無視で良いよ

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

>>4

Nimの特徴
直感的でわかりやすいシンタックス
公式サイトの記載からNimの特徴を見てみましょう。

以下は公式サイトに掲載されているNimのコード例です。

Nimの最初の特徴して挙げられているのが、そのシンタックスで、曰く「直感的でわかりやすい」とのことです。
Python(のインデントを含めた多くの特徴)やPascalを参考にしているらしいので似ていると思いますが、シンプルですね。

import strformat
type
Person = object
name*: string # Field is exported using `*`.
age: Natural # Natural type ensures the age is positive.

var people = [
Person(name: "John", age: 45),
Person(name: "Kate", age: 30)
]

for person in people:
# Type-safe string interpolation.
echo(fmt"{person.name} is {person.age} years old")

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

>>26
アセンブラだってスタック使うでしょ？

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

>>29
組込みだとRAMチェックが終わるまではスタック使わないとか普通にあったりする

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

>>30
ほー、なるほどね
だからって>20はおかしいよね

**デフォルトの名無しさん** · 2021/08/23(月) 00:53:35.51

アセンブラは型がない
アセンブラだけで作ったライブラリも可読性のためにはCの型を宣言する
宣言したらもうCのライブラリとして利用可能にするだろ常識的に

つまり旧世代言語のコードを減らすとかいうおかしな目的意識の代わりに
ライブラリを増やすという適切な意図がある

**デフォルトの名無しさん** · 2021/08/23(月) 01:09:17.02

そこはCもC++もRustも同じでアセンブリ含めて相互に呼び出し可能
だったらコンパイル通った時点でメモリ安全性を保証できるRustで基本的に書いてどうしても必要な部分のみアセンブリというのが現在の流れ

**デフォルトの名無しさん** · 2021/08/23(月) 03:28:42.97

型付けアセンブリ言語という研究かなり昔にあったよね？
どうなったの

**デフォルトの名無しさん** · 2021/08/23(月) 05:35:18.87

>>31
おかしくないよ、そういうコードはアセンブラでないと書けないから

**ハノン** ◆QZaw55cn4c · 2021/08/23(月) 05:39:50.18

一応 MASM には型はありますが？

**デフォルトの名無しさん** · 2021/08/23(月) 06:59:34.18

>>34
masm とかでも構造体を定義できたりするけどやればやるほどC言語で良くね？とかなりがち

**デフォルトの名無しさん** · 2021/08/23(月) 13:47:20.63

どうせWEB屋が好きな/使ってみたい言語ランキングでしょ

**デフォルトの名無しさん** · 2021/08/23(月) 18:03:58.81

nim もっとカッコイイ名前が良かった
julia よりマシだが

**デフォルトの名無しさん** · 2021/08/23(月) 18:27:25.22

GoもRustもNimもJuliaも検索性わるすぎるんよー

**デフォルトの名無しさん** · 2021/08/23(月) 19:25:50.37

Cは？

**デフォルトの名無しさん** · 2021/08/23(月) 21:15:07.01

>>35
せいぜいCで代替できないケースもある、だな
「代用不可」は言い過ぎ

**デフォルトの名無しさん** · 2021/08/23(月) 21:19:05.15

C/C++/Rustは中でアセンブリ書けるので大丈夫
どうしても必要な部分がある時は使われている

**デフォルトの名無しさん** · 2021/08/23(月) 21:38:44.27

>>42
スタック無しが要件なら代替不可
そうでないならあんたの言う通り

**デフォルトの名無しさん** · 2021/08/23(月) 22:01:28.04

>>39
G. M. Julia 「……」
https://ja.wikipedia.org/wiki/%E3%82%AC%E3%82%B9%E3%83%88%E3%83%B3%E3%83%BB%E3%82%B8%E3%83%A5%E3%83%AA%E3%82%A2

**デフォルトの名無しさん** · 2021/08/23(月) 23:23:44.42

>>34
それに近いのがllvm ir

**デフォルトの名無しさん** · 2021/08/24(火) 00:13:51.84

wasmとllvmって
どうしても必要とは言えない所でアセンブラ使ってるよな

**デフォルトの名無しさん** · 2021/08/24(火) 01:00:35.96

>>44
もうトートロジーに陥ってるじゃん…
無理しないで>20は命題として偽だって認めなよ