4 ms·

Generics are not "all the things". Last i checked there was still no object inheritance (in a subtype sense for interface implementations), no operator overload

by duaneb 11y ago

Generics are not "all the things". Last i checked there was still no object inheritance (in a subtype sense for interface implementations), no operator overloading, no bytecode/vm/jit, no inline asm, no macros, no pluggable gc, no call/cc, no (idiomatic) exceptions, no currying, no weak typing or implicit conversions, no way of enforcing referential transparency, no STM, no laziness, no assertions, no contracts, no untagged unions, no algebraic data types, no covariant return types, no pattern matching, no method overloading, no simd, no decorations/annotations.... I am sure i missed a lot. EDIT: of course this is good; such a language would be beyond nightmarish. By which i mean c++ or scala.

ViktorasM 11y ago
but having all those things go would become another C++ with a different syntax. I like the direction Go is going of "there are no options to choose", like unconfigurable fmt, or the fact that there is no way to create "exotic" implementations. However, generics would be my number #1 on the list of "maybe let's add that". Would be nice to have less "interface {}" in reusable libraries. Exceptions would be probably second, but that would come with some sort of runtime cost. With them Go would start to drift towards "generic programming language".
- pcwalton 11y ago
  Exceptions don't have any runtime costs beyond those which Go is already paying by mandating unwinding. In fact, C++-style exceptions are strictly less expensive in the non-exceptional case than defer, because of defer's dynamic semantics. Go's semantics require a slower exceptional control flow scheme than almost any other language I'm aware of, including dynamic ones like JavaScript.
  - duaneb 11y ago
    IIRC the idea is that the conceptual overhead of exceptions is much larger than the runtime cost, hence the minimal syntax/runtime support beyond defer (which is easy to follow, if hard to implement efficiently). I am not so sure I would agree with this, but I don't use go enough to have a firm opinion myself.
    - pcwalton 11y ago
      Try/catch/finally is simpler than panic/recover/defer both conceptually and in implementation, due to the statically, lexically-scoped semantics.
      - enneff 11y ago
        As you probably already know, panic/recover/defer are not supposed to be used in the same way as try/catch/finally. They're different features for different purposes. If you want error handling in Go, use error values.
        pcwalton 11y ago
        Sure. Panic, recover, and defer are in the language, though, and are more complex than exceptions regardless of how they're intended to be used.
      - duaneb 11y ago
        If recover is used in a file you never read, is its complexity relevant?
        enneff 11y ago
        I think what's happening here is pcwalton is a language implementer, so when you talk about 'conceptual complexity' he thinks about how the feature is specified, whereas you or I think about how the users of the feature think about and use it. We're all talking past each other a bit, I think.
        duaneb 11y ago
        Well he answered me as if he understood me, so I am going to go ahead with that assumption. This thread is not at all difficult to follow. Anyone who uses rescue should be shot on sight--it takes a masochist to introduce panic as a stack unwind mechanism intended to be caught. The process should stop. I have never seen rescue used in the wild, so it seems as if the only thing this has in common with exceptions is stack unwinding. It is apples and oranges and the performance difference is meaningless unless you try to use them as the same. To be fair, pcwalton was not advocating this. He was pointing out that defer is already more costly runtime wise than exceptions, correcting another person.
- duaneb 11y ago
  This was basically the point I was trying to make. :)
- ktRolster 11y ago
  I wouldn't mind seeing a powerful contracts implementation in C++. (Or any language, really).
- coldtea 11y ago
  >but having all those things go would become another C++ with a different syntax. Haskell and CL have "all those things" and they are not "C++ with a different syntax". I don't know why people repeat these cliches... It's not like a language can't have many features and be designed well at the same time. It just takes preparation and effort instead of ad-hoc additions (like with C++).
  - duaneb 11y ago
    I'd argue either are just as bad as C++ if you actually use all those features, just like NOT using all those features turns your C++ readable. I'd also argue that Haskell does NOT support all the features directly but implements them through the language, which is a Good Thing. I consider CL a mess, so I probably shouldn't comment on it.
  - geodel 11y ago
    But then there need not be raging debate about Go/Generics. As pragmatic developers can move to Haskell etc if Go has no value add to them.
    - coldtea 11y ago
      That reminds me of the "If those books say something worthwhile, it will be in the Kuran, too, so it's ok to burn them. If they don't, they it's ok to burn them anyway" argument -- something a sultan is alleged to have said as the justification for burning the library of Alexandria. The thing is, it's not just the feature set, different languages have lots of different things going (or not going) for them too. One might like Go's syntax over Haskell's. Another might not like Haskell's purity. A third might not like Haskell's heavyweight platform installation and tooling. Another might be forced to use Go because of his work but still hate the lack of Generics. Yet another might prefer Go over Haskell just for the fact that you can find Go jobs, where Haskell jobs are too few and far between.
idobai 11y ago
> EDIT: of course this is good; such a language would be beyond nightmarish. By which i mean c++ or scala. Then go and compare the same code in go and Scala and see which is more "nightmarish". You see Scala as a complex language because you need to learn something before you use it while go is almost the opposite - you may get it in an afternoon and create repetitive, boilerplatish and unmaintanable mess.
- mlvljr 11y ago
  This Scala maintainer disagrees, as we know: https://www.youtube.com/watch?v=TS1lpKBMkgg https://www.youtube.com/watch?v=TS1lpKBMkgg
- duaneb 11y ago
  > You see Scala as a complex language because you need to learn something before you use it No, I see Scala as a complex language because—much like C++—each library uses its own curious dialect. There is no community consensus on the balance between the object-oriented and functional. It's a mess, albeit a mess I'd prefer over most other languages. But dealing with implicits, language changes between versions, and "default" trait implementations (e.g. `val foo = Set()` is a simple example) makes me consider the language nightmarish.
  - idobai 11y ago
    > each library uses its own curious dialect That's the point of high-level languages - to create effective DSLs... > There is no community consensus on the balance between the object-oriented and functional. We mix it - there is neither functional nor oop camp at Scala, only objecto-functional - which makes our life easier with decent type and modular systems. >But dealing with implicits What's so hard about implicits? One of the easiest feature in PLT. It means to do things implicitly - implicitly waiting for a parameter, implicitly converting something or implicitly extending types with methods. > language changes between versions That's the point of versions - to release changes. And no, there aren't as many breaking changes to destroy your workflow if you didn't use any type-level magic. > and "default" trait implementations (e.g. `val foo = Set()` is a simple example) val foo = Set() means foo is an empty Set - why does it bother you? It helps to abstract your code and removes unwanted specializations. If you want to use concrete types nothing gonna stop you from that.

by duaneb 11y ago

ViktorasM 11y ago

but having all those things go would become another C++ with a different syntax. I like the direction Go is going of "there are no options to choose", like unconfigurable fmt, or the fact that there is no way to create "exotic" implementations. However, generics would be my number #1 on the list of "maybe let's add that". Would be nice to have less "interface {}" in reusable libraries. Exceptions would be probably second, but that would come with some sort of runtime cost. With them Go would start to drift towards "generic programming language".

pcwalton 11y ago
Exceptions don't have any runtime costs beyond those which Go is already paying by mandating unwinding. In fact, C++-style exceptions are strictly less expensive in the non-exceptional case than defer, because of defer's dynamic semantics. Go's semantics require a slower exceptional control flow scheme than almost any other language I'm aware of, including dynamic ones like JavaScript.
- duaneb 11y ago
  IIRC the idea is that the conceptual overhead of exceptions is much larger than the runtime cost, hence the minimal syntax/runtime support beyond defer (which is easy to follow, if hard to implement efficiently). I am not so sure I would agree with this, but I don't use go enough to have a firm opinion myself.
  - pcwalton 11y ago
    Try/catch/finally is simpler than panic/recover/defer both conceptually and in implementation, due to the statically, lexically-scoped semantics.
    - enneff 11y ago
      As you probably already know, panic/recover/defer are not supposed to be used in the same way as try/catch/finally. They're different features for different purposes. If you want error handling in Go, use error values.
      - pcwalton 11y ago
        Sure. Panic, recover, and defer are in the language, though, and are more complex than exceptions regardless of how they're intended to be used.
    - duaneb 11y ago
      If recover is used in a file you never read, is its complexity relevant?
      - enneff 11y ago
        I think what's happening here is pcwalton is a language implementer, so when you talk about 'conceptual complexity' he thinks about how the feature is specified, whereas you or I think about how the users of the feature think about and use it. We're all talking past each other a bit, I think.
        duaneb 11y ago
        Well he answered me as if he understood me, so I am going to go ahead with that assumption. This thread is not at all difficult to follow. Anyone who uses rescue should be shot on sight--it takes a masochist to introduce panic as a stack unwind mechanism intended to be caught. The process should stop. I have never seen rescue used in the wild, so it seems as if the only thing this has in common with exceptions is stack unwinding. It is apples and oranges and the performance difference is meaningless unless you try to use them as the same. To be fair, pcwalton was not advocating this. He was pointing out that defer is already more costly runtime wise than exceptions, correcting another person.
duaneb 11y ago
This was basically the point I was trying to make. :)
ktRolster 11y ago
I wouldn't mind seeing a powerful contracts implementation in C++. (Or any language, really).
coldtea 11y ago
>but having all those things go would become another C++ with a different syntax. Haskell and CL have "all those things" and they are not "C++ with a different syntax". I don't know why people repeat these cliches... It's not like a language can't have many features and be designed well at the same time. It just takes preparation and effort instead of ad-hoc additions (like with C++).
- duaneb 11y ago
  I'd argue either are just as bad as C++ if you actually use all those features, just like NOT using all those features turns your C++ readable. I'd also argue that Haskell does NOT support all the features directly but implements them through the language, which is a Good Thing. I consider CL a mess, so I probably shouldn't comment on it.
- geodel 11y ago
  But then there need not be raging debate about Go/Generics. As pragmatic developers can move to Haskell etc if Go has no value add to them.
  - coldtea 11y ago
    That reminds me of the "If those books say something worthwhile, it will be in the Kuran, too, so it's ok to burn them. If they don't, they it's ok to burn them anyway" argument -- something a sultan is alleged to have said as the justification for burning the library of Alexandria. The thing is, it's not just the feature set, different languages have lots of different things going (or not going) for them too. One might like Go's syntax over Haskell's. Another might not like Haskell's purity. A third might not like Haskell's heavyweight platform installation and tooling. Another might be forced to use Go because of his work but still hate the lack of Generics. Yet another might prefer Go over Haskell just for the fact that you can find Go jobs, where Haskell jobs are too few and far between.

idobai 11y ago

> EDIT: of course this is good; such a language would be beyond nightmarish. By which i mean c++ or scala. Then go and compare the same code in go and Scala and see which is more "nightmarish". You see Scala as a complex language because you need to learn something before you use it while go is almost the opposite - you may get it in an afternoon and create repetitive, boilerplatish and unmaintanable mess.

mlvljr 11y ago
This Scala maintainer disagrees, as we know: https://www.youtube.com/watch?v=TS1lpKBMkgg https://www.youtube.com/watch?v=TS1lpKBMkgg
duaneb 11y ago
> You see Scala as a complex language because you need to learn something before you use it No, I see Scala as a complex language because—much like C++—each library uses its own curious dialect. There is no community consensus on the balance between the object-oriented and functional. It's a mess, albeit a mess I'd prefer over most other languages. But dealing with implicits, language changes between versions, and "default" trait implementations (e.g. `val foo = Set()` is a simple example) makes me consider the language nightmarish.
- idobai 11y ago
  > each library uses its own curious dialect That's the point of high-level languages - to create effective DSLs... > There is no community consensus on the balance between the object-oriented and functional. We mix it - there is neither functional nor oop camp at Scala, only objecto-functional - which makes our life easier with decent type and modular systems. >But dealing with implicits What's so hard about implicits? One of the easiest feature in PLT. It means to do things implicitly - implicitly waiting for a parameter, implicitly converting something or implicitly extending types with methods. > language changes between versions That's the point of versions - to release changes. And no, there aren't as many breaking changes to destroy your workflow if you didn't use any type-level magic. > and "default" trait implementations (e.g. `val foo = Set()` is a simple example) val foo = Set() means foo is an empty Set - why does it bother you? It helps to abstract your code and removes unwanted specializations. If you want to use concrete types nothing gonna stop you from that.