nim

1 ：デフォルトの名無しさん：2018/03/01(木) 18:32:18.16 ID:vh/yy2VS.net

https://nim-lang.org/

279 ：デフォルトの名無しさん：2022/11/18(金) 10:17:44.40 ID:IJuokuF8.net

問題無い訳ではないとも
https://flat-leon.はてぶろ.com/entry/nim_arg_pass
バージョンや記事の年代に気を付けないといかんのかね

280 ：デフォルトの名無しさん：2022/11/18(金) 11:42:20.25 ID:IJuokuF8.net

古いけどここの議論は判り易い
https://forum.nim-lang.org/t/1207

281 ：デフォルトの名無しさん：2022/11/18(金) 11:48:22.19 ID:ygRIcUIa.net

>>273
それは var の説明であって ref の説明ではないですね

282 ：デフォルトの名無しさん：2022/11/18(金) 12:02:19.50 ID:IYaGyAsl.net

>>278
>>281
refのついた型またはvar引数は常に引数を参照渡し(ポインタのコピー)する。
refやvarがついてない場合は引数のサイズにあわせてコピー渡しか参照渡しになるが、どちらにせよプロシージャ内で引数を変更するのは禁止

283 ：デフォルトの名無しさん：2022/11/18(金) 12:10:00.28 ID:IYaGyAsl.net

だからデフォルトの引数の渡し方でそれがコピー渡しになろうが参照渡しになろうがそれで挙動が変わったりバグの温床になることはない。
ただしaddrとかemit, Assembler statementなどのNimが安全性を保証してない機能を使う場合は例外だ。

284 ：デフォルトの名無しさん：2022/11/18(金) 12:24:09.04 ID:IJuokuF8.net

参照とか reference とか同じ名前だから混同してるのかも知れないが
Nim の参照型と C++ の参照型は全く別物
C++ の引数で使う参照型 & は Nim では var の方が近い
Nim の ref は C++ ではポインタ * と思った方が良い
Nim では
GC で管理されるポインタが ref
GC で管理されないポインタが ptr

285 ：デフォルトの名無しさん：2022/11/18(金) 17:46:16.11 ID:PNsYUFFf.net

これ使うか使わないかでも全然違うのよね --gc:arc

286 ：デフォルトの名無しさん：2022/11/18(金) 18:35:09.65 ID:yVVkBIHa.net

最近は --mm:arc

287 ：デフォルトの名無しさん：2022/11/19(土) 16:28:59.40 ID:F8GIHVyH.net

--mm:orc 推奨

288 ：デフォルトの名無しさん：2022/11/19(土) 17:55:05.22 ID:lavOlnrp.net

Nim2では--mm:orcがデフォルトになるらしいぞ。
みんな知ってると思うけど--mm:arcだともし循環参照があったときにメモリリークするぞ。

289 ：デフォルトの名無しさん：2022/11/19(土) 19:05:39.54 ID:7QNjN12J.net

Nim2なんて10年以上先

290 ：デフォルトの名無しさん：2022/11/20(日) 10:26:07.81 ID:MUgzJmMj.net

>>278 のリンク先なんか
「Nimでアプリケーション開発をするための設計のベストプラクティス」
みたいにイキってるけど
信用していいの？

291 ：デフォルトの名無しさん：2022/11/20(日) 11:36:46.79 ID:h2bm0L4T.net

object type 全部 ref 付けろ教のひと
たまにいるよね
迷惑

292 ：デフォルトの名無しさん：2022/11/21(月) 13:35:10.22 ID:LzW8OiBh.net

割と実用になるわね
https://pastebin.com/Ry2wTRHi

293 ：デフォルトの名無しさん：2022/11/22(火) 09:38:49.09 ID:E0zMoWY7.net

理由を示さないお作法は無視していい

294 ：デフォルトの名無しさん：2022/11/24(木) 09:24:22.39 ID:qRYWlPaY.net

なんでもかんでもref付けろと
しつこく強要してる人は
あたまおかしい
大抵は{.byref.}で用足りる

295 ：デフォルトの名無しさん：2022/11/24(木) 15:02:15.10 ID:7i9tpoXw.net

{.byref.}はnimからC/C++の関数を使うときに引数をポインタで渡しているときに使うもの。
それ以外では使う意味はないよ。
Nimはちゃんと最適な方法で引数を渡すから必要でもないのに{.byref.}とかvarとかつける必要はない。

296 ：デフォルトの名無しさん：2022/11/24(木) 18:37:53.45 ID:m+x+kPsJ.net

var も ref も byref も全部別物だと何度言えば判るんだ？

297 ：デフォルトの名無しさん：2022/11/24(木) 18:42:50.52 ID:RL/H9YUN.net

>>296
みんなが必ず遭遇する問題なので
短くまとめて次スレからテンプレにするのが良い
以下 >>296 のテンプレが続く

298 ：デフォルトの名無しさん：2022/11/25(金) 09:06:20.12 ID:PV2ZG9bu.net

{.byref.}をrefと間違うのは判らんでもないし同情するが
{.byref.}をvarと間違う香具師は初めて観た

299 ：デフォルトの名無しさん：2022/11/25(金) 16:53:59.56 ID:s0hi6gQd.net

nim 1.6.10 出た

1.6.98 まで行くのかw

300 ：デフォルトの名無しさん：2022/11/27(日) 12:26:56.31 ID:IMKjsn3J.net

regexどれ使えば良いの？

301 ：デフォルトの名無しさん：2022/11/27(日) 16:05:43.13 ID:/+GS7DyS.net

>>300
好きなのでいいんじゃ ?

302 ：デフォルトの名無しさん：2022/11/27(日) 17:37:23.28 ID:1IfwvG7/.net

>>300
Nimでは正規表現よりPEGのほうがおすすめらしい。
https://nim-lang.org/docs/pegs.html

PEG (Parsing expression grammar) is a simple deterministic grammar, that can be directly used for parsing. The current implementation has been designed as a more powerful replacement for regular expressions. UTF-8 is supported.

303 ：デフォルトの名無しさん：2022/11/28(月) 05:25:04.28 ID:T/4+TPza.net

300

304 ：デフォルトの名無しさん：2022/11/29(火) 12:04:17.71 ID:+WMggzr1.net

pythonのStringIOとかBytesIOみたいなのは無い？

305 ：デフォルトの名無しさん：2022/11/29(火) 14:03:26.53 ID:lz77OQ93.net

>>304
FileStreamとStringStream かも
https://nim-lang.org/docs/streams.html

306 ：デフォルトの名無しさん：2022/12/02(金) 09:32:24.76 ID:ef8lBYgh.net

https://nim-lang.org/docs/streams.html を観ると
FileStream = ref FileStreamObj ← 判る
FileStreamObj = object of Stream ← 判らん
StringStream = ref StringStreamObj ← 判る
StringStreamObj = object of StreamObj ← 判る
Stream = ref StreamObj ← 判る
StreamObj = object of RootObj ← 判る

なんで
FileStreamObj = object of StreamObj
になっていないのでしょう？
意図を知りたいです

307 ：デフォルトの名無しさん：2022/12/02(金) 09:38:11.16 ID:ef8lBYgh.net

https://github.com/nim-lang/Nim で
lib/pure/streams.nim の type を観ても
FileStream のだけ
FileStream* = ref FileStreamObj
FileStreamObj* = object of Stream
でした

308 ：デフォルトの名無しさん：2022/12/02(金) 17:15:15.76 ID:Ojlf0I9F.net

命名の推測で「WHY？」という話なら、ofキーワードの後に来るのが、必ずxxxObjという規約ではないから。

目的としてxxxObjでないのは、それを扱いやすくするためでStringStreamやStreamはそのまま宣言したり
引数に渡したり、戻り値の型として記述して使用するのに対してxxxObjは普通にライブラリの使用者は
めったに直接的に使用しない。（ライブラリの設計者・実装者は普通に使う）
例を言えば、MemMapFileStream、ReadSocketStreamなども利用者は直接的に使用するが、いずれも
ストリーム系だがobject of の後にくるものは違う。

例えば、利用者はプロセスの出力をStreamで使用するなら、このようなprocを使う
proc outputStream*(p: Process): Stream

これを、クライアントプログラムの実装者が受け取る変数の定義でStreamObjと書いていたらおかしい。
APIドキュメントには、「最も使用される一般名称にはそのままの名前を付ける」としか書いてないが
Nimに限らず一般的に、１つか少数の抽象名と数多くの具象名は一般名称でプレ・サフィックスは付けない
https://nim-lang.org/docs/nep1.html
When naming types that come in value, pointer, and reference varieties, use a regular name for the variety that is to be used the most, and add a "Obj", "Ref", or "Ptr" suffix for the other varieties. If there is no single variety that will be used the most, add the suffixes to the pointer variants only. The same applies to C/C++ wrappers.

似た話にxxxRefがあるがこちらはref objectに単に付けるが、型名をあまり使用しない場合で、なおかつ
ref objectであることを強調する場合が多い。
StringTabeRef* = ref StringTabeObj
var tbl = newStringTable(...)

309 ：デフォルトの名無しさん：2022/12/02(金) 18:20:09.03 ID:hfqW6J8Y.net

https://play.nim-lang.org/#ix=4hrl
継承するときに基の型についてるrefは無視されるようなので
objectかref objectのどちらから継承しているかは重要ではないようだ。

310 ：デフォルトの名無しさん：2022/12/03(土) 14:54:39.83 ID:H3EtATlx.net

>>309
なるほど！

311 ：デフォルトの名無しさん：2022/12/08(木) 15:32:48.39 ID:0CftMozc.net

template とか macro とか使うと
流れる様にさらさら描けて気持ち良いわコレ

312 ：デフォルトの名無しさん：2022/12/12(月) 07:08:32.93 ID:pbYUfvW7.net

templateとmacroを上手くに使えるようになりてえなあ☹

313 ：デフォルトの名無しさん：2022/12/13(火) 09:48:40.02 ID:xx5dSLzS.net

こんな感じのmacroを書いていろんなコードを与えてみよう。
コンパイル時にecho x.treeReprの出力が表示される。
それを読めばNimのコードはAST(抽象構文木)になることが理解できると思う。
これがNimのmacroを理解する第一歩だと思う。

import std/macros

macro test(x: untyped): untyped =
　echo x.treeRepr

test:
　echo "test"

後はこれを読めばok
https://nim-lang.org/docs/manual.html#macros
https://nim-lang.org/docs/macros.html

314 ：デフォルトの名無しさん：2022/12/14(水) 10:22:41.84 ID:LLXuibjV.net

macro は AST 知ってると有利だね
あと head と body を受け取るタイプのと
node を受け取るのと
static type を受け取るのとか
区別して理解しないと
自分が何やってるのか判らなくなる

315 ：デフォルトの名無しさん：2022/12/14(水) 15:44:32.71 ID:SCwOJhsV.net

へぇ、それはクソ仕様だね

316 ：デフォルトの名無しさん：2022/12/14(水) 21:28:27.69 ID:XhtdH9iq.net

node造る関数も直交性が無いな

317 ：デフォルトの名無しさん：2022/12/17(土) 10:10:45.75 ID:a3CJqZUP.net

直交性という言葉を知ってるオジサン・・・
C/C++言語の#def, #include→別言語（直交性100%)、錆びのprintln!→実は別言語（直交性100%)
むしろこれは言語が習得で異なる仕様の言語を2つ覚えないといけない、敷居を高くする欠点

318 ：デフォルトの名無しさん：2022/12/17(土) 10:46:30.65 ID:2DPGsS1m.net

NimNodeはseqに近い方法で扱えるようにmacrosモジュールにプロシージャが定義されているのはいいことでは。

319 ：デフォルトの名無しさん：2022/12/17(土) 12:04:27.61 ID:OfpYIbSc.net

untyped は obsoleted

320 ：デフォルトの名無しさん：2022/12/17(土) 18:07:52.62 ID:GzYo/1Xm.net

今はNimNodeじゃなく、quote do:で書くのが良いよな。どうしてもNimNodeじゃなきゃ書けないマクロもあるだろうけどね

321 ：デフォルトの名無しさん：2022/12/17(土) 19:18:25.81 ID:2DPGsS1m.net

>>320
https://nim-lang.org/docs/genasts.html
https://github.com/nim-lang/Nim/pull/17426
https://github.com/nim-lang/RFCs/issues/122

322 ：デフォルトの名無しさん：2022/12/22(木) 07:38:06.92 ID:Fm5nn8iV.net

最初のrelease candidate for Nim v2.0が公開されました。
https://nim-lang.org/blog/2022/12/21/version-20-rc.html

323 ：デフォルトの名無しさん：2022/12/22(木) 10:51:20.76 ID:Y6cO6Ymu.net

ペース早いよなあ

324 ：デフォルトの名無しさん：2022/12/22(木) 10:52:43.57 ID:N8bfJDIh.net

nim-2.0 RC1 がリリースされた
https://nim-lang.org/blog/2022/12/21/version-20-rc.html

来年1月か2月には正式2.0になるのかも

325 ：デフォルトの名無しさん：2022/12/23(金) 02:05:06.61 ID:PNJSSvHF.net

もう2.0かよ(´・ω・`)公開してるライブラリ大丈夫かな

326 ：デフォルトの名無しさん：2022/12/23(金) 20:17:33.78 ID:244A80LW.net

バージョンが大きく変わって大丈夫と思う方が
無理がある

327 ：デフォルトの名無しさん：2023/01/04(水) 23:27:44.60 ID:ADP0p8ohV

だいぶマニアックなスレですね

328 ：デフォルトの名無しさん：2023/01/16(月) 16:24:59.02 ID:MsfEWWA2.net

あっという間に2月

329 ：デフォルトの名無しさん：2023/01/23(月) 22:52:56.91 ID:NHwV5soq.net

書き込みが1ヶ月に1回しかないスレ w

330 ：デフォルトの名無しさん：2023/01/26(木) 03:28:17.45 ID:To7TXanK.net

Nim言語を使っていても特につまづくことがないから話題があんまりないんだよね。

331 ：デフォルトの名無しさん：2023/01/26(木) 18:39:32.28 ID:MzjwjnoQ.net

使用者の絶対数が少なすぎ

332 ：デフォルトの名無しさん：2023/02/01(水) 01:23:34.72 ID:p1uaZW7X.net

てすと

333 ： ：2023/03/01(水) 09:22:10.73 ID:68s28u+f.net

!omikuji

334 ：デフォルトの名無しさん：2023/03/01(水) 12:20:14.81 ID:q8rzgPd8.net

初心者はys3mとかrs3mで十分

Ziicubeでys3m出た
1割引き価格後の値段

679円 マグネット
1151円 Maglev
1623円 Boall-Core

https://www.ziicube.com/Moyu-333-HuaMeng-YS3M

335 ：デフォルトの名無しさん：2023/03/01(水) 12:20:39.02 ID:q8rzgPd8.net

>>334
誤爆

336 ：デフォルトの名無しさん：2023/03/05(日) 11:11:16.11 ID:/Qd0pRlS.net

WinnyとNimってネーミングセンス似てるね

337 ：デフォルトの名無しさん：2023/03/05(日) 19:55:40.66 ID:gl/xkADq.net

>>336
Nimは元々Nimrodっていう名前だったんだけどその由来は
https://forum.nim-lang.org/t/9591#63054

338 ：デフォルトの名無しさん：2023/03/06(月) 14:19:57.93 ID:diWxUEyJ.net

https://www.cosme.net/product/product_id/10190076/top

339 ：デフォルトの名無しさん：2023/04/03(月) 17:59:13.21 ID:dNC7VYHk.net

この言語ってRustみたいにプログラマに押し付けるmutなんて使ってないのに、なんでいわゆるMove操作が勝手に出来るの？
説明しろください！

340 ：デフォルトの名無しさん：2023/04/03(月) 18:32:57.47 ID:3grB/pQG.net

>>339
こちらの資料には目をとおされましたか？
https://nim-lang.org/docs/destructors.html

341 ：デフォルトの名無しさん：2023/04/09(日) 09:29:43.33 ID:Dm0aM9sg.net

Nim良いよね
Rustは宣伝がうざいだけだが
Nimは判ってる人の間でまったり進化してくれ

342 ：デフォルトの名無しさん：2023/05/04(木) 21:15:01.62 ID:wwnsNcS0.net

公式読めばだいたいのことはわかるから特にここでも議論は出ないよね
唯一日本語の書籍がもう一冊くらい欲しいなあくらい

343 ：デフォルトの名無しさん：2023/05/06(土) 09:24:18.50 ID:u7gslL5e.net

importとincludeの違いってなに？

344 ：デフォルトの名無しさん：2023/05/07(日) 06:11:02.39 ID:uVIPnqNg.net

>>343
https://qiita.com/tauplus/items/80afbd47f3a44158ea1f#import-statement
https://qiita.com/tauplus/items/80afbd47f3a44158ea1f#include-statement

345 ：デフォルトの名無しさん：2023/06/28(水) 19:11:48.73 ID:cQY5DEV3.net

Nim言語 1.6.14 リリｰス
https://nim-lang.org/blog/2023/06/27/version-1614-released.html

346 ：デフォルトの名無しさん：2023/07/02(日) 18:18:52.72 ID:4yDce2PB.net

夜遅くにすいません。
SyntaxHilighter用のNim Brushってどっかにありませんか？

347 ：デフォルトの名無しさん：2023/07/02(日) 18:34:57.51 ID:DcMb4mOQ.net

>>346
話の内容が全然理解できないけど。。。

348 ：デフォルトの名無しさん：2023/07/02(日) 21:16:17.65 ID:w86HyNV3.net

>>347
ごめんなさい。
SyntaxHighlighter でした。

349 ：デフォルトの名無しさん：2023/07/02(日) 21:56:05.97 ID:DcMb4mOQ.net

>>348
SyntaxHighlighter っていうのがよくわからないけど
VSCode拡張とかのこと?

350 ：デフォルトの名無しさん：2023/07/03(月) 07:33:58.97 ID:VgAxDpje.net

>>349
えぇｴ～それぐらいネットで調べ「てく」ださいよ～～。
伝えるのめんど「い」し、説明上手くないからネッ-トで調べた方が絶対%絶対%にわかると思うんですよね。
お願いしますよ～～

351 ：デフォルトの名無しさん：2023/07/03(月) 10:05:16.82 ID:erf1sDFe.net

>>350
うわぁ～
怖い

引っ込んでます

352 ：デフォルトの名無しさん：2023/07/03(月) 12:35:43.48 ID:VgAxDpje.net

>>351
恐がらせてごめん。

353 ：デフォルトの名無しさん：2023/07/04(火) 04:16:26.79 ID:YbUZ4vjn.net

Nim言語はコンパイル時にreadFileとwriteFileを使えるんだけどコンパイル時にファイルを読み書きできるプログラミング言語ってあまりないんじゃないか?
staticExecていうコンパイル時にコマンドを実行できるプロシージャもあるし。

354 ：デフォルトの名無しさん：2023/07/07(金) 02:08:00.59 ID:B1cwSpdy.net

どっかで既出かもしれんけど、結局VSCの拡張は何入れれば安牌？

355 ：デフォルトの名無しさん：2023/08/01(火) 18:27:12.50 ID:JtUN40O9.net

https://github.com/nim-lang/Nim/releases/tag/v2.0.0

356 ：デフォルトの名無しさん：2023/08/02(水) 00:52:58.78 ID:4aCNkU8+.net

Nim 2.0がリリースされました。
https://nim-lang.org/blog/2023/08/01/nim-v20-released.html

357 ：デフォルトの名無しさん：2023/08/26(土) 23:20:45.36 ID:6K2VICrE.net

初めてお邪魔します

下のスレッドでフィボナッチ数列(回帰関数)のベンチマークをやったのですが
Nim 2.0がダントツの速さでした

原因が分かる方、教えていただけますでしょうか、よろしくお願いいたします

Qiita 3 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1685235361/368-371
https://mevius.5ch.net/test/read.cgi/tech/1685235361/373-375

上記スレ、fibonacci(44)の計算、抜粋

Nim(44はコマンドライン引数)
https://wandbox.org/permlink/WoYP0STRKxaRBGCY
>Time= 0.240s Result=701408733

C/gcc(44はソース直書き)
https://wandbox.org/permlink/9OYZBH14tYooZHF7
> Time: 0.89583 seconds

C/clang(44はソース直書き)
https://wandbox.org/permlink/U97PecZYrzymnfH4
>Time=1.58712s Result=701408733

358 ：デフォルトの名無しさん：2023/08/27(日) 00:54:05.78 ID:M561FwxM.net

>>357
Nimでコンパイルするときに'--listcmd'オプションを与えるとNimがgccを呼び出すときにどんな引数を渡しているか表示されるようになります。
もしかすると凄く最適化されるようなオプションを渡しているのかもしれません。

359 ：デフォルトの名無しさん：2023/08/27(日) 01:58:10.81 ID:CxwZcjGE.net

>>358
早速の回答ありがとうございます

wandboxのspeedだとO3が見られたので、nim.cfgに gcc.options.speed = "-O2" を追加してついでに-d:ltoも外しました

Nim 2.0.0 + gcc 12.2.0(-O2) --verbosity:2 --listcmd --passL:-s (strip symbols)
https://wandbox.org/permlink/RVJ4eHKKl5DARK3u

>CC: prog.nim: /opt/wandbox/gcc-12.2.0/bin/gcc -c -w -fmax-errors=3 -O2 -I...
>Hint: /opt/wandbox/gcc-12.2.0/bin/gcc ... -lm -lm -lrt -s -ldl [Link]
>Hint: mm: orc; opt: speed; options: -d:danger

>Time= 0.274s Result=701408733
>Time= 0.252s Result=701408733
>Time= 0.251s Result=701408733
>Time= 0.250s Result=701408733
>Time= 0.250s Result=701408733

今度は確実に LTO無し gcc -O2 になりましたが、実効速度はダントツに速いままでした
何か気が付く点がありましたらまた今度教えてください (私の方は今日は限界です...)

360 ：デフォルトの名無しさん：2023/08/27(日) 17:22:00.42 ID:P6KX7G/o.net

>>359
Nim言語が高速なのはC言語コードを吐き出した時に
再帰処理をgotoループに置き換えている可能性があります
その場合C言語のオプションをいくら変更してもあまり意味はない
です

確認はコマンドライン引数に --nimcache:.cache を加えて
コンパイルして.cacheフォルダ内のC言語ファイルを確認すれば
わかるはず

nim c --nimcache:.cache -d:release ...

-d:relsese の部分は -d:danger で 置き換え可能で
dangerのほうが高速です

詳細はここ
https://nim-lang.org/docs/nimc.html

コンパイル型言語のベンチを取る時は再帰処理コードは
避けた方が良いと思います

361 ：デフォルトの名無しさん：2023/08/27(日) 17:25:13.06 ID:P6KX7G/o.net

>>360 追記
末尾再帰になっている可能性もありかな

362 ：デフォルトの名無しさん：2023/08/27(日) 22:36:37.59 ID:M561FwxM.net

Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。
gccは再帰関数をループに置き換えているかもしれないからその確認をしたかったら-S -masm=intelを付けてアセンブリコードを出力させて読んでみよう。

363 ：デフォルトの名無しさん：2023/08/28(月) 06:30:35.88 ID:eKgmQu1D.net

>>360
変換キャッシュの見方、ありがとうございます

>再帰処理をgotoループに置き換えている可能性があります
確認したところ、置き換わっていませんでした

>コンパイル型言語のベンチを取る時は再帰処理コードは
>避けた方が良いと思います
↑ここ詳しくお願いします

>再帰処理をgotoループに置き換えている
↑こうなっていませんでしたが、これ前提での話だったのですか?

再帰fibonacciは個別の言語コンパイラ(更にバージョン)の
最適化ベンチマークには持って来いに見えますので

364 ：デフォルトの名無しさん：2023/08/28(月) 06:40:36.37 ID:eKgmQu1D.net

>>362
>Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。
その通りでした

確かめたところ二つの再帰関数コールがそのまま残っていて、
その他はNimのトランスパイル過程でのノイズがあるだけです

gccがノイズを消すために最適化を頑張った結果、Cより速くなったのですかね

365 ：デフォルトの名無しさん：2023/08/28(月) 06:47:48.48 ID:eKgmQu1D.net

何気にNim + gcc HEADにしてみたら、更に速かったです

Nim 2.0.0 + gcc 12.2.0 -O2 (44はコマンドライン引数)
https://wandbox.org/permlink/RVJ4eHKKl5DARK3u
>Time= 0.250s Result=701408733

これ↑がこう↓

Nim 2.0.0 + gcc HEAD 14.0.0 -O2 (44はコマンドライン引数)
https://wandbox.org/permlink/cpYesJtnlRNJiu7Z
>Time= 0.197s Result=701408733

参考値再掲(>>357)
C/gcc -O2 (44はソース直書き)
https://wandbox.org/permlink/9OYZBH14tYooZHF7
> Time: 0.89583 seconds

C/clang -O2 (44はソース直書き)
https://wandbox.org/permlink/U97PecZYrzymnfH4
>Time=1.58712s Result=701408733


gccの最適化が凄すぎて意味わからないですが、ありがたく享受する事にします

366 ：デフォルトの名無しさん：2023/09/06(水) 06:10:42.54 ID:8VjD58re.net

レバテックωωω
Rust in
Nim out
ωωωωωω

367 ：デフォルトの名無しさん：2023/11/15(水) 08:06:37.71 ID:6Kiw7POr.net

>>353
F#が、 F# Dataってライブラリで、コンパイル時に
ファイルの読み取りは、やってたけれど、あまり見かけないね。

368 ：デフォルトの名無しさん：2023/11/28(火) 09:23:46.10 ID:XbNpNPYt.net

happyxってdjungoの上位互換なれねーかな
https://hapticx.github.io/happyx/#/

369 ：デフォルトの名無しさん：2023/12/06(水) 09:31:30.20 ID:oM0gjrfW.net

>>367
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 は我々に教えてくれます

370 ：デフォルトの名無しさん：2023/12/06(水) 20:32:47.84 ID:7Cu2FhSW.net

Nim って python を強調し過ぎてるのはミスリードだと思うな
python と相性が良いってのは事実だけど Nim の特徴のほんの一部でしかない

371 ：デフォルトの名無しさん：2023/12/08(金) 21:38:37.62 ID:xBCOoZoU.net

>>370
Python使える人が多いからNimを広めるためにNim言語はpythonと同じだという人は多い。
文法がpythonに近いだけで中身は静的型言語だからpythonよりC++とかRustに近いと思う。
pythonしか知らない人がNimのオーバーロードとかGenericsとかobjectとref objectの違いとかちゃんと理解して使えるのかどうか心配になる。

372 ：デフォルトの名無しさん：2023/12/10(日) 11:41:19.18 ID:1MxEINjf.net

「文法がpythonに近い」が事実じゃないんだよな
観た目が似てるだけであって文法が似てる訳じゃない
全然別物

373 ：デフォルトの名無しさん：2023/12/10(日) 17:02:37.56 ID:S5Hrhavn.net

そういう意味では構文で結構損してそう
オフサイドルールが気に入らない人にとってはそもそも検討に値しないし
Python好きな人ならそこは気にならないだろうけど、別に移行しやすくもない

374 ：デフォルトの名無しさん：2023/12/11(月) 04:52:12.28 ID:E9pPgJ3z.net

>>373
でも静的型言語でオフサイドルールの言語はNimとcrystal以外あまりないのでは。
オフサイドルールが好きで型システムがちゃんとしていて高速に動くプログラムを書きたい人にはぴったり。

375 ：デフォルトの名無しさん：2023/12/11(月) 06:10:19.79 ID:dU0p99Eo.net

型で安全性を静的に担保したいと考える人が、同時にインデントで意味が変わってしまうオフサイドを好むってのはちぐはぐさを感じる

376 ：デフォルトの名無しさん：2023/12/11(月) 06:46:36.74 ID:Oijs0Efp.net

HaskellとデフォルトF#もオフサイドルールありですね。どうせインデントするんだしって使ってやれってくらいの感じなのかね？

あとは、インデントに意味はないけれど、goが標準のフォーマッタでインデント入れてくるね。

377 ：デフォルトの名無しさん：2023/12/11(月) 06:54:57.74 ID:n3cFiyWX.net

Python登場当時だと{}前後のどこで改行するか論争みたいなのがあったりして確かに括弧書くのが面倒な空気はあったんだよな
それがGo/Rustの世代だと言語標準のフォーマッタが勝手にやってくれるってなって
めんどくさくないっていうオフサイドのメリットはなくなってしまった
そうすると自動フォーマットしづらいとかコピペしづらいとかデメリットばかり目立つことになってしまう

378 ：デフォルトの名無しさん：2023/12/12(火) 04:50:08.02 ID:X9wYEqIf.net

ブロック毎に'{}'や行末に';'があるとソースコードが少し汚く見えるし
無いとすっきりして読みやすいと思うけどね。