This is a thread that I wanted to create myself in preparation for v1. Thank you for creating it. For everyone reading this thread: please let us know your opinions of what needs to go before v1 is released.

I'll probably read everyone's answers later, but here is the quick small list off the top of my head:

  • do notation, it always felt unnatural in Nim to me and I dislike it to this day.
  • coro module, it doesn't seem to be used much.
2018-04-23 22:50:06
Replying because thread is broken and 3rd page is linked but 404s 2018-04-24 01:08:51
Completing my first answer with tings that came up after:
  • converters currently are a bit unsafe. They can happily trigger ambiguous calls when a converter to numeric type exist. I don't mind them going especially if the int literal stuff is sorted out. Or it would be nice if we could restrict implicit conversion like it can be done to template:
  • discardable, I feel this should be explicit by default, too easy to discard error codes. Can be moved to sugar.nim
  • TaintedString: it's a good idea, reminds me a bit of the Haskell IO Monad in practice though, a bit cumbersome to use. At the very least parseutils should provide useful proc to deal with those otherwise I guess everyone is just doing $tainted. Also it's another concept that will surprise (delight/block?) newcomers.
  • methods: I rely on them for the neural net part of Arraymancer, I don't mind them going as long as the replacement's performance is similar or faster as I call them several times per second and Nim's methods have very low overhead especially when inlined (only 3x the proc cost).
  • do: Yeah it's a super strange notation, I do need a way to have multiline arguments though.
2018-04-24 06:40:35
I think there are probably a lot more lower hanging fruit than 'do' notation and coroutines. 'do' notation is super handy. Coroutines is fairly fundamental for Actor model and generators. 2018-04-24 07:40:07

To be able to eat and keep the cake, consider a three-layered architecture: kernel, modules, distros.

Nim kernel Would contain just the core features so that Nim can compile itself and majority of Rosetta code problems can be solved. Very compact, very stable, very efficient, very well tested and documented. (But not designed to be very useful (or even expressive) without additional modules)

Nim modules When kernel stuff is not enough, coder can install packages (modules and their documentation) from various repositories. Basically all language constructs that don't need magical compiler support should be implemented as additional modules (as macros, I guess).

Nim distros Would contain the kernel and a pre-selected collection of modules, tools, extra documentation, and such enabling a flying-start to Nim development.

There should be three "official" distros available:

  • Nim Legacy: Anything you need so that your old Nim 0.18 code still compiles
  • Nim Standard: The standard Nim programming language environment (lean and mean)
  • Nim Dev: For those who develop the Nim itself

Then hopefully communities would emerge that curate distros for their needs: Nim for Android, Nim Gaming, Data Science Nim, Nim Web, Nim Enterprise Edition, ...

(And in a perfect world one could install multiple distros simultaneously without hassle)

This three-layered architecture could achieve the following:

  • Core devs (like writers of alternative compilers) can concentrate on perfecting the kernel
  • The decision of which features to include in 1.0 would not have such criticality (when in doubt, leave it out)
  • Availability of application-specific distros would keep anyone happy (all your favourite features are still pre-installed there!)

"We can solve any problem by introducing an extra level of indirection."

2018-04-24 08:11:32
from my point of view things that should go out:
  • do every time I read code which uses do I have to think hard what's going on.
  • using never used it and looks a bit strange to me
  • method is not really usable in it current shape. But we need some OOP.

things that should stay or improve:

  • converters at least we need a mechanism to do implicit controlled conversion. I am happy with something better.
  • exceptions we are not in a nim only world. If you interface with C++/JS code you will need them.
  • bitsets they are handy

one thing that should improve is object variants. In their current form they are very low-level and error prone and not very elegant. I would prefer something like GADTs or the Enums in Haxe. But this is completely out of topic for v1.

2018-04-24 12:15:18
I'm glad @arnetheduck started this thread. I appreciate his minimalist leanings and the nod to Antoine de Saint-Exupéry.
  • exceptions Can't live with'em, can't live without'em. I agree that they're questionable, but like @Araq said there's no obviously better alternative. I know that in D their implementation is tightly tied with the GC. Do they present problems for the GC free Nim we expect to see in the year 2525? In the SPARK subset of Ada exception handling is banned, though exceptions can be raised. Also, Rust is a different beast than Nim, maybe if Nim had algebraic data types we could use Option and Result types and do like Rust. I'd suggest leaving them alone for v1.
  • method I understand @mratsim's position I think; he'd like some kind of dynamic dispatch that is relatively inexpensive but not necessarily method. I think that's achievable before v1.
  • bitsets No one suggested removing bitsets, just moving them to a library. This is analogous to the discussion in D about moving associative arrays from the language to a library. This makes sense; if you can't write it so that it's efficient and convenient as a library, you can either modify the language so that it's possible (the solution I like) or make it a built-in. I believe as much as possible should be in libraries. I don't think it matters much whether this is fixed now or later, so maybe it is better to wait until after v1. @arnetheduck, do you have a reason that they need to go now?
  • converters Opinions vary here, I generally agree with the dictum that explicit is better than implicit, especially in a language with overloading. I'd like them gone.
  • do I have no strong feelings one way or the other on this one.
  • Enums with holes Good catch @GULPF, I agree, out with v1
  • {.discardable.} Another good catch, out with v1
2018-04-24 15:15:10

bitsets - I haven't used them but I know I will someday and I wouldn't remove them. If they can be moved to a nimble package, that's fine with me.

exceptions - I'm 100% behind Araq that "bubble up" is the right default. Yet, I tend to favor having a Result type (similar to Rust) and having a set of macros to rewrite code to achieve this (both block-level and proc/method-level, along the lines of Rust's try! macro but better) . I think it would be simplify Nim's core and also simplify the job of many macros. It's always tricky to deal with exception paths in macros such as async, iterators, etc. Disclaimer: I have not used any C++ code with Nim and don't plan to do so. Perhaps exception-throwing C++ code can be wrapped at the FFI layer such that it catches exceptions returns Result types. I wouldn't change anything for v1, and I'd go towards Result + macros for v2.

methods - I'd definitely remove them if we get concepts with vtrefs. Those who are suggesting the different nimble packages for interfaces (e.g. interfaced) have not tried them, I'm afraid. They work only for the really simple use-cases. At the very least, we would need to make them work with generics, which I expect will require some non-trivial work. Until that's done, and some project uses them extensively, it is not a reasonable alternative, IMO. I wouldn't change anything for v1 and I'd wish for concepts with vtrefs for v2 (if we're not getting them for v1).

converters -- They've been useful to me so far, so I wouldn't remove them. I haven't run into issues with them either.

do -- Very useful. I don't find the syntax/notation offensive.

2018-04-24 16:21:22

While excess can be bad, and there are inconsistencies that should be repaired, I think a "batteries included" stdlib is a good thing. E.g., the recent enumerate for loop macro in tests/macros/tforloop_macro1.nim should probably be in lib/pure/sugar.nim. I think the duplication (re and nre, parseopt and parseopt2) should go. mersenne does seem pointless. Maybe game programmers use basic[23]d? I think coro is a good example of low level programming in Nim, but I don't know if needs to be in the stdlib.

I like set[], "do", converters, and exceptions. Exception-free alternatives in the stdlib sounds good, though. I think using is a good idea. I don't usually use dynamic dispatch of any kind, but the Lisp world swears by multi-methods for such and they are more general than the usual first-slot-only OO dispatch. No opinion on holey enums vs distinct ints or discardable. I never liked non-case-sensitivity or TaintedString.

I think it would be nice if openArray could be more "open". It could become a first class concept needing only [], len, etc. when concepts are ready enough. That may be already planned.

2018-04-24 22:39:56

Default Not Nil (and cleaning up the associated initialization that springs from this).

Newbies always get caught with a seq that hasn't been initialised.

If you want nil, be explicit about it.

2018-04-25 00:02:57