[Araq]

> And there's no strong sense of design and elegance. It very much comes off as "here's a bunch of ideas thrown together with the restriction that they all must somehow compile to C".

But C is Turing-complete, so there is no restriction here. It's also not a "bunch of ideas thrown together" anymore than Haskell or Scala or Rust is. Nim focuses on 3 things:

* Metaprogramming via a hygienic AST-based macro system.

* An effect system to make the type system simpler to use. (The compiler infers an awful lot of useful information for you, the docgen shows the results for everybody to look at.)

* GC'ed thread local heaps where each GC can comply with soft-realtime requirements. Hard realtime is being worked on.

Any modern statically typed language also needs to have generics, closures, inheritance, exceptions or workarounds of the same complexity, so yeah Nim also has these making Nim instantly a big language. That doesn't mean it's a "bunch of ideas thrown together".

> It doesn't have memory safety as a core goal.

It does and it is reasonably safe (yeah yeah yeah we don't check for 'nil' properly yet, give me a break) with quite some improvements in the pipeline.

[MichaelGG]

My apologies then. I didn't mean to come off rude; elegance is subjective I suppose.

I was under the impression that the only safe pointers (references) must be GC'd. So if you want/must to avoid that (say for perf), you're stuck using regular unsafe pointers. Is that inaccurate?

The manual even says that just calling printf is actually unsafe as the cstring could be GC'd (but it probably won't). Maybe Nim should have an unsafe directive to make sure any unsafe user code is clearly marked?

I also coulda sworn there was some part of the manual or site that was discussing a feature with a limitation due to the difficulty of expressing it in C. Maybe I imagined it. Sorry.

[Araq]

> The manual even says that just calling printf is actually unsafe as the cstring could be GC'd (but it probably won't).

The manual tries very hard to mention corner cases since it's evolving into a proper spec. Calling printf is safe, it's C functions that take ownership of the char* pointer that are inherently unsafe.

> Maybe Nim should have an unsafe directive to make sure any unsafe user code is clearly marked?

That's a common misunderstanding, Nim doesn't need this. Instead of an ``unsafe`` keyword, Nim has ``addr`` and ``cast`` as keywords, these are the unsafe building blocks of the language. There are other corner cases that introduce unsafety, but they are all known and can be solved in time.

> I also coulda sworn there was some part of the manual or site that was discussing a feature with a limitation due to the difficulty of expressing it in C.

Well these things certainly are everywhere, but the issue here is not the difficulty of expressing it in C, but a desire to have very good C interop. Rust actually has all the same design constraints even though Rust builds on top of LLVM because the constraints come from the "systems programming" problem domain: Control over memory layouts, the stressed difference between heap and stack, etc. LLVM's IR is very close to C, so what is difficult to map to C is difficult to map to LLVM too.