Nim v2.0.0 RC2 is out

> What about the idea that came up here at some point that the stdlib could > just be a list of curated nimbles, maintained or at least selected by the Nim > compiler developers? That's we're heading but the more we do it, the harder it becomes to port code over to 2.0, so we don't try too hard

Nim v2.0.0 RC2 is out

What about the idea that came up here at some point that the stdlib could just be a list of curated nimbles, maintained or at least selected by the Nim compiler developers? With stdlib being nimbles, we can imagine that a next version of the compiler will re

Nim v2.0.0 RC2 is out

this should be the [installing v2](https://nim-lang.org/blog/2023/03/31/version-20-rc2.html) of the docs

Nim v2.0.0 RC2 is out

`nimble install db_connector` import db_connector/sqlite3 Run

Nim v2.0.0 RC2 is out

Is there something wrong with `sqlite3` and this release? I tried to compile with this last version and seemingly it's complain about the module not being found: Error: cannot open file: sqlite3 Run

Nim v2.0.0 RC2 is out

* `nimble install db_connector` nimble install db_connector Downloading https://github.com/nim-lang/db_connector using git Warning: The package has no tagged releases, downloading HEAD instead. Verifying dependencies for

Nim v2.0.0 RC2 is out

Has anyone managed to use sqlite from a 2.0-rc2 build? The changelog notes: - Several Standard libraries are moved to nimble packages, use `nimble` to install them: - `std/db_sqlite` => `db_connector/db_sqlite` Run .. but that doesn't seem to live in the nimble

Nim v2.0.0 RC2 is out

> Advertising one, and not mentioning the great alternatives, confuses > newcomers a lot. The point was that the stdlib should offer a single thing. And "newcomers" might indeed be confused by choice. Which is a terrible argument in itself as: 1. The set of newcomers is not a homogenous group

Nim v2.0.0 RC2 is out

> The stdlib provides pegs: When you advertise that, you should at least also mention the great \-- even when you may have your reasons to dislike that one. Advertising one, and not mentioning the great alternatives, confuses newcomers a lot.

Nim v2.0.0 RC2 is out

The stdlib provides pegs: \- which potentially could be safer than regexps.

Nim v2.0.0 RC2 is out

For what is worth, I think having a regular expression library in the stdlib is essential given the fact that (I think!) nim is used pretty frequently to implement command line tools. I also agree that having 2 versions in the std library is confusing. Personally, I'd prefer having a pure Nim r

Nim v2.0.0 RC2 is out

Good points! `async`, `json` and `threadpool` are different because their alternatives live in nimble. stdlib gives you clear guidance that you can follow or deviate from. You can invest brain cycles in a proper evaluation, but in a pinch you can accept stdlib's suggestion and move forward more

Nim v2.0.0 RC2 is out

You could make a good argument about that if it were good for adoption to argue with new users.

Nim v2.0.0 RC2 is out

> It depends. The one I fixed gave ["f", "oo", ""] splitting "foo" with a zero > length expression. I remember but IMHO zero length expressions should simply not be allowed for splitting. :-)

Nim v2.0.0 RC2 is out

> But your other points are good. Thank you! > "Bugs" can be subjective, there is no pressure to "fix" them It depends. The one I fixed gave ["f", "oo", ""] splitting "foo" with whitespace. Complying with Perl's behavior might not be as critical but it we can start considering `re` a "comfort

Nim v2.0.0 RC2 is out

> What's important is to remove friction Personally, for me decisions between threadpool/taskspools and Nim's async vs. Chronos or the various JSON implementations have never been easy. Similar for all the GUI attemps, but for GUIs it is not so difficult to select the one which one likes best,

Nim v2.0.0 RC2 is out

> And why do you think nobody is fixing those re bugs? "Bugs" can be subjective, there is no pressure to "fix" them. But your other points are good.

Nim v2.0.0 RC2 is out

And why do you think nobody is fixing those `re` bugs? Would you improve something with a perceived 50% chance of premature removal? It took a notorious risk-taker like me to fix even a glaringly obvious one. So what if `nre`'s API is marginally better? As you pointed out many times, if you wan

Nim v2.0.0 RC2 is out

We cannot deprecate nre as many people think it's just the better API. It also has fewer quirks and bugs. At the same time Nim's tools continue to use `re` as it came first and it's not easy to port them over (I tried). Yet at least one pure Nim regex implementation exist that even support runni

Nim v2.0.0 RC2 is out

All I want is faster compile times.

Nim v2.0.0 RC2 is out

See:

Nim v2.0.0 RC2 is out

This would be a lot less of an issue with a compiled language like Nim. It's not like your script you have running on a production server is going to start failing if Nim updates unless you recompile it. So as long as the developer is aware of which version was initially used to build it (which

Nim v2.0.0 RC2 is out

Hard data is good when you have it but an impossible standard for every decision (and can have its own perils). Hence, my falling back the educated guess. I think that we would be losing zero users because of re/nre is downright implausible. I can't think of a programmer I know who doesn't use

Nim v2.0.0 RC2 is out

> How can this be the language to rule them all if they can't decide on a regex > library? Is this what we want them to be thinking about? Pure speculation. Nobody knows how many users we lose because of nre being in the standard library (zero?). Nobody knows how many of these potential new use

Nim v2.0.0 RC2 is out

> each time we do it it adds friction to somebody's porting efforts I wouldn't recommend it lightly, but in this case I'd go as far as to say it's close to imperative with an eye on helping new users. Learning a new programming language is special because you are simultaneously studying and eva

Nim v2.0.0 RC2 is out

Looks like if I unset `NIMBLE_DIR` then `nim c` works fine.

Nim v2.0.0 RC2 is out

> Did something change regarding Nimble dependency resolution ? > Some repo > don't find dependency when the packages is installed. I believe there was -- it seems Nimble now requires the package to be listed in the project's `.nimble` file.

Nim v2.0.0 RC2 is out

> Never keep supporting a deprecated/superseded version. I don't think this is realistic but thanks for your uncommon opinion. (No irony here!)

Nim v2.0.0 RC2 is out

Happy to see this being an "evolution" rather than a "revolution"... One of the things worst about Python is its madness with version 2 vs 3. It literally _broke_ tons of operating systems under my control & systems from other people I know personally & from people I have talked to online. Plea

Nim v2.0.0 RC2 is out

Did something change regarding Nimble dependency resolution ? Some repo don't find dependency when the packages is installed.

Nim v2.0.0 RC2 is out

> Is this part of a comprehensive push to make all error messages ergonomic to > users? Or is this really an improvement concerning simple type mismatches at > the use site (judging from the example given)? It's an improvement for the most common error message. There is no principled push to im

Nim v2.0.0 RC2 is out

Compared to the RC1, we have many ORC-related bugfixes, but the most crucial difference for ordinary users are the vastly improved error messages Run Is this part of a comprehensive program to make _[all](https://forum.nim-lang.org/postActivity.xml#all) error messages ergonom

Nim v2.0.0 RC2 is out

Since this is a unique opportunity for breaking changes- Wouldn't it be a good time to put `nre` into a nimble package?

Nim v2.0.0 RC2 is out

When using the compiler available via homebrew, it generates an arm64 executable: $ /opt/homebrew/bin/nim --version Nim Compiler Version 1.6.12 [MacOSX: arm64] Compiled at 2023-03-10 Copyright (c) 2006-2023 by Andreas Rumpf active boot switches: -d:release -d:nim

Nim v2.0.0 RC2 is out

> Stable version points to 1.9.3 instead of 1.6... Sorry I messed this up yet again, the build program does not automate "release candidates" properly. It should be fixed now.

Nim v2.0.0 RC2 is out

I have the same problem except I cannot even install choosenim because of it. Stable version points to 1.9.3 instead of 1.6... deck@ubuntu-22-10:~$ curl https://nim-lang.org/choosenim/init.sh -sSf | sh choosenim-init: Downloading choosenim-0.8.4_linux_amd64 Prompt: Can ch

Nim v2.0.0 RC2 is out

> Is this expected on macOS M1? I used to have the same problem but I don't remember what I did about it. :-) OSX is weird.

Nim v2.0.0 RC2 is out

So is the situation with exceptions going to stay the same?

Nim v2.0.0 RC2 is out

Wow, my boy `.forbids` will get into mainline! It can be used to enforce logical order at compile-time in some cases.

Nim v2.0.0 RC2 is out

Is this expected on macOS M1? $ file ./bin/nim ./bin/nim: Mach-O 64-bit executable arm64 But after compiling a simple hello.nim file: $ file ./hello ./hello: Mach-O 64-bit executable x86_64 Can be specific to my system. Compiled from source. > Nim Compiler Version 1.9.3 [MacOSX: arm64] Compil

Nim v2.0.0 RC2 is out

Small improvement suggestion: I think the title "Nim 2.0.0 RC2" instead of "Version 2.0.0 RC2" would be more expressive, for example when the link is posted on another website without Nim context, which uses the page title as a description of the link.

Nim v2.0.0 RC2 is out

Yes it is unrelated with choosenim, I have seen a couple of messages in the internals channel about it in the Matrix server. I confirm that choosenim update "#version-2-0" does install 1.9.3

Nim v2.0.0 RC2 is out

Not sure it is related, but something is broken with stable channel and 1.9.3:

Nim v2.0.0 RC2 is out

Does `choosenim "#version-2-0"` works ?

Nim v2.0.0 RC2 is out

Very nice! Would be good though with choosenim install instructions as well

Nim v2.0.0 RC2 is out

The second release candidate for Nim v2.0.0 is ready for testing! See more: