Controversial opinion but I'll just leave it out there because I'm a fan of Nim:

Halt Nim 1.0 until Nim 2.0 destructors suggested in is standardized. Eventually for systems programming people will want to do manual memory management. It also gives you an extra market so people don't just discard Nim just because it has a thread unsafe GC.

The market for manual resource management and RAII will never end and C++ will always be there for this. Why not penetrate this area where people advocate Rust so much? Systems/Games people want fully deterministic performance more than safety afaik.

Also, with package repo... ( does NOT look scalable to me.

Just saying. Thanks for reading.

2018-05-09 03:41:46

@aedt I think it's a question of resources.

Given the current promising state it would be better to release now, garnering interest and goodwill and probably new hands to help on ironing bugs and use cases that the current tiny community doesn't need in my opinion.

Also that allows those with interest to pitch in before the door is closed. The current GC/manual memory management is already good enough to start doing productive stuff with Nim (alloc0, allocShared, ptr object).

2018-05-09 08:31:02

+1, mratsim.

What I want is convenience and still catering for people who wanted more performance for low level stuff. Convenient and practical.

2018-05-09 09:00:34

@aedt don't really think that is a good idea at all re halting Nim 1 for destructors.

Nim can be/is a good general purpose language.

If you look at any top 10 programming languages list only C and C++ have manual memory management. Most top 5 lists now days will also include Python, Javascript, Java and C#. The majority of programmers use GC languages.

So why limit all the majority to satisfy a minority of programmers by holding back version 1?

Most GC based languages have challenges and trade offs when it comes to threads and for most purposes Nim's thread model while it may not be ideal is good enough.

This Perfecting Nim thread is the wrong mental frame.

No programming language is perfect. They all have trade offs. Like every other language Nim will not be perfect. So its time to get over that idea, release Nim 1.0 this year, and the destructors can continue to be worked on for version 2.

If perfection or nearing perfection was a requirement for a successful language then languages like PHP and Javascript would not have enjoyed the success they have.

2018-05-10 01:10:18

We are talking past each other due to multiple possible interpretations of english language terms (do we need a technical standard for english?).

I'm using the term standard in the sense of technical standard as described in Wikipedia. Let's denote a standard library interpreted this way as a standardised library.

However, the Nim community seems to interpret the term standard as an adjective as in "a standard hotel room", - synonym with terms such as normal, usual, baseline, customary or prevailing. Let's denote a standard library interpreted this way as a de-facto library.

I'm using the term Nim 1.0 language (specification) in the sense of ISO/IEC 9899:2011 language (specification), which includes, among other things, the C standard library. However, the Nim community seems to interpret the term Nim 1.0 language in stricter sense as the things specified in Nim manual (specification).

I'm inclined to agree that at this point of Nim language maturity there is no need to rigorously specify a standarised library. However, the need may raise later when competing implementations start to appear. The BASIC programming language is a cautionary example of how a language may disintegrate into non-compatible dialects with their own sets of documentation if no adherence to a specification is required (and with things like MicroPython, Python seems dangerous too...).

With these readings in mind, it makes sense to state that the de-facto library that ships as part of the Nim reference implementation is not part of the Nim language specification and therefore out-of-scope problem in perfecting Nim. Some concerns still remain:

  • The Nim reference implementation should be made available as source and as installation (the language part implementation of the compiler without any out-of-spec-libraries bundled in)
  • Will there be any assurance that the de-facto library will remain backwards-compatible after 1.0 (append-only, deprecation marks instead of replacements)?
  • Some elementary arithmetic and string handling functions like sqrt and intToStr should be moved from library to language specification to make the language more general-purpose.
  • It is unfortunate that the Nim language and the Nim compiler are both called Nim (in contrast to C/gcc, Java/javac, Python/CPython, Go/gc, ...). To avoid confusion, the latter should be renamed to something else (nimcc? nimdom?), after which I'm grittingly willing to accept the liberal use of the term standard as in "nimcc standard library, the de-facto library for Nim language users").
  • It must be clearly stated somewhere which library modules are available for which environments and targets - maybe in some kind of table form.

I hope this helps.

2018-05-15 10:44:22