It made a ton of code faster. It made thinking about memory simpler and is just better in every way. The optimization move and the predictable =destroy is a game changer.
ISSUE: It’s not default.
In the past compiling with --threads:on made Nim a lot slower due to using --gc:refc (And some other bugs...). Not any more with --mm:orc or with --mm:arc life is good. You can now allocate and pass everything between threads without resorting to unnatural c pointers or slow data copying.
ISSUE: It’s not default. > There are still some performance costs. 7% slower for pixie's tiger test we ran .. its not huge but significant. > Every alloc/dealloc requires a lock/unlock so even single threaded becomes slower.
Or the death of the win32 prefix. In the old Nim everything had this strange "hungarian win32 api inspired" prefix. Nothing else in Nim did.
Now when you say node.align = Left it will know which left you mean.
ISSUE: It’s not default. > https://github.com/nim-lang/Nim/issues/19930
This is great you can define:
macro `.`*(v: GVec234, fields: untyped): untyped =
## Adds support for swizzle getter.
## x y z w
## r g b a
## s t p q
## v.xyz, v.xxx, v.zyx ...
## v.rgb, v.rrr, v.bgr ...
## v.stp, v.sss, v.pts ...
And you can just generate v.xxx, or v.yzx, or v.bgr fields at compile time. Or any other field. It's beyond cool!
If you define even a single . or import a library using this, from then on every error will mention it for no reason. Its so annoying I stopped using it.
ISSUE: It’s not default. > Huge bug with errors! > https://github.com/nim-lang/Nim/issues/13063
You always need to remember to add the flag. If you don't, it's a runtime error! That is super hostile. SSL on windows continues to be an especially bad issue for Nim. On windows you need to ship 3 random DLLs and also a cert file that could not be revoked or updated. Oh yeah and SSLv3 has problems as well. I just wrote and use puppy. puppy is not for everything. If you have a http server, use normal nim's http stack. If you are scraping the web, use normal nim's http stack. But if you just need your simple app to download a file or make a couple of API requests - like 95% - of windows desktop software just use puppy. It will just use the native Win32 or MacOS APIs. puppy certs will update with OS updates and no DLLs are necessary. You can't ship static CA files and expect that to work long term.
ISSUE: People don't know about this library. > https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aopen+SSL
Using zlib on windows causes strange issues. You got your normal errors like zlib1.dll not found or it was a 32bit version, but you also had errors like some C structure does not match size during runtime. It appears that currently Nim is shipping zlib1.dll that nim bindings cannot work with on windows. It is strange. zippy library just fixes everything, and it's in pure nim, and it is oftentimes much faster than zlib. There simply is no reason not to use it.
ISSUE: People don't know about this library. > https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aopen+zlib
The {.async.} stack traces are beyond bad. They are long because they repeat a bunch of junk info. Just filtering out standard library async code out of the stack traces would go a long way.
It will become default after orc booting compiler can pass tests and severe arc/orc related issues are fixed.
Here is the PR that would make threads:on default. See also the solution which uses mimalloc in Nim with ARC/ORC and make threads + orc faster.
There is an alternative => parser: make dot operators (eg:.?) same precedence/associativity as .
puppy has its own problem. For me, it doesn't support multipart/form-data. I had to patch its curl backend.
@xflywind It is very exciting to see that work on --mm:orc and --threads:on. I believe these are huge improvements and both of these seem soooo close from the perspective of someone "just using Nim".
Regarding the puppy issue, is something making you use mulitpart/form-data? I thought it was mostly a way for web browsers / HTTP POST to support file uploads.
I see this post as really positive, pointing out how much Nim has continued to improve since Nim 1.0. It's easy to keep focusing on all the additional cool things Nim could do but I'd say some really awesome things have already been done.
Regarding the puppy issue, is something making you use mulitpart/form-data? I thought it was mostly a way for web browsers / HTTP POST to support file uploads.
Yeah, I was making a ipfs HTTP client and I need to post a file to a server.
Making Orc the default is not just a matter of fixing the remaining bugs, the compiler bootstrapped with Orc uses much more memory than the compiler that uses the old default GC. The primary reason for this is that the compiler's data structures have been optimized for the old GC and Orc changes the seq implementation. The compiler could use its own seq implementation that is optimized for its needs but this would be quite a refactoring.
However, nobody said that the compiler itself needs to use the default settings -- we can change the default to --mm:orc and let the compiler use the old GC. This is my preferred solution but I can already hear the "liar! fraud!" screams. ;-)
The primary reason for this is that the compiler's data structures have been optimized for the old GC and Orc changes the seq implementation.
This is where we are, those of us that actually have written lots of good Nim code
This is my preferred solution
Rewrite it in C while you're at it, nobody will notice that either ;)
Shouldn't at least files and sockets auto-close with Orc?
"uniformity over comfort". If it means that I have to think about whether auto-close works in 'this' situation/library, I'd prefer no auto-close at all.
Hey, Guzba and me created a whole video talking about the topic: https://www.youtube.com/watch?v=nyhkhB23tOQ
Let us know were we are wrong :)
Very nice video :-)
One other flag that I wish were set by default in nim 2.0 is -d:release. It would make nim "fast yet safe by default". I've seen too many messages in this forum and in other places where people were complaining about nim's speed because they did not know that they were compiling in debug mode by default.
People could always enable -d:debug when needed and perhaps that could be made to also imply --debugger=native, --stackTrace:on and --lineTrace:on? Not sure if that would have any serious drawbacks though...
Release would make compilation quite slower, especially because it makes the C compiler use the best optimizations. Also it'll be very unfriendly to developers, as you'll have to specify -d:debug in every project.
Nim already shows warning when compiling, if people can't see this it's their problem IMO:
Hint: used config file '/opt/wandbox/nim-1.6.4/config/nim.cfg' [Conf]
Hint: used config file '/opt/wandbox/nim-1.6.4/config/config.nims' [Conf]
.........................................................
CC: stdlib_digitsutils.nim
CC: stdlib_dollars.nim
CC: stdlib_io.nim
CC: stdlib_system.nim
CC: prog.nim
Hint: [Link]
Hint: gc: refc; opt: none (DEBUG BUILD, `-d:release` generates faster code)
26615 lines; 0.337s; 31.531MiB peakmem; proj: /home/jail/prog.nim; out: /home/jail/prog [SuccessX]
Release would make compilation quite slower
Just using gcc -Og instead of gcc -O0 makes compile times quite a bit longer https://forum.nim-lang.org/t/8677#56724
Not sure why the default nim.cfg does that, but maybe less necessary suffering infliction upon pre-learning-how-to-hack-their nim.cfg users now that we have a DEBUG BUILD warning message?
maybe i'm asking questions in wrong place.
are 3rd libs ready for nim 2.0's --mm:orc? especially nim-chronos. or, how can i tell whether a 3rd lib is ready for --mm:orc
are 3rd libs ready for nim 2.0's --mm:orc? especially nim-chronos which i use heavily. or, how can i tell whether a 3rd lib is ready for --mm:orc?
I have a PR tracking whether important packages work with ORC => https://github.com/nim-lang/Nim/pull/19972
According to https://github.com/nim-lang/Nim/runs/7340659723?check_suite_focus=true, chronos probably pass the CI with orc.