Live data from Hacker News

Go 1.6 is Released

blog.golang.org

171–180 of 367 posts

Re: Go 1.6 is Released

#171
post #100

Earlier quoted context omitted.

"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 f…

The list of languages that permit that in a principled way is short, and the list of languages where it's a good idea is even shorter. I've come to the conclusion that it's generally not a good idea. (And it's not Go making me say that, it's more Haskell.) Keeping dependencies flowing in one direction seems to be a good plan.

Re: Go 1.6 is Released

#172
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…

This is very similar to my experience. There are some very obvious flaws that have been analyzed to death, but I find myself returning to Go despite them. The native binaries and extremely simple cross-compilation are the features that I really miss with other languages.

Re: Go 1.6 is Released

#173
post #171

Earlier quoted context omitted.

> 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 f…

The list of languages that permit that in a principled way is short, and the list of languages where it's a good idea is even shorter. I've come to the conclusion that it's generally not a good idea. (And it's not Go making me say that, it's more Haskell.) Keeping dependencies flowing in one direction seems to be a good plan.

I totally disagree. It's not only a good idea, it's essential for certain core functionality to work at all. Take serialization, for example: without this feature it's impossible to write a good serializer as a library without code generation (messy and brittle) or reflection (very slow). To give another example, try writing a linear algebra library that's generic over the data type without this feature (and such libraries are essential for high performance graphics programming). The only way I can think of to make it work is to make callers explictly box their numbers into wrapper types you create, which is really ugly and causes various other problems.

I don't understand the idea that not having this feature somehow helps enforce dependency order either. Extension implementations of traits don't give you any more abstraction-breaking power than downcasting interface{} to a concrete type not defined in your package does. In fact, they're pretty much strictly less powerful.

Re: Go 1.6 is Released

#174
post #31
post #18

Earlier quoted context omitted.

Even with the delve debugger?

Despite being a great work, delve is slow and sometimes might skip some of my breakpoints and have problems in debugging goroutines.

Yeah, it can get pretty confusing. It would nice if there was a way to define a breakpoint that only gets tripped by a specific goroutine.

Re: Go 1.6 is Released

#175

I just recently started with go, but I love how simple (apart from horrible $GOPATH) and effective that is. Still can't get over the moment I realized that in order to deploy my web server on an empty virtual box all I had to so was to build and upload. After all the languages and frameworks that required endless customization and setting up it was a true eureka moment.

What is horrible about $GOPATH?

Re: Go 1.6 is Released

#176

Earlier quoted context omitted.

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

You don't have to "get" anything. If Java works for you, great!! Go just works better for some of us, and that's all the justification we need.

This type of comment is common, but specious. It sounds nice: "what works for you; great! this works for me" but it undermines a large category of important discussions: e.g. analyzing which, out of several competing discussions, is a better fit for large classes of people, or on average. In other words, I think this sort of comment strays too far in the direction of niceness, and tends to undermine simple, and desirable, notions of better vs. worse, etc.

TL;DR being nice and polite is over-rated. Some things are wrong and it is helpful to say so.

Re: Go 1.6 is Released

#177

Earlier quoted context omitted.

No because you can't easily pass multiple return values as parameters. So annoying...

Actually you can: https://play.golang.org/p/a-qhe_vRvo

Thanks, I've never seen that used and didn't know they special-cased it until I found https://golang.org/ref/spec#Calls. I wonder why it's not more common...

Re: Go 1.6 is Released

#178

Earlier quoted context omitted.

For my money, Java is a pretty good language; there are only a couple of things that I think were real mistakes in the core language. And the JVM certainly performs. But the ecosystem around Java is very complex and hard to manage. Dealing with JVM configuration, webserver configuration, build system configuration, IDE configuration and God knows what else takes up all kinds of brain-space. And every so often the com…

> culture really needs to learn the value of the simple and explicit. This is true for any programming community.

"Compile times must be fast"

Re: Go 1.6 is Released

#179
post #97
post #68

Go CSP is minimal and ortongonal, I just wish it did three things: 0. could lto optimize or link against a shared library to reduce the titanic size of compiled programs and cut down on duplication of instruction. Therue is no practical sense in wasting memory and storage on systems with dynamic linkers: edge cases of including the world for rare situations but YAGNI in real production systems. 1. could output flat b…

0. It does dynamic linking on most stdlibs (libc, etc) 1. What do you mean self-hosted runtime? Anyways, golang will likely never be a good candidate for kernel development, but in theory you could do it (go supports assembly) 2. Generics would be nice. Who knows, maybe they'll be in 2.0? Go wasn't developed in llvm, because they wanted to build something very fast, and they were planning on writing the compiler in g…

> 2. Generics would be nice. Who knows, maybe they'll be in 2.0?

There will be no 2.0 and there will be no generics, at all.In fact there will never be any changes to the type system, cause it's impossible at this point.

Re: Go 1.6 is Released

#180

Earlier quoted context omitted.

Actually you can: https://play.golang.org/p/a-qhe_vRvo

Oh my god...is that new? I swear I've tried that and it didn't work. You are my new hero. [edit] Though maybe I was thinking of adding parameters like https://play.golang.org/p/FKUMlQzCI5 In any case 'thebaer continues to be my hero.

Haha, I'll take it. Go forth and wield your new power! I'm not able to find anywhere official documenting it, but yeah I don't believe it's new.

Edit: prodigal_erik found it: https://golang.org/ref/spec#Calls

Post reply on HN