Live data from Hacker News

Four days of Go

evanmiller.org

181–187 of 187 posts

Re: Four days of Go

#181
post #137

Earlier quoted context omitted.

Various core Go team members seem to have a different philosophy regarding generics. They actually don't have a united front on this. It seems Russ Cox and Rob Pike are either anti-generics or in the you-dont-really-need-them camp, but Ian Thompson and Brad Fitzpatrick have seemed very open to the idea - what they can't, however, agree on, is exactly how to implement them so that they make sense in Go. That's it. If…

I think adding generics to a stable language is actually a hard thing to do. There's more than "that's it". Rust has had many major and minor changes regarding generics solely, which has broken backward compatibility each time. The Go team may find a brilliant way to accomplish this, but I think the only viable way left is, as you said, using code generation. Either C++-way, which is a special syntax but still a form…

Maybe the "elegance" is a factor as well, but I haven't seen it mentioned. All I've seen mentioned is: a) can't change syntax b) can't take huge performance hits at run time or at compile time c) can't break backwards compatibility d) talk is cheap - provide a working implementation

So far, nobody has been able to show all 4 of these requirements, so nothing has been done.

But when/if someone does, I expect it to be taken very seriously.

Re: Four days of Go

#182
post #104

Earlier quoted context omitted.

I guess that makes Go the inverse of Perl. I assume if a Perl programmer shakes hands with a Go programmer, they cancel each other out.

No, the Go programmer will win. Strong(ly) type(d), you see :) #SorryCouldntResist Note: Said without any bias towards either Go or Perl. Also, I'm not a language lawyer, and this was a joke, so I'm not replying to any comments about Go not being "purely" or "strictly" strongly typed or whatever.

Also, speaking of Perl, check out this (old) interview with Larry Wall:

http://jugad2.blogspot.in/2015/04/interview-linux-journal-wi...

Re: Four days of Go

#184
post #151

Earlier quoted context omitted.

It's not part of Go-the-language. It's part of the distribution of the most popular (ok, only) implementation of that language.

Not true. It is illegal for a package to import itself, directly or indirectly, or to directly import a package without referring to any of its exported identifiers. - https://golang.org/ref/spec

What?

I'm saying that the tooling that helps manage import paths in the way you want is not part of Go-the-language.

The language restriction against unused imports certainly is.

Re: Four days of Go

#185
post #20

I find that every issue I had with unused imports disappeared when I started using goimports: http://godoc.org/golang.org/x/tools/cmd/goimports

There are unused imports, solved easily with goimports, and then there are unused variables , which AFAIK are not solved by any tool. I dig what the author says regarding "explorability" hindered by all those errors popping up. It's also funny to see errors solved automagically by tools instead of manually by the developer; there used to be a time where IDEs where voluntarily avoided because they did too many magic t…

> I fear go may be headed back to IDE-land if it starts relying too much on tools (we have goimports today, the go generate command is to be used for code mangling before compiling ...)

I think that it's kinda the opposite: rather than one monolithic IDE, it's lots of little pieces working together. Pretty much what one would expect from the guys who brought us Plan 9 and Go…

Re: Four days of Go

#186
This author is quite exaggerating a bit. It seems like he himself is constantly preoccupied with politics. Fine. But this doesn't mean other people who he see with his eyes are necessarily thinking in the same pattern. "Machiavellian" is such a heavy word. Go started out with a purpose, a purpose which makes a lot of sense. It's not all about "make a new language and shove the new rules onto everyone by coupling it with Very Fast Build Times, a kind of veto-proof Defense Spending Bill in the Congress of computer programming." Such a design has a lot of practical value.
Post reply on HN