Live data from Hacker News

Go 1.6 is Released

blog.golang.org

121–130 of 367 posts

Re: Go 1.6 is Released

#121

Can someone give a decent explanation of the following: 1) Supposed I have a library that was written in C that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program. 2) Supposed I have a library that was written in Go that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled vers…

1) Was this static C library? Then you need to recompile. If it was dynamic then the question is did abi change? If yes, you need to recompile, otherwise you don't (but security updates usually don't break abi).

2) Always.

3) Yes, Go runtime is linked in to executables build with Go.

Re: Go 1.6 is Released

#122
post #44

Earlier quoted context omitted.

Java doesn't require an IDE either: emacs/Ant/Maven is all I've ever used. Barring specialized platform-specific toolsets (like Android Studio) you don't NEED anything else (you might WANT something else, but that's a separate issue...)

emacs is an IDE wrapped inside half an OS

I would like people that keep saying stupid stuff like this to try and compare the size of GNU Emacs to the size of, say, NetBeans, Eclipse or Visual Studio.

There is an enormous amount of stuff that "conventional" IDEs to and emacs does not do.

Consider NetBeans: there are a lot of people that use the NetBeans platform to create stuff that have nothing to do with programming, the very same way emacs users create modes that have nothing to do with programming: https://platform.netbeans.org/screenshots.html

Seriously guys, grow the fk up.

Re: Go 1.6 is Released

#123
post #14

Earlier quoted context omitted.

"is opinionated"? What does that mean in the context of a computer programming language?

Doesn't attempt to please everyone. Case in point: no OOP or inheritance and no FP. Minimal syntactic sugar.

Nitpick - Go is very much an OO language. Almost everything is done using objects. It has a different way of handling inheritance however - it makes a different decision in the "Composition over inheritance" debate.

https://en.wikipedia.org/wiki/Composition_over_inheritance

Re: Go 1.6 is Released

#124

Can someone give a decent explanation of the following: 1) Supposed I have a library that was written in C that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program. 2) Supposed I have a library that was written in Go that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled vers…

3) A compiled Go binary contains the import paths of all used libraries plus all variable names that they are using. Also the header of the binary contains a string like "Go" followed by a hash. If you open a binary in a Hex Editor you will see it yourself.

Re: Go 1.6 is Released

#125
post #115
post #6

Earlier quoted context omitted.

The more I dig into type coercion and interfaces the less I miss generics. Still not 100% there, but for day to day the things I used to use generics for have been replaced by alternates. I still wish I never had to write `interface{}` though. Debugging absolutely needs work though.

What is an alternate? I've never heard of that and Googling tells me nothing.

I'm guessing that means something more like "alternatives," but that's just a guess.

Re: Go 1.6 is Released

#126

Earlier quoted context omitted.

I'm not sure that I understand your definition of the term "opinionated". Is Haskell opinionated? Is Fortran?

I take opinionated to mean one obvious way to do things. Python and Go are opinionated. Ruby and Perl are not. But RoR is very opinionated.

> I take opinionated to mean one obvious way to do things. Python and Go are opinionated.

IMO Python wants to be opinionated (in your 'one obvious way' definition), and it actually was 10-15yrs ago when Perl was the comparison, but ongoing progress has eroded that a lot - especially across the stdlib :)

But yeah Go and RoR are probably two of the most opinionated technologies I can think of.

Re: Go 1.6 is Released

#127
post #58

Go has a lot going for it. That said, there were a few points I noted, based on a recent go I gave it (pardon the pun), at least in relation to my style of development for this project: 1. It's hard to tinker, mostly because it's fussy about what variables are defined or used. This is a strength in the usual course, but when one is trying to posit what a poorly documented 3rd party API is doing it can be a serious pa…

For (1), I'd highly suggest using 'goimports' (my editor's fmt-on-save uses 'goimports' by default). It will remove and add non-referenced imports as needed. Also, quick prototyping is partially what the underbar (_) notation is meant for in variable assignments.

As for (2), I feel it's more of a consequence of programmers not using error types to its advantage. Since Error is an interface it allows for an absurd amount of flexibility (e.g. bundle up a whole bunch of information into one error and send it back) and typed errors, both of which are excellent for testing and debugging.

As for (3), I usually rely on printing output (github.com/davecgh/gospew is quite useful). To get a stack trace just calling panic() in the offending code area will suffice.

No arguments on (4) - it could be better - but I think support for vendoring is a good step, and the maintainers seem to be taking it slow and getting it right.

On (5) -- if you go get the package it's available in GOPATH and/or it's usually vendored, so you can just go edit it in place (including debugging statements if you need more insight) without needing to know any magic $X_PATH rules -- I see this as a huge advantage. Furthermore, go get-ed code is each in its own version control repo, so sending patches back upstream is (generally) easier than ever.

Anyway, hope I don't seem argumentative (everyone has different tastes), but maybe some of these suggestions might help you a bit with your language peeves.

Re: Go 1.6 is Released

#128
post #100
post #26

Earlier quoted context omitted.

I am reading and writing Go and Java almost daily. Java has a tendency to be written in an over-engineered way. The Go community has an inclination towards cautious abstractions. Take interfaces. In Java you might start with them. In Go - in the best case - they emerge, when it's time for them. Java has more mature tooling, but then, I cannot remember gathering runtime insights with Java quicker than with Go pprof[1]…

"Take interfaces. In Java you might start with them. In Go - in the best case - they emerge, when it's time for them." And it's a relatively subtle language feature that does this, the way that any struct that implements a given interface automatically conforms to that interface without having to be declared. Which means you can declare an interface that foreign packages already conform to, and then freely use them.…

> Which means you can declare an interface that foreign packages already conform to, and then freely use them.

But you cannot do the reverse: you cannot make a type from a foreign package conform to your interface by adding new methods to it. This is because, with structural typing, it's not safe to add methods to types in other packages, since if packages B and C both were to add a conflicting method Foo to a type from package A, B and C could not be linked together. This is a major downside of structural typing for interfaces. Swift, for example, has the "extension" feature, and Java's design allows for it in principle, but it's fundamentally incompatible with Go's design.

Re: Go 1.6 is Released

#129
post #5

Go checks a lot of boxes for my ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports concurrency very well, is opinionated, is small/simple, its community prefers to just use standard lib for most work, etc. Yes, Generics is an issue and so is debugging. But, overall, I can't think of many other options that check so many boxes. EDIT: I must h…

Java SE and a fat jar... checks all the boxes and has generics and superior tooling. I still don't get the Go love.

If I may also chime in with one idea as to why someone might prefer Go: Java simply is not opinionated enough. Compare two developers Java code and it looks, flows, feels completely different.

Go forces people more into boxes and leaves a lot less up to discussion. This is annoying for the individual contributor, but I believe is a net plus for a team of contributors.

Re: Go 1.6 is Released

#130
post #33

Earlier quoted context omitted.

Yes, I'd say modern Java is a good candidate too. However, the verbosity is a deal-killer for me. Go's error handling can be verbose, but while scanning the code, if I want/need to, I can easily skip through the error handling parts mentally. Java, though, is verbose everywhere. EDIT: Actually mtrn said it better: Java feels over-engineered.

Okay, ditch Java if it's too verbose and adopt one of Kotlin, Groovy (w/ @CompileStatic) or Scala.

Or Clojure.
Post reply on HN