6 ms·

To me, "takes up a significant part of the language spec, compiler, and VM" isn't a meaningful reason to exclude something from a language, unless it's a hobby

To me, "takes up a significant part of the language spec, compiler, and VM" isn't a meaningful reason to exclude something from a language, unless it's a hobby project. The job of languages, imo, is to provide tools/features/syntax for expressing problems, whether their implementation is complex or not. Ruby is an incredible language to use, but its implementation is notoriously hairy. That internal complexity is not something that matters to me in the slightest. I understand the Go team's reluctance to get the user-facing interface wrong, and end up with something like type-erasure in Java; that's slightly connected with implementation complexity, but saying "it's complex to implement and specify" doesn't seem enough to me. [edit: made it clearer that this is my thought on the job of languages and not some universal truth]

assbuttbuttass 5y ago
I actually have a different view. One of the things I love about go is it's a simple language, and I can hold the whole language spec in my head while I'm programming. A generics implementation can't sacrifice the simplicity of the language, or make it any harder to read go code.
- leshow 5y ago
  I can hold the entire spec to brainfuck in my head, but it doesn't make it any easier to write.
- nauticacom 5y ago
  I can hold the whole language spec in my head while I'm programming People love to say this about Go, but it's not something that, like, actually matters (and I doubt it's literally true). A language can be reasonably understandable such that you can effectively and productively program in it without being aggressively simple. Again, to use the case of Ruby, I might not remember every single syntactical construct or handling of every edge case, but the language is reasonably understandable such that I can write programs without constantly asking "what was the syntax for that?" or "how do I express this?" As a counter-example, I think the complexity of C++ is not just limited to its implementation, and leaks out to its interface. ...sacrifice the simplicity of the language, or make it any harder to read go code These are two separate concerns which, while somewhat related, are not directly correlated. A simple language can make it more obvious which syntactical constructs are being used and what literal operations are being performed, but there are many more dimensions to reading code than just those.
- cultofmetatron 5y ago
  lisp and smalltalk both manage this while allowing sophisticated abstractions.
remus 5y ago
> It should be noted that "takes up a significant part of the language spec, compiler, and VM" isn't a meaningful reason to exclude something from a language, unless it's a hobby project. If we assume complexity ~= "takes up a significant part of the language spec, compiler, and VM" then I think it's an excellent reason not to include something! Somebody has to maintain this stuff and making it complicated makes that hard, which in turn means less time to spend on things like tooling, performance improvements and documentation which then makes our lives as users of the language harder. Of course there is a trade-off here but I think, in general, the go team manage to strike a nice balance.
- nauticacom 5y ago
  Right, but the entire point of my comment was that "takes up a significant part of the language spec, compiler, and VM" is not a good approximation of complexity. It can be related, but it is not necessarily true that something with a complex implementation has a complex interface.
  - remus 5y ago
    I think we are talking past each other a bit, as I completely agree with > it is not necessarily true that something with a complex implementation has a complex interface. In turn, my point is that as a language implementer you only have so much time available to work on the language and surrounding ecosystem. If your time is spent dealing with a complex spec, compiler and VM then you have less time to spend on the rest of the ecosystem. I think go has shown that spending tim on the surrounding ecosystem can be very valuable (e.g. go fmt, go vet and more recently go fuzz).
    - nauticacom 5y ago
      Ah, I understand now. That's a fair point! I agree that the excellent Go tooling is one of its strengths.

assbuttbuttass 5y ago

I actually have a different view. One of the things I love about go is it's a simple language, and I can hold the whole language spec in my head while I'm programming. A generics implementation can't sacrifice the simplicity of the language, or make it any harder to read go code.

leshow 5y ago
I can hold the entire spec to brainfuck in my head, but it doesn't make it any easier to write.
nauticacom 5y ago
I can hold the whole language spec in my head while I'm programming People love to say this about Go, but it's not something that, like, actually matters (and I doubt it's literally true). A language can be reasonably understandable such that you can effectively and productively program in it without being aggressively simple. Again, to use the case of Ruby, I might not remember every single syntactical construct or handling of every edge case, but the language is reasonably understandable such that I can write programs without constantly asking "what was the syntax for that?" or "how do I express this?" As a counter-example, I think the complexity of C++ is not just limited to its implementation, and leaks out to its interface. ...sacrifice the simplicity of the language, or make it any harder to read go code These are two separate concerns which, while somewhat related, are not directly correlated. A simple language can make it more obvious which syntactical constructs are being used and what literal operations are being performed, but there are many more dimensions to reading code than just those.
cultofmetatron 5y ago
lisp and smalltalk both manage this while allowing sophisticated abstractions.

remus 5y ago

> It should be noted that "takes up a significant part of the language spec, compiler, and VM" isn't a meaningful reason to exclude something from a language, unless it's a hobby project. If we assume complexity ~= "takes up a significant part of the language spec, compiler, and VM" then I think it's an excellent reason not to include something! Somebody has to maintain this stuff and making it complicated makes that hard, which in turn means less time to spend on things like tooling, performance improvements and documentation which then makes our lives as users of the language harder. Of course there is a trade-off here but I think, in general, the go team manage to strike a nice balance.

nauticacom 5y ago
Right, but the entire point of my comment was that "takes up a significant part of the language spec, compiler, and VM" is not a good approximation of complexity. It can be related, but it is not necessarily true that something with a complex implementation has a complex interface.
- remus 5y ago
  I think we are talking past each other a bit, as I completely agree with > it is not necessarily true that something with a complex implementation has a complex interface. In turn, my point is that as a language implementer you only have so much time available to work on the language and surrounding ecosystem. If your time is spent dealing with a complex spec, compiler and VM then you have less time to spend on the rest of the ecosystem. I think go has shown that spending tim on the surrounding ecosystem can be very valuable (e.g. go fmt, go vet and more recently go fuzz).
  - nauticacom 5y ago
    Ah, I understand now. That's a fair point! I agree that the excellent Go tooling is one of its strengths.