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

**デフォルトの名無しさん** · 2020/04/19(日) 15:06:02.92

スレタイ以外の言語もok

前スレ
次世代言語18 Go Rust Elixir Kotlin TypeScript (実質20)
https://mevius.5ch.net/test/read.cgi/tech/1569866283/

**デフォルトの名無しさん** · 2021/06/19(土) 18:20:46.92

>>892
nim 結構いいのに Python 臭いとこがやだよね。

**デフォルトの名無しさん** · 2021/06/21(月) 18:23:45.07

Swiftも!あんじゃん

**デフォルトの名無しさん** · 2021/06/22(火) 01:19:34.45

そりゃビックリ！

**デフォルトの名無しさん** · 2021/06/22(火) 07:17:18.33

swiftのResultBuildersってなんか面白そうだな

**デフォルトの名無しさん** · 2021/06/22(火) 09:26:37.53

>>893
いつも思うんだが、こういう奴ってなんでこういうスレに来るの？
うざいんだが

**デフォルトの名無しさん** · 2021/06/22(火) 20:38:29.50

その言葉、そっくりそのままお返しします。

**デフォルトの名無しさん** · 2021/06/23(水) 02:30:54.55

>>899
いやスレの趣旨に合わないやつが居座ってんのどっちだって話

**デフォルトの名無しさん** · 2021/06/23(水) 13:28:38.76

居座ってるってどうやって確かめたんだ？
たまたまスレが目に入っただけかも知れんだろ

**デフォルトの名無しさん** · 2021/06/27(日) 01:52:23.46

>>893
Rustをオススメします

**デフォルトの名無しさん** · 2021/06/27(日) 04:28:46.15

Kotlin もよろしく

**デフォルトの名無しさん** · 2021/06/27(日) 05:55:26.60

C/C++のかわりにおすすめするってことはKotlinってJVMへの依存切ってシングルバイナリで動くの？
できたとしてもランタイム重そう

**デフォルトの名無しさん** · 2021/06/27(日) 12:57:27.73

なんで D は無かったことにされてるのですか？

**デフォルトの名無しさん** · 2021/06/27(日) 23:00:58.14

>>905
度々自らの過去を無かったことにしたことでプログラマに愛想を尽かされて無かったことにされた

**デフォルトの名無しさん** · 2021/06/27(日) 23:40:14.19

もうlazy くらいしか特徴が無いデカいし将来性の無い環境だからねー
デカいスタティクライブラリとコンパイラメッセージは仕方ないとしても
ビルド環境はメジャーなんに幅広く寄生すればいいのに

**デフォルトの名無しさん** · 2021/06/29(火) 00:20:13.47

>>904
一応 Kotlin native は既にある。でもまだ作ってる最中って感じかな? 遅いらしい。

**デフォルトの名無しさん** · 2021/06/29(火) 00:24:49.55

まあしかし C はまだいいけど C++ は複雑で分かりにくいように思う。
学習に時間が掛からないか?

そしてよく使われていたであろう Windows ネイティブのプログラムはじわじわと廃れていく。

**デフォルトの名無しさん** · 2021/07/01(木) 07:59:54.15

デジタルなんだからじわじわ劣化しないよ
っていう単純化された理論が崩壊したのは事実だが

実装レベルのC++は複雑だが破綻はしてない

**デフォルトの名無しさん** · 2021/07/01(木) 19:20:24.95

bool
polymorphism
match
と来て次の層はどんなんになるんかな

**デフォルトの名無しさん** · 2021/07/01(木) 20:52:42.10

WebAssemblyアプリ開発で最も使われている言語はRust、注目の機能はスレッドなど。The State of WebAssembly 2021
https://www.publickey1.jp/blog/21/webassemblyrustthe_state_of_webassembly_2021.html

**デフォルトの名無しさん** · 2021/07/04(日) 10:42:07.67

注目の機能スレッドってなんかそういう独自の機能があるのかと思ったわ

**デフォルトの名無しさん** · 2021/07/10(土) 18:17:31.11

L言語とな？
https://github.com/microsoft/L

**デフォルトの名無しさん** · 2021/07/10(土) 21:06:58.55

注目の機能は、と問うスレッドが5chでも建ったんじゃないの

**デフォルトの名無しさん** · 2021/07/11(日) 15:36:58.13

>>910
「,」、「&&」、「||」周りのオーバーロードとか完全に破綻しとるわ。

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

llangってぱっと見なんだかわからんな
またネーミング失敗じゃない？

**デフォルトの名無しさん** · 2021/07/14(水) 00:32:39.09

そういえばZenってお前ら的にどうなの
https://www.zen-lang.org/ja-JP/

**デフォルトの名無しさん** · 2021/07/14(水) 00:42:40.34

>>918
つまらん言語だな
GCのないGo処理系を作れば済む話だったのではないか

**デフォルトの名無しさん** · 2021/07/14(水) 08:15:42.46

>>918
ゴミ言語という印象しかない　https://ziglang.org/news/statement-regarding-zen-programming-language/

**デフォルトの名無しさん** · 2021/07/14(水) 10:52:37.13

Zigのパクりでしょ

**デフォルトの名無しさん** · 2021/07/14(水) 13:41:04.37

zigってnimとかvlangとかに比べてどこらへんがいいん？

**デフォルトの名無しさん** · 2021/07/14(水) 14:03:16.32

>>922
やりたいことはわかるが、わざわざ言語を作るほどのことではない
スルーしてよし

**デフォルトの名無しさん** · 2021/07/14(水) 15:48:49.76

このスレなんのスレだっけ？

**デフォルトの名無しさん** · 2021/07/14(水) 16:02:12.04

自分の気にいらない言語を貶めるスレ

**デフォルトの名無しさん** · 2021/07/15(木) 03:40:50.12

ここまできてはじめて
スレ住人全員が同意する意見が書きこまれた >>925

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

勝手に同意した事にするなよ…
主語がでかすぎる

**デフォルトの名無しさん** · 2021/07/18(日) 12:01:23.40

プログラミング言語とか、勘違いしやすく物忘れも激しいという
人間の非理想的な特性に対する対策なのだからそれ自体が宇宙の真理ﾚｳﾞｪﾙの美しさを備えることは難しい
C++はその対人間の対策にすら失敗している気配がするが、
プログラミング言語の理想を言い出したらキリがないことも上のことから明らかなので、
必要な仕事をやれるのだからC++でも及第点とも言える

**デフォルトの名無しさん** · 2021/07/18(日) 12:04:40.99

「より良いソリューションに対する最も危険な敵というのは、十分に良い既存のコードベースなのだ
（the most dangerous enemy of a better solution is an existing codebase that is just good enough.）」
とゆー格言はプログラミング言語にも当てはまる

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

なんかキモいね

**デフォルトの名無しさん** · 2021/07/18(日) 18:39:25.82

褒められたと思っておこう（ｷﾘ

**デフォルトの名無しさん** · 2021/07/19(月) 01:55:47.55

ていうか最も危険な敵っていってるけど
そんだけ十分によいソリューションになってるってことじゃねーか
「より良い」ってのがただの思いこみってのが真相だろう
手前ミソを売りこむのに邪魔、っていうのをいいかえただけだな

**デフォルトの名無しさん** · 2021/07/19(月) 08:27:19.09

「betterの敵はenough」で十分なのに、既存の格言はやけに長いな

**デフォルトの名無しさん** · 2021/07/22(木) 17:21:37.86

Sather

**デフォルトの名無しさん** · 2021/08/09(月) 14:42:17.17

Pythonより30％高速目指す「Pyston」--開発者が語る次の目標

**デフォルトの名無しさん** · 2021/08/09(月) 18:34:55.62

のちのピストン運動である。

**デフォルトの名無しさん** · 2021/08/20(金) 21:52:24.83

Rustのボローチェッカーとは動作が異なるようなのですが、
Nimにはすでに「借用チェッカー」に似たものがあるそうです
https://forum.nim-lang.org/t/5459

Nimでもボローチェッカーで参照の有効性を検証することによって
メモリ安全性を保証できるのでしょうか？
何方か詳しい方がいましたらご教示お願い致します

**デフォルトの名無しさん** · 2021/08/21(土) 03:28:29.09

>>937
まだ実装されてないけど、ボローチェッカーに似たようなものを作る予定はあるようだよ。
http://nim-lang.github.io/Nim/manual_experimental.html#view-types

**デフォルトの名無しさん** · 2021/08/21(土) 06:03:46.59

>>937
Nimはガベージコレクション(GC)のある言語
だからGCのないC/C++/Rustとは別分野なのでそれらの代替にはならない

**デフォルトの名無しさん** · 2021/08/21(土) 06:50:02.55

>>938
ご教示ありがとうございます。
さっそくリンク先をgoogle翻訳してみたのですが、
Nimバージョン：1.5.1でRustのボローチェッカー
に似た「View types」が実装されるんですね

Nim　Version 1.0.0 正式リリースされてから
1年も経過しないうちにARCとORCが実装されたよう
なので、一年後（現在Version 1.4.8）には
「ボローチェッカー(View types)」も実装されそうですね

**デフォルトの名無しさん** · 2021/08/21(土) 07:04:18.79

GCが無い事実は保証できる
速度のベンチマークが嘘じゃないことは保証できない

だから自称超高速GCがもしあっても普及しない
GC無しで高速化した方が確実

**デフォルトの名無しさん** · 2021/08/21(土) 07:09:56.98

>>939
>Nimはガベージコレクション(GC)のある言語

Nimはガベージコレクション(GC)を任意で外せるから、
ガベージコレクション(GC)を外して「ボローチェッカー(View types)」
で参照の有効性を検証することによってメモリ安全性を保証できないのでしょうか？

**デフォルトの名無しさん** · 2021/08/21(土) 07:27:43.27

>>941
>GC無しで高速化した方が確実

NimはオプションでGC無しにできるので、
Nimバージョン：1.5.1でRustのボローチェッカー
に似た「View types」が実装されればGC無しで
高速化出来ますか？

**デフォルトの名無しさん** · 2021/08/21(土) 07:45:38.03

>>939
>だからGCのないC/C++/Rustとは別分野なのでそれらの代替にはならない

NimにGC有りは事実なのですが、
NimはオプションでGC無しにできるので、
Nimバージョン：1.5.1でRustのボローチェッカー
に似た「View types」が実装されれば
GC無しで、View types参照の有効性を検証する
ことによってメモリ安全性を保証しつつ高速化して
C/C++/Rusの代替にt出来ますか？

**デフォルトの名無しさん** · 2021/08/21(土) 09:50:30.70

Rust難しくて諦めたのかな？デフォルト実装されてなきゃランタイムやライブラリが纏まらなくて代替にはならんよ。
Rustに慣れる方が現実的だな

**デフォルトの名無しさん** · 2021/08/21(土) 10:59:32.65

Javaですら難しい所はあるんだよ
そこを任意で外してstatic変数ばかり使うと結構酷い目にあう
任意で外せると言われても現実的に外せないことがよくある

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

>>945
>デフォルト実装されてなきゃランタイムやライブラリが纏まらなくて代替にはならんよ

NimはNimソースコードをトランスコンパイルして、一度 Cのソースコードを吐き出します
このトランスコンパイルする時にオプションでGC無しを選択して一つ一つ手動でメモリ管理
していくことになる
吐き出されたCソースコードをCコンパイラでバイナリへ変換するのでランタイムやライブラリが
纏まらなくなったり、Javaコンパイラみたいに外せないと言う問題も発生しないと思うのですが
間違っていますか？
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

**デフォルトの名無しさん** · 2021/08/21(土) 13:46:01.75

なんでプログラミング言語って十徳ナイフに向かいがちなんだろうな

**デフォルトの名無しさん** · 2021/08/21(土) 14:06:29.07

Cでいいやん

**デフォルトの名無しさん** · 2021/08/21(土) 14:30:12.98

>>948
それはあなたが考える十徳ナイフがプログラミング言語に似ているからです。

**デフォルトの名無しさん** · 2021/08/21(土) 14:33:03.76

0を1にする脳より、1を10にする脳になりがちな理由？
前者は破壊的で後者は建設的に見えるからかな

**デフォルトの名無しさん** · 2021/08/21(土) 15:24:53.18

>>949
CやC++で書くとメモリ安全性が必ずしも保証出来ないために様々なセキュリティの穴を含むバグを生じさせてきた
そのためメモリ安全性を保証しつつC/C++の代替となる言語としてRustが誕生した
C/C++/RustはGC(ガベージコレクション)がないためOSや基本ライブラリに組み込み等の分野に至るまで幅広くカバーすることができるプログラミング言語
その中でもメモリ安全性を保証できるRustへと少しずつ移動が始まりつつあるのが現在の流れ

**デフォルトの名無しさん** · 2021/08/21(土) 15:27:45.68

>>947
ランタイムやライブラリを貴方が一つ一つ手動でメモリi管理するなら問題ないね

**デフォルトの名無しさん** · 2021/08/21(土) 17:30:00.12

>>949
>Cでいいやん

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

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

**デフォルトの名無しさん** · 2021/08/21(土) 17:33:35.36

>>954
コンパイルが通った時点でメモリ安全性が担保されるRustの方が良いですよ

**デフォルトの名無しさん** · 2021/08/21(土) 17:54:49.49

>>955
Rustのメモリ安全性はボローチェッカー担保されている

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

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

Nimの実験的特徴
著者：アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

**デフォルトの名無しさん** · 2021/08/21(土) 18:53:58.07

だったらnimでいいじゃん

**デフォルトの名無しさん** · 2021/08/21(土) 18:55:52.39

怠け者のくだりが意味わからん

**デフォルトの名無しさん** · 2021/08/21(土) 19:25:31.33

>>958
>怠け者のくだりが意味わからん

ご指摘ありがとうございます。
「C言語でリモートワークでされている方は」が抜けていましたので以下訂正いたします

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

**デフォルトの名無しさん** · 2021/08/21(土) 19:51:42.21

>>959
Pythonが高い可読性？？
信者くらいしかそんなこと言わないぞ
他の言語と可読性は同じだろ

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

Pythonのライブラリを再発明するかーとはならんだろ
Pythonの可読性を再発明するふりをすれば怠けることができる

**デフォルトの名無しさん** · 2021/08/21(土) 21:53:00.41

>>960
Pythonは構文にインデントを組み込むことによってざっと眺めた時に人間が読みやすい
一般的には上記の事をPythonは高い可読性があると表現されています
この事は「Pythonは可読性の高い言語」ググれば約 265,000 件出てきます

他の言語と可読性は同じだろって意見の人は少数派です

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

「javascriptは可読性の高い言語」で検索すると約 334,000 件

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

関係無いスレに出張ってんじゃねーよNimキチガイ

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

>>963
>「javascriptは可読性の高い言語」で検索すると約 334,000 件

単に検索件数が多いだけで、上位10件の表示内容を読んでも
「javascriptは可読性の高い言語」と言う内容のページは1つも見つかりません

対して「Pythonは可読性の高い言語」は上位10件の内5件見つかりました

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

>>964
>Nimキチガイ

いつもみんなによく言われます
照れますね～ｖ（=＾0＾=）ｖ

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

>>962
インデントで可読性が高い？？
じゃあほとんどのプログラミング言語はインデント出来ますから可読性が高いことになりますねｗ
Pythonが他の言語より可読性が高いなんて一切ありません
そもそもPythonはプログラミング言語としてあまりよくないので積極的に使いたい人はあまりいないでしょう
分野によってはライブラリの充実状況で仕方なく使う程度の言語です
Pythonで開発なんて絶対にしたくないと思う人が多数派でしょう

**デフォルトの名無しさん** · 2021/08/21(土) 23:03:01.15

>>967
元の文脈的に
Nimも構文にインデントを組み込んでるからpythonが出てきただけでそういう議論がしたいんじゃない

**デフォルトの名無しさん** · 2021/08/21(土) 23:24:43.32

他のコンパイラが自分自身をconfigureとかmakeしている間に
Pythonはライブラリを充実させる仕事が早く終わって怠けることができる

**デフォルトの名無しさん** · 2021/08/21(土) 23:58:42.50

>>969
つまりNimはダメってこと？

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

>>970
>NつまりNimはダメってこと？

そんな寂しい事言わないでかまってよ～(´;︵;`)

Nimは行末のセミコロンが必要ない
タイプ数がもりもり減ります。

Rust にはもちろん必要です。

Nimはmain が要らない
スクリプト言語感覚でいきなりコードを書けます。

Rust は main が必要です。

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

>>970
そんな寂しい事言わないでかまってよ～(´;︵;`)

Nim は標準出力への文字列出力が楽
Nim では echo で改行付きの出力ができます。shell と同じですね。通常は改行付きで出力することの方が多いでしょ。
Nim はしょっちゅうやることは簡単にできるようになっています。
そんな Nim の echo は可変引数で値を受け取り型が何なんだろうとお構いなしに出力できます。

let n = 10
let str = "HOGE"
echo "Number: ", n, " String: ", str
一方 Rust は

let n = 10;
let str = "HOGE";
println!("Number: {} String: {}", n, str);
なんかよく判らんマクロでいちいちびっくりさせなきゃいけないです。よく使うものが冗長だとゲンナリします。
変数を直接ぶち込むことも出来ませんしね。

let n = 10
echo n
普通出来るでしょこんなもん・・・。ところが Rust は出来ない。

let n = 10;
println!(n); <- エラー
println!("{}", n); <- 毎度これを書かされる
うざいっす。

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

>>970
NimはC の関数を気軽に持ってくる
たった一行足すだけで C の関数を使うことが出来るようになります。

proc printf*(format: cstring) {.header: "<stdio.h>", importc: "printf", varargs.}
let n = 10
let str = "HOGE"
printf "Number: %d String: %s\n", n, str
どうですこれ？C の資産を気軽に使うことができるんです。SWIG 等の鬱陶しいラッパーを使うこと無くです。
Rust の場合はご多分にもれずラッパー行きで超絶面倒くさいです。比較用に書きたいんですが結構な文章量になるのでやめます。

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

>>970
そんな寂しい事言わないでかまってよ～(´;︵;`)

Nimはmut mut しなくて良い
Rust はまともな変数を使おうとすると mut mut しないといけません。デフォルトだと再代入できませんから。
普通再代入しまくりますよね？定数ライクに使いたい機会なんて殆どないですよね？なのに mut を毎度書かされます。

let n:int = 10
let mut m: int = 10
Nim ならこうですよ。

let n = 10 # immutable
var m = 10 # mutable
素敵。

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

>>970

Nimは所有者・借用なんてもんでイライラしない
　Rust には C のポインタが可愛く見えるレベルで高くそびえ立つ鉄壁の初心者ガード、悪夢の"所有者・借用"の概念が存在します。
プログラムに慣れた人間ですら混乱に陥れ、書いている最中に精神力と人生の貴重な時間をガンガン削ってくれる究極の嫌がらせです。

Rust は変数のコピーしちゃうと元のやつが使えなくなるクソ仕様なのです。書き手にメリットなんて一切無い。C++の悪しきメモリ管理の呪いを持ち込んで来てその中でもさらに悪い部分をデフォルトにした感じです。

struct Point {
x: i32,
y: i32,
}

fn Print(p: Point) {
println!("x = {}, y = {}", p.x, p.y);
}

fn main() {
let mut a: Point = Point{ x: 10, y: 15 };
Print(a);
// エラー！
println!("x = {}, y = {}", a.x, a.y);
}
Print(a) で1回コピーされているのでその後使うと死にます。ウソでしょ？と思うでしょ？ホントです。
そしてプリミティブ型ならOKと言う Java に似たダブスタの呪いもオマケで付いてます。

おかげさまで関数はほぼ全て明示的に参照渡しをするハメになります。
「だったらデフォルトそうしとけよ！ & をイチイチ書かせんなやワレ！」と思わないのってある種の才能だと思います

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

>>970

struct Point {
x: i32,
y: i32,
}

fn Print(p: &Point) {
println!("x = {}, y = {}", p.x, p.y);
}

fn main() {
let mut a: Point = Point{ x: 10, y: 15 };
Print(&a);
println!("x = {}, y = {}", a.x, a.y);
}
これだとまぁエラーにはなりません。が、参照だからといってこんなことやったら死にます。

fn Print(p: &Point) {
println!("x = {}, y = {}", p.x, p.y);
p.x = 10; <- die
}
イミュータブルだからですって。はぁ・・・。

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

>>970

だからこう書けですって。

fn Print(p: &mut Point) {
println!("x = {}, y = {}", p.x, p.y);
p.x = 100;
}

fn main() {
let mut a: Point = Point{ x: 10, y: 15 };
Print(&mut a);
println!("x = {}, y = {}", a.x, a.y);
}
はい来た。mut mut mut mut mut mut mut mut mut ああぁぁああぁ～～～！！！

なんでよく使う方を面倒臭くしたがるんですか、この言語を作っている方々は。

その他又貸しの呪いやらなにやら超盛り沢山ですし。もうね私とはセンスが全く合わないです。

ぬぅぅうぅうぉぉおぉおぁぁあぁあああ！！！！！Rustよ！もうお前には頼まん！malloc と free を俺によこせうぉるぅぁあ！！こんな訳のわからんものに付き合わされるんだったら自分でメモリ管理した方がマシだわ！！！

とよくみんな発狂しませんよね。我慢強いですね。馬鹿じゃないの。

とっても良い子である Nim にはこんな呪いある"ワケ"がないです。

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

>>970

type Point = object
x: int
y: int

proc print(this: Point) =
echo "x = ", this.x, ", y = ", this.y

var p = Point(x: 10, y: 15)
p.print()
echo "x = ", p.x, ", y = ", p.y
まぁ普通はこうですよね・・・。Rust がぶっ飛んで異常なだけです。ありえないです。

ちなみに Nim の場合 print(p) と p.print() は書き方が違うだけで意味は同じです。

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

>>862

参照で渡す場合はこうなります。

type Point = object
x: int
y: int

proc print(this: ref Point) =
echo "x = ", this.x, ", y = ", this.y
this.x = 100

var p = Point.new
p.x = 10
p.y = 15
p.print()
echo "x = ", p.x, ", y = ", p.y
new で Point object を作成すると参照のオブジェクトが出来ます。これを渡すために print 側の引数には ref をつけてあげます。new 関数でメンバに値を割り当てることは出来ないので後から渡してやります。

つっても上のやつはあくまで Rust と似せて書いたらこうなるよって話でこんな書き方しません。

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

>>970

普通オブジェクトなんて参照だろ、って事で Nim では以下のように書くのが慣例化しています。

type
Point = ref PointObj
PointObj = object
x: int
y: int

proc print(this: Point) =
echo "x = ", this.x, ", y = ", this.y
this.x = 100

var p = Point(x: 10, y: 15)
p.print()
echo "x = ", p.x, ", y = ", p.y
オブジェクトとそのリファレンスを同時に定義して、通常使わない方のオブジェクト側にサフィックスをつけておくと、まぁ素のオブジェクトも作りたきゃ作れるし、って話です。

自分は正直リファレンスだけで良いので更に手を抜いてこう書きますけどね。

type
Point = ref object
x: int
y: int

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

>>970

パターンマッチ？case でしょ？
Nim も case でそれっぽく書けます。

複式パターン
fn main() {
let x = 1;
match x {
1 | 2 => println!("1 | 2"),
3 => println!("3"),
_ => println!("other"),
}
}

let x = 1
case x
of 1, 2: echo "1 | 2"
of 3: echo "3"
else: echo "other"

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

>>970

範囲
fn main() {
let x = 1;
match x {
1...5 => println!("1...5"),
_ => println!("other"),
};
}

let x = 1
case x
of 1..5: echo "1..5"
else: echo "other"

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

>>970

case の返りを受け取る
fn main() {
let x = 1;
let s = match x {
1 => "one",
2 => "two",
_ => "other",
};
println!("{}", s)
}

let x = 1
let s = case x
of 1: "one"
of 2: "two"
else: "other"
echo s

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

>>970

分配束縛
Nim は標準ではできませんが

https://github.com/andreaferretti/patty

を突っ込むことで可能です。

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

>>970

仕様バグがない
Rust の以下の挙動は全く理解ができません。

fn main() {
let x = 'x';
let c = 'c';
match c {
// x: c c: c
x => println!("x: {} c: {}", x, c),
}
// x: x
println!("x: {}", x)
}
普通 x にマッチすると思わないでしょこれ。
さらにその直後 x が 'c' に変わってるとか予想だにしませんよ。
まぁ普通はこんな書き方しないと思いますがこんな調子ではどこでどうハマるか予測不可能です恐ろしすぎます。

Nim はこんな書き方そもそも出来ません。

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

必死にならないといけないほどゴミってことだろう

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

>>970

コンパイラがケチくさくない
nim c -r hoge
これで hoge.nim をコンパイルします。
拡張子なんて指定する必要ありません。
-r で実行もします。

Rust の場合

rustc hoge <- ダメ
コンパイルと同時に実行しようと思ったら

rustc hoge.rs && ./hoge
うーん・・・

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

>>985
君はブロックスコープも理解できないアホなのかｗｗ
つまりNimにはスコープがないのかね

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

某ブログのコピペじゃん
あのブログ主に恨みでもあるの？

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

>>970

実行速度・メモリ使用量・ファイルサイズが小さい
Rust と比べて Nim の実効速度はどっこいかむしろ速いです。
Rust はこんだけイライラする書き方を強制されるにも関わらずたいして速くないとかもう哀れすぎます。

コンパイル後のファイルサイズは話にならないレベルで比べ物になりません。

fizzbuzz の例(FizzBuzz を無駄にベンチマークしてみた By Nim、golang、Rust、Crystal、その他 - 強まっていこう)で言うと

項目　　　　　　　　Nim 　　　　Rust
実行速度　　　　　0.37s 　　　　0.44s
ファイルサイズ　　82K 　　　　3.4M
メモリ　　　　　356K 　　　　900K
こんな感じです。

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

>>990
バカ丸出し
Rustはバイナリサイズも小さく出来ます
だから組み込み分野でもRustが強いわけです

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

Nimいいじゃん

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

さすがに騙される人はいないでしょう
ここまで荒らしがひどいなら次スレはNimを外した方がいいかもね