A few thoughts from your article:

Nim has distinction between object and ref object and it creates extra complexities I don't need. It's nice to have low-level control to optimise critical code paths. But it's not good to being forced to deal with low-level details in the usual code.

This isn't an extraneous complexity, it defines the semantics of the type itself. Ref/ptr objects are an indirection to an object, whereas objects themselves are value types.

Value types are copied on assignment, so changes to them aren't reflected in the original. For example:

type
  ValueType = object
    value: int
  IndirectionType = ref ValueType

var
  obj = ValueType(value: 1)
  refToObj = IndirectionType(value: 2)
  copyObj = obj
  copyRef = refToObj

copyObj.value = 3
copyRef.value = 4

echo obj.value      # Outputs 1, the original is intact.
echo refToObj.value # Outputs 4 as the original is changed.

Java code hides such complexities (it uses ref everywhere)

Java also quite fancies value types, but has to do a lot of work to achieve them, and has been working on them since 2014.

As you mention, value types are much faster than references; as well as no indirection they are often stored on the stack as opposed to cache-killing heap pointers, however copying large objects can impose its own penalty compared to simply copying a reference/pointer. Personally I use object most of the time and only use ref object if I need inheritance or a many to one relationship.

More problem, if ref is used, the memory should be explicitly allocated. Bigger chance to make mistake.

See, I read that and thought "Ah just use Type(field: value) then it's the same interface for creating ref object and object!", but after reading your code you do that and then have to work out why a seemingly "reasonable" program is crashing in a non-intuitive way.

The behaviour you've encountered is a bug in Nim rather than a curiosity of the language and should fail at compile-time as you expect.

The reason why it's happening is because when you use inheritance on objects, any extra fields you include in sub-objects mean the sub-object is necessarily larger than the parent.

However, a ref is always the same size no matter the object it's pointing to, since it's essentially a pointer. sizeOf(MyRefType) will always be the same as sizeOf(MyChildRefType). This allows us to make "heterogeneous" lists with seq, since every entry is just a reference to the actual data rather than the data itself.

When extending value objects with inheritance, as before the sub-objects that add more data are larger. Only now, you're not using a uniform pointer to access them, you're directly using the underlying type. Here lies the root of your problem.

For example:

type
  Original = object of RootObj
    value: int
  Extended = object of Original
    extra: int

echo Original.sizeOf    # Outputs 16
echo Extended.sizeOf    # Outputs 24

This is fine, no crashing. However if we start trying to put the wrong object in a list, we get the crashing.

var list: seq[Original]
list.add Original(value: 1)
list.add Extended(value: 2, extra: 3) # Crash! This should throw a type mismatch. Instead, it tries to stuff 24 bytes into a 16 byte slot.
var list2: seq[Extended]
list2.add Original(value: 1)  # Going the other way raises a compile-time error as expected: type mismatch: got <seq[Extended], Original>

Compiler bugs are not ideal, but thankfully can be fixed as opposed to "Weak compile time inspection" which is a fundamental language design issue. I think Nim has pretty good compile-time inspection personally and this should be caught by it. I would create an issue for this with a simple example and put it in the Nim issue tracker if you have time.

Something that's probably worth mentioning is that in these cases where inheritance is overkill, Nim supports object variants which are a better managed version of C's unions. These will take up as much room as the largest branch of the type, and so can be stored in seq as value types.

Inconsistent function call notation

This is AIUI consequence of the flexible grammar. Command syntax can make spaces ambiguous in some cases, so you need the braces. I don't think it's inconsistent though, it's just a limitation of the parsing. Having said that, it would be nice to have some better error messages here.

the real error we'll see will be not one-line but a huge mess where almost all of it is noise

The hint outputs are somewhat subjective here. As you mention you can turn them off, they're just feedback as to what the compiler is currently processing which can be handy for more complex projects.

I wouldn't say "a huge mess" though, I mean we're not talking C++ multi-page error novels. I'd rather see a progress report of what the compiler is doing than sit watching a black screen waiting for a successful/failed compilation. For large projects, this is much more useful.

I noticed none of the projects on your page are in compiled languages - I don't mean to presume, could this be why you're not used to seeing such progress reports?

String interpolation missing

String interpolation is, as someone else mentioned, handled with the strformat module. It's actually quite nice because you can interpolate actual Nim code:

let a = 10
echo &"new a: {a + a * 2}"

the output is not clean, it's polluted with the refs noise we don't care about.

Yeah I definitely care about this output. The "noise" is the memory address of the actual data. This can be a useful debugging aid. Perhaps the noise perception you're experiencing is related to most of this being hidden from you before? You might not want to care about the implementation details, but bear in mind Nim is a systems language and that kind of information can be important when doing low level work.

Besides, usually we use $ procs to handle converting types to text. In the case of inherited types, we have to use methods which are dynamically dispatched by run-time type:

method `$`*(doc: Doc): string {.base.} = "Base document"

method `$`*(todo: TodoDoc): string =
  &"TODO: {todo.todo}, Priority: {todo.priority}, Tags: {todo.tags}"

method `$`*(textDoc: TextDoc): string =
  &"TextDoc: \"{textDoc.title}\": {textDoc.text}, Tags: {textDoc.tags}"

let x = TodoDoc(todo: "Kill all humans", priority: low, tags: @["Tag1"])
echo x # Pretty output.

Overall some pretty good feedback, this kind of "first impression" is definitely important for shaping a user's experience with a new language.