Hacker News Reader

Comment by tree_of_item | Hacker News Reader

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?

View on HN

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

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.

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.

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?

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.

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.

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.

> 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.

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.

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.

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.

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...

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.

> 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++

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.

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).

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.

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".

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.

I get the feeling that C++ is becoming simpler to use with each edition. Perhaps some day if Go will be adding features such as this, they will meet half way through :)

That may be true of "the currently recommended subset of C++", but I doubt that many big legacy C++ codebases are written in that subset.

I don't think the language as a whole is getting any simpler.

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

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.

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.

Reply on news.ycombinator.com