I don't know when Nim 2.0 will ship or the features it will have, only Araq and
Co can know this. But for me Nim "2.0" is "mostly" here. With enough flags and
using some different libraries I basically have Nim that is very different to
Nim 1.0 and I feel it's worthy to call it Nim 2.0.
## \--mm:orc
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.
## \--threads:on
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.
## {.experimental: "overloadableEnums".}
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.
For example:
* `haLeft` for "horizontal align left"
* `laLeft` for "layout left"
* `cssLeft` for "CSS left"
* `svgLeft` for "Svg left"
With `overloadableEnums` all basically can be left now. It's just:
* `Left` for "horizontal align left"
* `Left` for "layout left"
* `Left` for "CSS left"
* `Left` for "Svg left"
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>
## macro `.`
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 ...
Run
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>
## -d:ssl -> puppy
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>
## zip/zlib.nim -> zippy
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>
## async stack traces
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.
> ISSUE: Async stack traces are super bad.
> <https://github.com/nim-lang/Nim/issues/19931>
