Hacker News Reader

Comment by pietroppeter | Hacker News Reader

It's interesting to hear the constraints the language developer wanted from the beginning (20k lines, macro system drives most of the language development) and the various compromises they had to make along the way.

> Furthermore, we don't really know yet how to leverage a macro system in order to give us extensibility on the type system level, so Nim's core needed generics and constraints for generics.

I'm curious to dig into Nim and it's type system. I'm not familiar with Pascal style typing, I wonder how it compares with Rusts type system?

I haven't looked into Nim in as much detail as Rust (though I did make some contributions to the compiler/language a number of years ago), but one aspect that has always seemed notable to me is that it seems to defer type checking of generic code until it is instantiated (this is what happens in C++), so these functions will all typecheck until you actually try to use them:

  proc foo[T](): float32 =
    result = "foo" + 4
  
  proc bar[T](n: T, m: T): T =
    result = n(m)(n)

In Rust, such functions would require some sort of explicit constraints on `T`, so it's more-or-less guaranteed to be instantiable (ignoring the issue of polymorphic recursion) and you don't get some error pointing to code internal to the function when the user applies types that don't work.

>it seems to defer type checking of generic code until it is instantiated (this is what happens in C++) ... and you don't get some error pointing to code internal to the function when the user applies types that don't work.

Worth noting that C++ is going the opposite way with concepts. The compiler still won't enforce that `template<typename T> void foo(T t) { t++; }` needs a `requires Incrementable T` (like Rust would require with trait bounds). But if `foo` does use the concept `template<Incrementable T>`, then a call like `foo(S{})` will raise an error at the callsite, not at the `t++` line.

Interesting. From what I remember of Go's generics proposal, they seemed to be trying to do something similar, which seemed a bit hacky to me (as you say, it addresses the error reporting issue but it's difficult to see how the constraints would be used to actually check the generic code, so functions can presumably still lie about being "for all types").

EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them.

Looking into it now, Nim apparently has experimental support for the same feature: https://nim-lang.org/docs/manual_experimental.html#concepts

> EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them.

Just wanted to add that my initial memory was apparently of the earlier proposal for generics in Go, as reflected here: https://dev.to/deanveloper/go-2-draft-generics-3333 (in this earlier proposal, contracts simply specify code that is expected to compile, in such a way that it would be difficult/impossible to derive types for symbols introduced by the contract).

I guess the golang people figured out why that was not an optimal system and changed it ... wonder if the same will be true of Nim.

Reply on news.ycombinator.com