You made a lot of points. But to be fair, speaking as a normal developer, some
of your points do not make sense.
* `&` do exactly what it supposed to do. It is not `&` 8100x time slower than
`add`, it is the algorithm 8100x slower. A year 1 student know to use a string
builder for fast repeating string concatenation. If someone want to benchmark
how the gc handle strings, it is fine. But if someone want to blame compiler
not optimizing away his poor algorithm. IMO, he should read introduction to
programming.
* `100M loops of s.add('x') uses 325MB of RAM` I didn't look into details, it
does look a bit high to me, I would expect ~200MB, but 325MB is not utterly
unacceptable.
* `Nim stdlib code is not compiled in production mode unless my code is also
in production mode` Actually, I didn't expect stdlib to be pre-compiled or
stdlib compiled in prod mode and my code compiled in dev mode... as far as I
know, many languages just treat stdlib the same as other libraries and your
code. Maybe you expect too much.
* I agree that the implementation of `initTable` should just simply adjust
the size to the next power of 2.
* Treating array as value is rather inconsistent with other languages. But
once wrapping a `ref object`, the usage is almost the same as usual. The core
developers prompts to use object variant or alike, but I am just get too used
to class and I does see it as a problem.
* I dream to have everything "best in class" for free too =]
* It is the **strong type** that do not allow passing `int64` to `int`. It is
a safety feature! You may expect the compiler to auto detect int are actually
int64 on 64-bit machine, but then the same code do not compile in 32-bit
machine... The mindset of strong type will be treat `int64` and `int` as two
different types and require programmer to convert it explicitly. `SomeInteger`
on the other is alias to `int | int8 | int16 | int32 | int64 | uint | uint8 |
uint16 | uint32 | uint64` which explicitly say `int` or `int64` or ...
* I am happy to read and write `10i64`, `8u32`
