3 ms·

My (personal) problem with Nim is that it assumes a Unix universe for everything. Which is good until (1) you want to do something on Windows and (2) you want t

by ethin 1y ago

My (personal) problem with Nim is that it assumes a Unix universe for everything. Which is good until (1) you want to do something on Windows and (2) you want to use other Nim libraries from Nimble. Nim will happily allow you to use the MSVC compiler, but a lot of good libraries don't and force GCC via pragmas which directly pass compiler options to "just make it work" or something. Last time I tried discussing this in the Nim matrix chat, I got some... Quite hostile responses. Not in the insulting me way, but in the "bro, just use Linux" way. Maybe things have changed; when I did use Nim I found it to be quite the pleasant language to work with excepting the nimble library problem.

WesolyKubeczek 1y ago
There's another problem that whenever Windows Defender sees any executable produced with Nim, for some inexplicable reason it decides it must be malware. Which puts you in the uphill battle situation from the get go if you want to develop things for Windows. Which brings us to the "just use linux, bro" argument. Windows could be interesting, but imagine making a commercial piece of software with it and then beg each and every antivirus author to please not quarantine your .exe on sight. And this is quite similar to the old "just use Windows, bro" argument that has been exrtemely popular some years ago whenever someone asked how to make a piece of hardware work under Linux (it still is — whenever anyone tries to extend battery life on a Thinkpad).
miguel_martin 1y ago
I actually prefer atlas (see: https://github.com/nim-lang/atlas https://github.com/nim-lang/atlas) to nimble now, it clones dependencies to to a local `deps/` folder relative to the project. It also supports adding local folders to the nimble path for management (via `atlas link` - see docs here: https://github.com/nim-lang/atlas/blob/master/doc/atlas.md#link- https://github.com/nim-lang/atlas/blob/master/doc/atlas.md#l...), i.e. you can clone your dependencies yourself via git submodule or a manual git clone To solve your woes, fork and patch the code you need to in order to support pragmas for MSVC. And in atlas, use your fork's git path and if you choose to: submit a PR to the project. You can edit the project locally until something works.

by ethin 1y ago

WesolyKubeczek 1y ago

There's another problem that whenever Windows Defender sees any executable produced with Nim, for some inexplicable reason it decides it must be malware. Which puts you in the uphill battle situation from the get go if you want to develop things for Windows. Which brings us to the "just use linux, bro" argument. Windows could be interesting, but imagine making a commercial piece of software with it and then beg each and every antivirus author to please not quarantine your .exe on sight. And this is quite similar to the old "just use Windows, bro" argument that has been exrtemely popular some years ago whenever someone asked how to make a piece of hardware work under Linux (it still is — whenever anyone tries to extend battery life on a Thinkpad).

miguel_martin 1y ago

I actually prefer atlas (see: https://github.com/nim-lang/atlas https://github.com/nim-lang/atlas) to nimble now, it clones dependencies to to a local `deps/` folder relative to the project. It also supports adding local folders to the nimble path for management (via `atlas link` - see docs here: https://github.com/nim-lang/atlas/blob/master/doc/atlas.md#link- https://github.com/nim-lang/atlas/blob/master/doc/atlas.md#l...), i.e. you can clone your dependencies yourself via git submodule or a manual git clone To solve your woes, fork and patch the code you need to in order to support pragmas for MSVC. And in atlas, use your fork's git path and if you choose to: submit a PR to the project. You can edit the project locally until something works.