5 ms·

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 m

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.
- Vendan 10y ago
  How would you possibly do that? Part of Go is that there are no warnings, only errors. If you want it to just error a build if you've "deprecated" a thing, just delete the thing...
- danaliv 10y ago
  If I've learned anything in nearly 20 years of professional software development, it's that nothing is temporary, least of all things that are explicitly labeled as such.
elcct 10y ago
> except in that it will make go less 'simple' to read and understand. Which probably will defeat the point of using Go... its main selling point for me it is its simplicity. If they keep making it more difficult to work with, I might just end up going back to C++
- tree_of_item 10y ago
  Really? Go would need to add a lot more than aliases to reach C++ levels of complexity. I honestly think you're just being dramatic here, there's no way Go catches up to C++ in that respect any time soon.
  - majewsky 10y ago
    My favorite metric for language complexity is: How many distinct Turing-complete languages exist in this language? On this metric, Go scores 1 (just Go itself), and C++ scores 3 (C preprocessor, C++ itself, C++ templates).
    - bbatha 10y ago
      Go scores infinity actually. Go generate is a part of the language, which means that you can bring your own Turing-complete language to the party. Reflection especially with plugins, are essentially another language that is even more difficult to track down than macros (or templates). Though you can at least write Reflection using go.
      - Vendan 10y ago
        but go generate isn't a part of the standard build process. If we go to that level, I can just say "most things that use C++ have a Makefile, so that's infinite too".
    - gue5t 10y ago
      C preprocessor alone is not turing-complete; you have to repeatedly apply the preprocessor (until you get a fixpoint or decide the program won't halt) to perform arbitrary computation.
amelius 10y ago
Perhaps then Go should include tooling to trace back the original definition (?)
- KirinDave 10y ago
  It'd be a good idea, but it's REALLY important to remember that the path to Java (where your language is so full of makework tasks that it is only truly productive with a mountain of tooling) is a very short path with conversations like this. Most language designers generally say that if your language requires a sidecar development environment to be reasonably productive, you've failed at your design tasks. Tools should be time saving helpers, not requirements to understand and navigate even basic code structures.

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.
Vendan 10y ago
How would you possibly do that? Part of Go is that there are no warnings, only errors. If you want it to just error a build if you've "deprecated" a thing, just delete the thing...
danaliv 10y ago
If I've learned anything in nearly 20 years of professional software development, it's that nothing is temporary, least of all things that are explicitly labeled as such.

elcct 10y ago

> except in that it will make go less 'simple' to read and understand. Which probably will defeat the point of using Go... its main selling point for me it is its simplicity. If they keep making it more difficult to work with, I might just end up going back to C++

tree_of_item 10y ago
Really? Go would need to add a lot more than aliases to reach C++ levels of complexity. I honestly think you're just being dramatic here, there's no way Go catches up to C++ in that respect any time soon.
- majewsky 10y ago
  My favorite metric for language complexity is: How many distinct Turing-complete languages exist in this language? On this metric, Go scores 1 (just Go itself), and C++ scores 3 (C preprocessor, C++ itself, C++ templates).
  - bbatha 10y ago
    Go scores infinity actually. Go generate is a part of the language, which means that you can bring your own Turing-complete language to the party. Reflection especially with plugins, are essentially another language that is even more difficult to track down than macros (or templates). Though you can at least write Reflection using go.
    - Vendan 10y ago
      but go generate isn't a part of the standard build process. If we go to that level, I can just say "most things that use C++ have a Makefile, so that's infinite too".
  - gue5t 10y ago
    C preprocessor alone is not turing-complete; you have to repeatedly apply the preprocessor (until you get a fixpoint or decide the program won't halt) to perform arbitrary computation.

amelius 10y ago

Perhaps then Go should include tooling to trace back the original definition (?)

KirinDave 10y ago
It'd be a good idea, but it's REALLY important to remember that the path to Java (where your language is so full of makework tasks that it is only truly productive with a mountain of tooling) is a very short path with conversations like this. Most language designers generally say that if your language requires a sidecar development environment to be reasonably productive, you've failed at your design tasks. Tools should be time saving helpers, not requirements to understand and navigate even basic code structures.