5 ms·

I don't really get it. What's the big deal? I see a lot of dramatic language about the "strenuous objections of many external contributors", but what exactly is

I don't really get it. What's the big deal? I see a lot of dramatic language about the "strenuous objections of many external contributors", but what exactly is so bad about this proposal? There was even a comparison to `goto`...? What am I missing?

aristidb 10y ago
Type aliases have been useful in many languages for many reasons. I also don't understand why the author is so upset.
- KirinDave 10y ago
  I mean, I think Go generally holds that it cannot be nearly as complex as other languages with type aliases. It's a curious restriction for a language with pointers to take, I know... But I suppose that the way go implemented vendoring introduces some strange outcomes here.
  - mixedCase 10y ago
    Go pointers have no pointer arithmetic and are clearer than guessing what's being passed by value/reference and something like C#'s out/ref. With or without pointers, as a programmer you'll have to understand passing by value and passing by reference. Go just makes it explicit in a language construct.
    - KirinDave 10y ago
      I am confused why C# came up or why you'd call it's in/out parameters "guessing." Your second paragraph seems to invalidate your first?
      - mixedCase 10y ago
        What I said is that the (ugly) C# solution is one alternative to "guessing" (or rather, knowing the implicit details of the language). Go pointers make references and values quite visible to the programmer, because in the real world it's not actually convenient to hide those details.
        KirinDave 10y ago
        I do not think in/out parameters are ugly. I find them to be a lot more elegant than the cudgel that is pointers. Go's pointers are certainly BETTER than C++ pointers, but I don't think that immediately makes it better. BOTH languages have value and reference semantics, and BOTH languages use syntax to dogwhistle that to programmers.
shadowmint 10y ago
The main issue seems to be if A imports and re-exports symbol B from C, reading code that uses A.B you have no idea where to look to find out more about B; it may even be multiple hops of indirection to get to the original C.B, and that layer of cruft will never be removed, realistically. ...that said, I don't really see the problem either, except in that it will make go less 'simple' to read and understand.
- evincarofautumn 10y ago
  > that layer of cruft will never be removed, realistically. It will if you mark the alias as deprecated. Unfortunately, there seems to be no standard way to do that in Go.
  - zaphar 10y ago
    I have worked on codebases where the deprecated annotation lasted years in the wild. Marking something as deprecated does almost nothing to make it possible to remove code. It doesn't even do all that much to prevent new uses most of the time. Preventing it in the first place is a much more effective method.
    - evincarofautumn 10y ago
      Sure, my comment is only meaningful if someone bothers to fix the warnings. Before Vendan’s comment I didn’t know that Go doesn’t have warnings, so it’s moot anyway. I was thinking in terms of upgrading a library to a newer version. It’s nice to at least get warnings for everything you’ll need to update, even if it doesn’t make it any easier to actually do so.
      - zaphar 10y ago
        Yeah. Part of the problem that Go attempts to fix is exactly this. They just make it fail to compile if you don't update your code. In a large monolithic repository this is easier to police and manage. In the rest of the world not so much.
oolongCat 10y ago
I think the big deal here is, a political one, more than a technical one. While google is the reason we have go and google basically pays for go, people are afraid that go might lose its simplicity in order to cater to google's wishes.

aristidb 10y ago

Type aliases have been useful in many languages for many reasons. I also don't understand why the author is so upset.

KirinDave 10y ago
I mean, I think Go generally holds that it cannot be nearly as complex as other languages with type aliases. It's a curious restriction for a language with pointers to take, I know... But I suppose that the way go implemented vendoring introduces some strange outcomes here.
- mixedCase 10y ago
  Go pointers have no pointer arithmetic and are clearer than guessing what's being passed by value/reference and something like C#'s out/ref. With or without pointers, as a programmer you'll have to understand passing by value and passing by reference. Go just makes it explicit in a language construct.
  - KirinDave 10y ago
    I am confused why C# came up or why you'd call it's in/out parameters "guessing." Your second paragraph seems to invalidate your first?
    - mixedCase 10y ago
      What I said is that the (ugly) C# solution is one alternative to "guessing" (or rather, knowing the implicit details of the language). Go pointers make references and values quite visible to the programmer, because in the real world it's not actually convenient to hide those details.
      - KirinDave 10y ago
        I do not think in/out parameters are ugly. I find them to be a lot more elegant than the cudgel that is pointers. Go's pointers are certainly BETTER than C++ pointers, but I don't think that immediately makes it better. BOTH languages have value and reference semantics, and BOTH languages use syntax to dogwhistle that to programmers.

shadowmint 10y ago

The main issue seems to be if A imports and re-exports symbol B from C, reading code that uses A.B you have no idea where to look to find out more about B; it may even be multiple hops of indirection to get to the original C.B, and that layer of cruft will never be removed, realistically. ...that said, I don't really see the problem either, except in that it will make go less 'simple' to read and understand.

evincarofautumn 10y ago
> that layer of cruft will never be removed, realistically. It will if you mark the alias as deprecated. Unfortunately, there seems to be no standard way to do that in Go.
- zaphar 10y ago
  I have worked on codebases where the deprecated annotation lasted years in the wild. Marking something as deprecated does almost nothing to make it possible to remove code. It doesn't even do all that much to prevent new uses most of the time. Preventing it in the first place is a much more effective method.
  - evincarofautumn 10y ago
    Sure, my comment is only meaningful if someone bothers to fix the warnings. Before Vendan’s comment I didn’t know that Go doesn’t have warnings, so it’s moot anyway. I was thinking in terms of upgrading a library to a newer version. It’s nice to at least get warnings for everything you’ll need to update, even if it doesn’t make it any easier to actually do so.
    - zaphar 10y ago
      Yeah. Part of the problem that Go attempts to fix is exactly this. They just make it fail to compile if you don't update your code. In a large monolithic repository this is easier to police and manage. In the rest of the world not so much.

oolongCat 10y ago

I think the big deal here is, a political one, more than a technical one. While google is the reason we have go and google basically pays for go, people are afraid that go might lose its simplicity in order to cater to google's wishes.