Nim programming language finally hit 1.0

[Chris]

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.