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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

291–300 of 670 posts

Re: Toward Go 2

#291

Post by vec »

fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

I'm not even a Go developer, I just played with it a bit a couple of years ago and used it for a small one-off internal API thing, and I can think of a dozen real-world use cases for generics off the top of my head.

  * type-safe containers (linked lists, trees, etc.)
  * higher order functions (map, reduce, filter, etc.)
  * database adapters (i.e. something like `sql.NullColumn` instead of half a dozen variations on `sql.NullWhatever`)
  * 99% of functions that accept or return `interface{}`
I appreciate that they seem open to the idea for v2, but "the use case isn't clear" is absurdly out of touch with the community. Using `interface{}` to temporarily escape the type system and copy/pasting functions just to adjust the signature a bit were among the first go idioms I learned, and they both exist solely to work around the lack of generics.

Re: Toward Go 2

#292

Post by geodel »

elliotmr wrote: post #233

I must say that whenever there is a discussion about the merits of the Go programming language, it really feels hostile in the discussion thread. It seems that people are seriously angry that others even consider using the language. It is sort of painful reading through the responses which implicitly declare that anybody who enjoys programming with Go is clueless. It also really makes me wonder if I am living in some…

It is because some people here who have no stake in Go programing seem extraordinarily angry or maybe just concerned that why the hell Go authors didn't just override Go programmers' and listened only to enlightened PL experts here and at Reddit.

If it were a topic of gender or race instead of programing language I am sure this behavior would be called out as mansplaining/whitesplaining.

I do wish some term like 'PLsplaining' be used for this infuriating behavior of calling Go/PHP or whatever programmers clueless.

Re: Toward Go 2

#293

Post by camus2 »

elliotmr wrote: post #233

I must say that whenever there is a discussion about the merits of the Go programming language, it really feels hostile in the discussion thread. It seems that people are seriously angry that others even consider using the language. It is sort of painful reading through the responses which implicitly declare that anybody who enjoys programming with Go is clueless. It also really makes me wonder if I am living in some…

> It also really makes me wonder if I am living in some sort of alternate reality. I am a professional programmer working at a large company and I am pretty sure that 95% of my colleagues (myself included, as difficult as it is for me to admit)

What are you and your co-workers using aside from Go?

Re: Toward Go 2

#294

Post by slavapestov »

dbaupp wrote: post #280
slavapestov wrote: post #256

Earlier quoted context omitted.

> The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). There is also the approach taken by Swift, where values of generic type are unboxed in memory, and reified type metadata is passed out of band. There's no mandatory monomorphization.

The Swift approach shares many of the same characteristics and trade-offs as "true" (aka Java-style) boxing. Of course, it does avoid some downsides of that, but also brings along some additional ones.

I think the main difference is that the Swift approach ends up being more memory-efficient, eg consider Swift's Array is stored as an array of integer values compared to a Java's ArrayList where each element is boxed.

Also the Swift optimizer can clone and specialize generic functions within a module, eliminating the overhead of indirection through reified metadata.

Re: Toward Go 2

#295

Post by mappu »

lemoncucumber wrote: post #158

As much as I want them to fix the big things like lack of generics, I hope they fix some of the little things that the compiler doesn't catch but could/should. One that comes to mind is how easy it is to accidentally write: for foo := range(bar) Instead of: for _, foo := range(bar) When you just want to iterate over the contents of a slice and don't care about the indices. Failing to unpack both the index and the val…

If `bar` is a slice then the short syntax isn't that useful (although it's shorter than the three-clause for loop equivalent).

But if `bar` is a map or a channel, then that short syntax is very handy.

For comparison's sake, you don't see many PHP users complaining about the difference between `foreach($bar as $foo)` and `foreach($bar as $_ => $foo)`.

Re: Toward Go 2

#296

Post by Spiritus »

cdelsolar wrote: post #219
kzisme wrote: post #136

Earlier quoted context omitted.

This is the sort of thing that makes it hard to get started with Go in my opinion.

It shouldn't be. Set the GOPATH once and use any text editor.

Except you have to set it every time you open a shell. You can’t put it into your .bashrc either unless you only ever work on one project. This workflow sucks:

    $ cd projects/foo
    $ export GOPATH=$PWD
    $ cd src/github.com/company/foo
    $ go build

Re: Toward Go 2

#297

Post by rbehrends »

ziotom78 wrote: post #212
nightski wrote: post #203

Earlier quoted context omitted.

Nearly every item on your list is available with OCaml.

Apart from "great concurrency story", because of the well known problems with the GC. This might be a huge shortcoming for a number of people.

It isn't a great concurrency story, but the shortcomings are also overstated. OCaml does message-passing concurrency just fine and allows for shared memory for arrays and matrices of scalars, which is good enough for most scenarios.

(Technically, there's also Ocamlnet's multicore library, but that's too low-level for most people.)

Re: Toward Go 2

#298

Post by cdelsolar »

Spiritus wrote: post #296
cdelsolar wrote: post #219

Earlier quoted context omitted.

It shouldn't be. Set the GOPATH once and use any text editor.

Except you have to set it every time you open a shell. You can’t put it into your .bashrc either unless you only ever work on one project. This workflow sucks: $ cd projects/foo $ export GOPATH=$PWD $ cd src/github.com/company/foo $ go build

OP was talking about getting started. I also don't understand why you can't use the same GOPATH across multiple projects, especially with godeps?

Re: Toward Go 2

#299

Post by JepZ »

masklinn wrote: post #23
JepZ wrote: post #15

I know there is a lot of discussion about generics, but I am not sure if that is missing the point. I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go. From my experience I think we should talk about container formats because they make 80% of what we would like to have generics for. Actually, go feels as if it has only two container data st…

> I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go. That's inane and insane. Java generics do almost nothing, they don't even exist at runtime in a language with (much like Go) heavy runtime semantics. Here's what Java's generics do: get typechecked, and insert implicit casts. > Yes, I am sure there are more container formats First, you f…

> What does that mean? It is not easy enough what? To write containers? To have generics?

Actually, I meant it is not easy enough to build container formats (maybe due to the lack of generics).

Btw. I will not continue this conversation as I am tired of getting insulted (inane and insane), getting downvoted for merely asking questions and you editing your post without labeling it. Just saying.

Re: Toward Go 2

#300

Post by hota_mazi »

kevinconaway wrote: post #138
jasonwatkinspdx wrote: post #118

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a he…

> asking for monotonic time His anecdote about Google/Amazon using leap smears to solve the problem is telling. I suspect that they were unable to see outside their own bubble to think about how others may be impacted. > We did what we always do when there's a problem without a clear solution: we waited The original problem described the issue and the potential consequences very well and the problem didn't change bet…

> We did what we always do when there's a problem without a clear solution: we waited

And this is exactly why the Go designers don't understand language design, and how this ignorance shines through every single place in their language.

Language design is about compromises. There is never a perfect solution, only one that satisfies certain parameters while compromising others. You, the designer, are here to make the tough choice and steer the language in a direction that satisfies your users.

Besides, characterizing their position as "We waited" is very disingenuous. First of all, this is more stalling than waiting, and second, waiting implies they at least acknowledge the problems, which the Go team famously never does. Read how various issues are answered and then summarily closed with smug and condescending tones.

Post reply on HN