On Wednesday, 9 October 2019 at 13:52:18 UTC, IGotD- wrote:
> One Achilles heel of Nim is that it compiles via C or C++. This means in a debugging environment you will be watching the environment of the intermediate language. There workarounds for this described here.
>
> https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#using-gdb-lldb
>
> However, this doesn't solve everything. Also all the variable are intermixed with generated symbols, probably with some ugly hash added to it. Languages that directly compiles to the target like D will give a better debugging environment.
>
> There is a attempt make Nim compile via LLVM instead.
>
> https://github.com/arnetheduck/nlvm
>
> not sure if it is in any productive state yet. Also Nim seems to allow C to intermix and all sorts of built in C features that will not work when going via LLVM. Trying to merge Nim with C features is a bad decision in my opinion.

There are some things I'm not happy with either. But I think, as has been mentioned before, the purpose of Nim is to be a "native Python", i.e. it produces fast native stand alone binaries and you don't need Cython or an interpreter (Nim does that in one go). So the route via C/C++ seems acceptable from Nim's point of view. As I have no real world experience with Nim, I don't know how often you'll actually need to go low-level when debugging.

On Wednesday, 9 October 2019 at 14:00:46 UTC, Chris wrote:
> There are some things I'm not happy with either. But I think, as has been mentioned before, the purpose of Nim is to be a "native Python", i.e. it produces fast native stand alone binaries and you don't need Cython or an interpreter (Nim does that in one go).

Interesting that you take that viewpoint, that seems also to be the angle some in the press are going with:

https://www.zdnet.com/article/python-inspired-nim-version-1-0-of-the-programming-language-launches/

I personally think that probably won't work out for Python programmers, but it is at least a good marketing strategy. Although if compiled Python is the goal the goal, I'd think that Go would be the best "VM" today.

> So the route via C/C++ seems acceptable from Nim's point of view. As I have no real world experience with Nim, I don't know how often you'll actually need to go low-level when debugging.

What works reasonably well in the JavaScript world for TypeScript is source-maps. So that you step through the TypeScript code, but the debugger executes JavaScript.

Something similar ought to be possible for C, but probably takes a commercial-level effort to be usable.

On Thursday, 10 October 2019 at 08:16:40 UTC, Ola Fosheim Grøstad wrote:

>
> Interesting that you take that viewpoint, that seems also to be the angle some in the press are going with:
>
> https://www.zdnet.com/article/python-inspired-nim-version-1-0-of-the-programming-language-launches/
>
> I personally think that probably won't work out for Python programmers, but it is at least a good marketing strategy. Although if compiled Python is the goal the goal, I'd think that Go would be the best "VM" today.
>

Well, with the advent of GraalVM that already supports Python [1] and R [2], it will be much harder for Nim to convince Python users and data miners who use R to make the switch. If you have one VM that is polyglot you can combine all the widely used tools, e.g. Java/Kotlin for server/backend, desktop and (maybe) apps, Python and R for stats.

[1] https://www.graalvm.org/docs/reference-manual/languages/python/
[2] https://www.graalvm.org/docs/reference-manual/languages/r/

On Thursday, 10 October 2019 at 10:40:00 UTC, Chris wrote:
> Well, with the advent of GraalVM that already supports Python [1] and R [2], it will be much harder for Nim to convince Python users and data miners who use R to make the switch. If you have one VM that is polyglot you can combine all the widely used tools, e.g. Java/Kotlin for server/backend, desktop and (maybe) apps, Python and R for stats.

Ekm...
GraalVM has poor Python support.

"Warning: The support for Python is experimental. Experimental features might never be included in a production version, or might change significantly before being considered production-ready."

On Friday, 18 October 2019 at 16:28:47 UTC, Marek Marczak wrote:
> On Thursday, 10 October 2019 at 10:40:00 UTC, Chris wrote:
>> Well, with the advent of GraalVM that already supports Python [1] and R [2], it will be much harder for Nim to convince Python users and data miners who use R to make the switch. If you have one VM that is polyglot you can combine all the widely used tools, e.g. Java/Kotlin for server/backend, desktop and (maybe) apps, Python and R for stats.
>
> Ekm...
> GraalVM has poor Python support.
>
> "Warning: The support for Python is experimental. Experimental features might never be included in a production version, or might change significantly before being considered production-ready."

Oh, I know that and they saliently state it on the website. But who knows, in 2 or three years GraalVM may be truely polyglot and take languages like Python to new places. But you never know. Oracle might just kill the whole thing again.