Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.6 is Released

blog.golang.org

Post reply on HN
Print view View original

341–350 of 367 posts

Re: Go 1.6 is Released

#341

Post by azth »

jerf wrote: post #100
mtrn wrote: 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.

Except that it is very difficult to find out which struct implements what interface, you'd have to go look through the code. Not to mention there is always the possibility of accidentally implementing an interface. This has already caused real issues it seems (there was a blog post about it).

There already exists a solution for this issue, via typeclasses.

But golang doesn't have generics.

Re: Go 1.6 is Released

#342

Post by abc_lisper »

groovy2shoes wrote: post #340
abc_lisper wrote: post #63

Earlier quoted context omitted.

Either you are very good, or you are working on small projects. Can't say which! Java is 100-ton dinosaur to be working with using a simple editor. Spring, it dependencies, hibernate, junit alone make you want to work with an IDE.

I once wrote a forest fire simulator based on a cellular automaton in Java using nothing but a terminal and Leafpad. It's doable, I promise.

Yeah, I can believe that. However webapps(in your average startup) are far more complex, in the tools, libraries they use.

Re: Go 1.6 is Released

#343

Post by sriram_malhar »

Have been using Go since its release, and like the deployment experience, the feeling of solidity of putting together a tight system. The toolchain is great. 1.6 is yet another Solid release in that direction. Thank you all.

However, the _language_ doesn't give me much programming pleasure alas. Since there is plenty of time for Christmas, here's my syntax wish list :)

'?': C's if-then-else operator.

Block-syntax for closures ala Ruby. Unifying blocks and closures makes creating DSLs easy, but doesn't add to cognitive load (no more than using anon funcs)

Pattern matching like Scala, ML, Rust.

Sum types -- (Yeah, I lied. Not just syntax enhancements), or at least discriminated unions. I'd like to see an example (in the FAQ entry on the topic) on why support for it is troublesome.

For 2017 Christmas, -------------------

Macros ala Nim.

Systemic support for Goroutines, including detection of conditions where a goroutine would never get scheduled. Erlang-like tools for built-in goroutine insight.

------

My ideal language would be an intersection of Nim+Go

Re: Go 1.6 is Released

#344

Post by rphlx »

> Source trees that contain a directory named “vendor” that is not used in accordance with the new feature will require changes to avoid broken builds

That seems a little bit distasteful.

Re: Go 1.6 is Released

#345

Post by majormjr »

kasey_junk wrote: post #45
eddiezane wrote: post #34

I've really enjoyed the time I've spent with Go but feel like the state of dependency management has kept me away. Am I being stubborn in my longing for an npm, Ruby Gems, or pip? Is there a reason why one of these hasn't emerged/been adopted by the community? (I'm aware of the 1.5 experiment with vendoring.) Semver and pinning versions has always just made sense to me. I can easily adopt new features and fixes autom…

Dependency management is a huge weakness in golang and there isn't much point in debating it. That said, my time in golang has crystalized something I'd been leaning towards anyway, that is dependencies are way more dangerous than we think they are. I find all of my code now (golang or otherwise) less likely to have dependencies, and therefore dependency management weaknesses are mitigated (not solved).

Agreed, Go's strong standard library also helps avoid dependencies.

Re: Go 1.6 is Released

#346

Post by pjmlp »

johan_larson wrote: post #335
pjmlp wrote: post #220

Earlier quoted context omitted.

Just wait when Go EE becomes a thing. Then you will get testing frameworks, libraries each with its own generics workaround and cool interface spaghetti that looks beautiful in UML diagrams at the scrum wall room. People don't really get that before Java there was C EE and C++ EE, all with similar sins. One can change the language of the enterprise, but not what those architects do with them.

I fear you are right. Go's simplicity, its pattern of having one and only one way of doing anything, is likely a product of its youth and unpopularity. As the years pass and its following grows, people will come along who want to do things differently, and the ecosystem will become richer but also more confusing. Perhaps the best thing for the language would be for it not to become too popular.

Avoid success at all cost.

-- Haskell

Re: Go 1.6 is Released

#347

Post by duaneb »

Nutomic wrote: post #337
fithisux wrote: post #255

Earlier quoted context omitted.

I agree with you. But this code, does not compile List [] j=new List [10]; and this is a a serious problem. If generics are correctly implemented, then it should compile.

That's because List is an interface, not a class. FYI this works in Scala: val j = List(1, 2, 3)

It doesn't work for all scala interfaces, and when it is like that, it's often frustrating to find the underlying implementation.

But that's beside the point—OP was pointing out that you can't have generic allocation.

Re: Go 1.6 is Released

#348

Post by _ak »

golergka wrote: post #289
sigjuice wrote: post #175

Earlier quoted context omitted.

What is horrible about $GOPATH?

The notion that you can't put the codebase wherever you want to on your own computer. A "project", as a folder, should be atomic and work regardless of where it is moved; the $GOPATH convention just breaks this encapsulation completely. For example, when I create client-server projects, sometimes I put both client and server under the same git repository, in the same folder (whether it is a good or bad decision is an…

I wrote an extension to gb (the go build tool released by Dave Cheney) that uses gb's functionality to determine the $GOPATH where it operates, plus an alias gbpath="eval `gb gopath`", so a simple gbpath sets the right $GOPATH no matter where I am in the filesystem. I should probably release that at some point.

Re: Go 1.6 is Released

#349

Post by merb »

duaneb wrote: post #347
Nutomic wrote: post #337

Earlier quoted context omitted.

That's because List is an interface, not a class. FYI this works in Scala: val j = List(1, 2, 3)

It doesn't work for all scala interfaces, and when it is like that, it's often frustrating to find the underlying implementation. But that's beside the point—OP was pointing out that you can't have generic allocation.

However there are mostly alternatives for Java8 something like that: Collections.singletonList(1, 2, 3) which actually gives a List by the end it all comes down to syntactic sugar.

Re: Go 1.6 is Released

#350

Post by ue_ »

Cyph0n wrote: post #10

I can't wait to see what's new in 1.6! I really had a pleasure working with Go for my senior project last year. If I need to write either a server (HTTP or TCP/UDP), or a client application that must be easy to build and distribute, Go is my first choice. What Go is lacking at this moment in my opinion is: 1) A comprehensive and mature web framework. Play w/ Scala is my go-to choice now, with Django a very close seco…

>A comprehensive and mature web framework.

Call me old fashioned, but I've only ever used the stuff from Gorilla (mux and sessions) and before that plain CGI with Go, and running behind uriel's cgd to hook it up with nginx.

I've never been fond of web frameworks that try to hide a lot of stuff from you.

Post reply on HN