Wow, I see most of you guys don't like the index & library list as much as I do. They're not bad, in my opinion.
@bluenote Dependency avoidance... Well... It wouldn't be a real problem if dependencies were solved automagically (see: Rust). ^^" Btw. that's a hell of a nasty line you quoted! Adding spaces in a for loop? It's horrible! You actually convinced me to look for a Rust string interpolation lib. Or create a procedural macro for that, if it doesn't exist yet. @mikra I had some problems with Slice and Range too, actually. ^^" More so with why static didn't work as expected (it's much better now though) despite working in the examples. Simple examples, I'd add. About the easiest build system --- try Rust. It's even easier. And Scala has a build system quite similar to Nim. Hell, even Fortran has it's build system (FoBoS), which is roughly as advanced as Nim's one so I guess it's not that huge an advantage, actually. It's just... modern. Actually, as much as I hate Java, I need to admit it's a good example of nice docs. Glad you brought it up. @all Well, I had a break using Nim. What really puzzled me that recommended project structure actually changed without me noticing it in the docs. I've only noticed when I saw it in some new projects and then looked for it very carefully. This is not the case for, let's say, Rust or Scala --- project hierarchy is a valid part of their respective manuals. @Araq Speaking about documentation... As you've probably noticed by know, I love metaprogramming. Would it be difficult to enamble doc tool to handle expanded macros? I love generating docs in Rust's macros so I thought it would be really nice when you have repetitive routines as I could use a macro and the user still have nice docs for each routine independently. @jzakiya Well... I'd say you're not the first one to make Araq get mad despite doing the right thing (see the blog post mentioning slice views). Just get used to it and do your thing.
