Nim v2: what would you change?

In reference to another thread about comparisons with Rust, I have recently been wondering about what Nim could be if it had the backing and manpower of Rust, feel like it has so much potential but currently doesnt have the means to realise it. Rustaceans are strange creatures, who in their righ

Nim v2: what would you change?

To respond in a facetious manner, we already have that! We do not but there are ordinal indexed arrays which you suggestion is ambiguous for. let x = 5 array1 = [false: 100, true: 300] assert array1[x > 3 and x < 5] == 100 Run To respond in a more since

Nim 1.6.6 released

I guess that would work but it would be nice if those environment variables could be set through choose in or the choose I’m installer.

Nim 1.6.6 released

It looks like it was failing originally because of permissions issues. As for custom `choosenimDir` I discussed with someone else recently: I would prefer an env var for this. Nimble already has one called `NIMBLE_DIR` so choosenim should have the same and then you'll be able to set `CHOOSENIM_D

Full-time Nim developer rates for new software company

I think that i want too, my contact dementishcherbakov8...@gmail.com Jack, developer

Nim 1.6.6 released

BTW, the good news is that I just tried again and it did work. The difference seems that it now said: `Extracting nim-1.6.6_x64.zip` Instead of : `Extracting nim-1.6.6_x8.zip` The bad news is that Symantec Endpoint Protection immediately detected nimgrap.exe as a Trojan.Gen.2. @dom96, my IT

Nim 1.6.6 released

Thank you @dom96. This is what I get: C:\Windows\system32>cmd /c echo int main^(^) { return sizeof^(void *^); } | gcc -xc - -o archtest && archtest c:/users/User/.choosenim/toolchains/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ca

Nim v2: what would you change?

> rust/haxe style enums instead of the currently confusing object variants With Haxe style enums, _Generalized Algebraic Data Types_ are possible. These haxe/rust style enums can be seen as datatypes on the fly. Look at: Whe

Nim v2: what would you change?

Herbceptions, anyone? The hard part of thinking it through is done: The other hard part is implementation in Nim :P

Nim 1.6.6 released

@didlybom I've seen others running into this in the past: . This code seems to be failing for you: . Do you have `gcc` in your PATH? can you see what happens when

Nim v2: what would you change?

Is there any proposal with regards to exceptions? Could they be made more efficient, either by breaking changes to their design and implementation or not?

Nim 1.6.6 released

I got the following error when trying to install the new version: > C:Windowssystem32>choosenim --verbose 1.6.6 > Info: No client ID found in 'C:UsersUser.choosenimanalytics', not sending > analytics. Info: No client ID found in 'C:UsersUser.choosenimanalytics', not > sending analytics. > >

Fidgets!

> I would suggest the nim maintainers to take this as official UI lib and > support eh developers and the original dev also who set the the core libs to > make this happen Fwiw I keep being interested in exploring this idea...

Nim v2: what would you change?

> I want all this macros to be in the stdlib. Many things can be achieved with > macro, but far less are actually implemented and standardized. This thread is for breaking changes. Adding more macros to stdlib is not a breaking chaige.

Nim v2: what would you change?

* rust/haxe style enums instead of the currently confusing object variants * inbuilt pattern matching (and not a macro based library)

Fidgets!

> Oh, it is but I really liked the idea of making "fidgets" out of Fidget. > Though FidgetWidgets has a rhyme. It's just that when importing module you'd potentially end up with : import fidget import fidgets Run which can lead to rather confusing situations this

Nim v2: what would you change?

> `array1[x > 3 and x < 5]` vs `array1.filterIt(it > 3 and it < 5)` Which one > do you prefer? The latter, because it's explicit.

Error: execution of an external program failed When using nim c -r --threads:on

`std/threadpool` and `spawn` are known to be broken, at least with ORC. Multiple tests in `tests/parallel` fail on Windows both for ARC and ORC. A couple segfault for ORC.

Nim v2: what would you change?

i prefer the one that doesnt break fundamental assumptions about how nim functions for a bit of builtin sugar.

CLOEXEC on old Linux kernel.

BTW, if you are hacking/replacing `posix.nim` then you may also want to know about the `patchFile` construct for `myModule.nims`.

Fidgets!

> For theming either you create a new set of theme style that could better fit > as across platform or use ex. Material Design theme as main theme till theme > support will be better. I'm open to people helping with themes. I just did the bare minimum. > I prefer to have agreements with the ori

Fidgets!

Oh, it is but I really liked the idea of making "fidgets" out of Fidget. Though FidgetWidgets has a rhyme.

CLOEXEC on old Linux kernel.

It looks like asyncdispatch checks to see if `accept4` is declared, and only then uses SOCK_CLOEXEC. I'd try editing posix.nim [here](https://github.com/nim-lang/Nim/blob/927978345bbf57631828287850eda13b82277eb7/lib/posix/posix.nim#L921) and adding another guard, like (defined(li

Nim v2: what would you change?

I want all this macros to be in the stdlib. Many things can be achieved with macro, but far less are actually implemented and standardized.

Nim v2: what would you change?

Strictly speaking all abstractions are possible even in a low level programming language like C if you do them yourself. My point is when I have a task at hand 1) I want to start working directly on the task with already implemented, standard, well-thought, out-of-the-box high-level abstractions

Nim 1.6.6 released

Here is our third patch release for the latest stable (1.6) version of Nim — 1.6.6! Read more:

Nim v2: what would you change?

> * Estensible Scheme-style eager comprehensions that cover all > language-supported data types (e. g. array, seq, set, table) and allow > concise, expressive and flexible generation, collection, transformation, > filtering, aggregation, folding and side-effecting on the above mentioned > typ