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

321–330 of 670 posts

Re: Toward Go 2

#321

Post by 43224gg252 »

slantedview wrote: post #162
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…

The idea of needing to come up with use cases for generics is baffling. The existence of generics in numerous other languages already support of plethora of use cases. I really don't get that statement at all.

Then why don't you come up with a legitimate use case?

Re: Toward Go 2

#322

Post by baq »

jimjimjim wrote: post #246

Here be Opinions: I hate generics. also, I hate exceptions. Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory. If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths an…

there's nothing magic about generics. every time you make a channel or a map in go, you're using a generic function even if go people don't want you to call it that.

there's nothing magic about exceptions, too, it's that it's harder than necessary to use them correctly and that's why it's not as big of a deal to not have them in go - as evidenced by this thread.

Re: Toward Go 2

#323

Post by erikpukinskis »

kernelbandwidth wrote: post #184
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…

The request for use cases in Go seems a bit like begging the question to me. Since Go doesn't have generics, anything designed in Go will necessarily take this into account and design around this lack. So it's relatively easy to show that Go doesn't have a compelling use case for generics, since the designs implemented in Go wouldn't (usually) benefit from generics! Rust has generics and traits/typeclasses, and the r…

This suggests that both generics and inheritance are unnecessary.

Re: Toward Go 2

#324

Post by cyphar »

Spiritus wrote: post #89
lomnakkus wrote: post #82

Earlier quoted context omitted.

Asking for use cases when the use cases and benefits are already well-known seems pretty disingenuous to me. (Of both you and the blog post.) ... but, hey, just to indulge you, a few off the top of my head: - Generic containers in libraries (aka not built-in) - Parametricity to restrict user-supplied implementations of interfaces; not quite as valuable in a language with casts, etc., but still reasonably valuable. -…

I was merely suggesting to indulge the author, especially now that generics might actually happen.

The problem is that the community did indulge the author and the other Go maintainers 5 years ago and their was an apparent refusal to see lack-of-generics as an issue, almost as though Turing-completeness was sufficient justification to not include them.

"Find us examples and show us so we can ponder this further" is incredibly condescending after we did that 5 years ago and they decided to stall (or to use the author's term, "wait") on the issue. Honestly I think it might be too late for generics to be added, because the large body of existing interfaces aren't generic and likely would have a very high transition cost.

Re: Toward Go 2

#325

Post by egonschiele »

Most of the discussion here seems to be around generics, and it sounds like they still don't see the benefit of generics.

I like Go, but the maintainers have a maddeningly stubborn attitude towards generics and package managers and won't ease up even with many voices asking for these features.

Re: Toward Go 2

#326

Post by abiox »

nightski wrote: post #203
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…

Nearly every item on your list is available with OCaml.

it's a bummer that the windows story for ocaml is so sketchy. i'd like to use it for work (various utilities and whatnot) but the ecosystem seems to make a lot of assumptions about the system it runs on. (for me there's still haskell and rust at least.)

Re: Toward Go 2

#327

Post by kccqzy »

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…

Generics in Go: https://twitter.com/snoyberg/status/882255351382462464

Re: Toward Go 2

#328

Post by cyphar »

vram22 wrote: post #290
scribu wrote: post #235

Earlier quoted context omitted.

Not quite. The article mentions that Go 1 code needs to be able to coexist with Go 2 in the same codebase. So, at runtime, Go 1 code needs to be able to work with Go 2 types. That will impose some restrictions, I imagine.

>The article mentions that Go 1 code needs to be able to coexist with Go 2 in the same codebase. Interesting. Are there any other languages where that is allowed? I'm assuming that by "codebase" you mean all the code that gets compiled into one program or library (for compiled languages), or is part of one program or library (for interpreted languages). And I don't mean the case where only a common subset of Lang X v…

I would just read the article. Basically, the restriction they want to impose is to make sure that you can import v2 code into a v1 codebase and vice-versa with a v2 compiler. So that means any syntax breakage would need to be versioned or otherwise inferred, I guess.

Re: Toward Go 2

#329

Post by zemo »

zackmorris wrote: post #214

Go doesn't have const structs, maps or other objects: https://stackoverflow.com/questions/43368604/constant-struct... https://stackoverflow.com/questions/18342195/how-to-declare-... This is a remarkable oversight which makes it impossible to write purely-functional code with Go. We also see this same problem in most other imperative languages, with organizations going to great lengths to emulate const data: https://f…

it's almost like writing purely-functional code is not the goal of Go.

Re: Toward Go 2

#330

Post by kccqzy »

erikpukinskis wrote: post #323
kernelbandwidth wrote: post #184

Earlier quoted context omitted.

The request for use cases in Go seems a bit like begging the question to me. Since Go doesn't have generics, anything designed in Go will necessarily take this into account and design around this lack. So it's relatively easy to show that Go doesn't have a compelling use case for generics, since the designs implemented in Go wouldn't (usually) benefit from generics! Rust has generics and traits/typeclasses, and the r…

This suggests that both generics and inheritance are unnecessary.

It only suggests you can't easily give an example because the language is forcing a design where such things aren't needed. Sort of like linguistic relativity.
Post reply on HN