Toward Go 2 • Hacker News Board

Re: Toward Go 2

#191

Post by vram22 » Thu, Jul 13, 2017, 7:50 PM UTC

pjmlp wrote: post #67

crawshaw wrote: post #5

Earlier quoted context omitted.

Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor published several of his previous efforts, which had shortcomings he was dissatisfied with. I believe your impression of the Go team's position has been corrupted (likely unintentionally) by intermediaries.

Except they seem to focus only on Java, .NET and C++, forgetting that generics were initially implemented in CLU back in 1975, and there were several programming languages since those days that had some form of generics being designed into them.

Any thoughts on Eiffel's implementation of generics?

https://en.wikipedia.org/wiki/Eiffel_(programming_language)#...

Re: Toward Go 2

#192

Post by slantedview » Thu, Jul 13, 2017, 7:50 PM UTC

pmarreck wrote: post #141

camus2 wrote: post #127

Earlier quoted context omitted.

> overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead…

I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go

Python expats needed a place to go.

Re: Toward Go 2

#193

Post by Orangeair » Thu, Jul 13, 2017, 7:51 PM UTC

ahacker15 wrote: post #146

johansch wrote: post #114

My main wish: Please don't refuse to compile just because there are unused imports. Please do warn, and loudly say it's NON-CONFORMANT or whatever will embarass me enough from sharing my piece of Go code with someone else.. but.. can I please just run my code, in private, when experimenting?

I like that Go don't allows unused import and variables. If you're working with inexperienced programmers (and some experienced but bad programmers), you should be certain that they WILL let that code garbage there if the compiler allow it.

That's the kind of thing that should be detected by a linter and stop code submission though, not necessarily stop it from even compiling. What if you just want to comment something out quickly? I don't program in Go, but it seems like it would be annoying to have to repeatedly add and remove the main dependencies while I was iterating on something.

Re: Toward Go 2

#194

Post by pebers » Thu, Jul 13, 2017, 7:52 PM UTC

andrewprock wrote: post #145

treehau5 wrote: post #131

Earlier quoted context omitted.

> Pike said "Go design" is done. Except that a language which design "is done" is a dead one. Guess C is done for.

I think you're confusing stable with "done". The C language has been getting updates about once every 10 years: Original (~1970) K&R (~1980) ANSI C (~1990) C99 (~2000) C11 (~2010) I would not be surprised to see a C22.

To what degree are those being used though? Major projects (e.g. Linux, CPython) are still on ANSI C.

Re: Toward Go 2

#195

Post by loup-vaillant » Thu, Jul 13, 2017, 7:53 PM UTC

> 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. […] If we had a large set of real-world use cases, we could begin to answer a question like this by examining the significant ones.

Not implementing generics, then suggesting that it would be nice to have examples of generics being used in the wild… You had it coming, obviously.

Now what's the next step, refusing to implement generics because nobody uses it?

> Every major potential change to Go should be motivated by one or more experience reports documenting how people use Go today and why that's not working well enough.

My goodness, it looks like that is the next step. Go users have put up with the absence of generics, so they're not likely to complain too loudly at this point (besides, I hear the empty interface escape hatch, while not very safe, does work). More exacting developers have probably dismissed Go from the outset, so the won't be able to provide those experience reports.

Re: Toward Go 2

#196

Post by int_19h » Thu, Jul 13, 2017, 7:54 PM UTC

phillipcarter wrote: post #33

Analemma_ wrote: post #8

> 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. This is sampling bias at work. The people who need generics have long since given up on Go and no longer even bother participating in Go-related discussions, because they've believe it will never happen. Meanwhile, if you're still using Go, you must…

We have a similar viewpoint w.r.t Higher Kinded Types in F#. Much of the motivation for HKTs comes from people wishing to use them how they've used them in other languages, but we've yet to see something like this in our language suggestions or design repositories: "Here is a concrete example of a task I must accomplish with , and the lack of HKTs prohibits me from doing this in such a way that I must completely re-t…

It's the same thing in principle, but it's one of those cases where details matter a lot. Generics have been mainstream - as in, implemented in mainstream programming languages used to write millions of lines of production code - for over a decade now. At this point, someone claiming that they need specific user scenarios to convince them that generics are worthwhile, or that they aren't aware of a "good enough" way to implement them, beggars belief.

Re: Toward Go 2

#197

Post by girvo » Thu, Jul 13, 2017, 7:54 PM UTC

dvt wrote: post #80

munificent wrote: post #25

> 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. I work on the Dart language. Dart was initially designed with generic classes but not generic methods. Even at the time, some people on the team felt Dart should have had both. We proceeded that way for several years. It was annoying, but tolerable because of Dar…

I edited a book on Dart a few years ago. It's a shame the language hasn't gotten much traction outside of Google, as I enjoyed learning and using it.

I think it'll see more traction with Flutter and the like over the next year

Re: Toward Go 2

#198

Post by Tyr42 » Thu, Jul 13, 2017, 7:54 PM UTC

didibus wrote: post #177

I get that everyone would love to have a functional language that's eager by default with optional lazy constructs, great polymorphism, statically typed with inference, generics, great concurrency story, an efficient GC, that compiles quickly to self contained binaries with simple and effective tooling which takes only seconds to setup while giving you perfomance that equals java and can rival C, with a low memory fo…

Sounds like you want Eager Haskell.

Re: Toward Go 2

#199

Post by pjmlp » Thu, Jul 13, 2017, 7:54 PM UTC

vram22 wrote: post #191

pjmlp wrote: post #67

Earlier quoted context omitted.

Except they seem to focus only on Java, .NET and C++, forgetting that generics were initially implemented in CLU back in 1975, and there were several programming languages since those days that had some form of generics being designed into them.

Any thoughts on Eiffel's implementation of generics? https://en.wikipedia.org/wiki/Eiffel_(programming_language)#...

I liked using it at the university back in the day, and didn't had to repeat code.

Eiffel is a very powerfull language with good tooling, just failed adoption, because licenses were too expensive and software industry still has issues valuing quality.

Re: Toward Go 2

#200

Post by notjack » Thu, Jul 13, 2017, 7:55 PM UTC

> We did what we always do when there's a problem without a clear solution: we waited. Waiting gives us more time to add experience and understanding of the problem and also more time to find a good solution. In this case, waiting added to our understanding of the significance of the problem, in the form of a thankfully minor outage at Cloudflare. Their Go code timed DNS requests during the end-of-2016 leap second as taking around negative 990 milliseconds, which caused simultaneous panics across their servers, breaking 0.2% of DNS queries at peak.

This is absurd. Waiting to fix a known language design issue until a production outage of a major customer is a failure of process, not an achievement. The fact that the post presents this as a positive aspect of Go's development process is beyond comprehension to me.