7 ms·

In before "but adding generics does not make team projects harder, look at language ..." Your (and many other people's) insistence on dismissing discussion reg

by adrusi 12y ago

In before "but adding generics does not make team projects harder, look at language ..." Your (and many other people's) insistence on dismissing discussion regarding generics as some kind of a joke is anti-intellectual. You're rejecting valid criticism of your arguments on the basis that the critic's argument is unworthy of attention for some reason external to the discussion at hand. I agree that pro-generics arguments are usually boring, and at least 90% of what they say has been heard before. But the same can be said of Go evangelism, like your comment; they are no less worthy. Please don't deliberately shut down discussion.

nemothekid 12y ago
I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics. Then people bring Rust, which has only had a stable grammar for last couple months and a standard library nowhere near Gos. Would it be wise to complain that the Rust stdlib doesn't contain a HTTP server implementation?
- Scarbutt 12y ago
  Rust's stdlib not containing a HTTP server is a deliberate act.
  - ori_b 12y ago
    Go not including generics is a deliberate act.
    - heinrich5991 12y ago
      A web server can easily be implemented as a library, generics are a language feature.
      - EugeneOZ 12y ago
        And library can be easily abandoned or just be broken after breaking changes in next version of language, and you will have to wait couple of months, while this issue will be solved. Or just fix all the things yourself.
        heinrich5991 12y ago
        Just fixing the language is not possible without major problems though.
        pcwalton 12y ago
        > after breaking changes in next version of language In practice Rust doesn't make breaking changes anymore. (It hasn't since beta, and in a month or so 1.0 will be declared officially stable and it will become forbidden to make them.)
- wwweston 12y ago
  It's not just the "not now" approach. It's the rhetoric that often goes along with it. The author of this piece picks up on it when he talks about the "we've already thought about this and we're tired of talking about it" vibe, though I might characterize a lot of the discussion around generics from the Go community at large more specifically as "you think you want/need this, but trust us, you don't, and the inconveniences you think you're experiencing are just not that big a deal, particularly compared to the inconveniences you'll experience if we do add it." And yes, if not having an HTTP server implementation in the stdlib seems like it makes your project difficult, that's a perfectly reasonable criticism of Rust. (Though one I suspect will get resolved much more quickly and cleanly than issues like generics in Go.)
  - steveklabnik 12y ago
    > I suspect will get resolved much more quickly and cleanly It's pretty easy. You just add this line to your Cargo.toml: hyper = "0.3.14" And the next time you build, Cargo handles everything. You can now use hyper like any other library that's included with Rust, no biggie. This is one reason we've chosen minimalism for the standard library: It's really easy to use external libraries, and once things land in the standard library, they often don't improve much. The versions become tied to the compiler versions, contributors now need to build the entire compiler rather than just working on a single library, and everything else. We've already seen three distinct major HTTP implementations happen, had we put rust-http right in the standard library, we'd have frozen something the author has already deprecated! Choosing non-minimalism has advantages too: in this scenario, you need to know that hyper is currently the best library, for example. Engineering is all about trade-offs. (Solely chiming in on the HTTP in Rust thing here. I found the part of the article about the Gopher... lacking, and it distracted me from the rest of the author's points.)
    - cryptos 12y ago
      > Engineering is all about trade-offs. What a wonderful sentence about a simple, but often forgotten truth!
    - EugeneOZ 12y ago
- MichaelGG 12y ago
  > I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics. I don't use Go so I don't really care about their generics or lack thereof. What I found ... odd ... is how the Go team has apparently said they can't go generics because there's no good way to implement them. Seems like a strange thing to say when many languages are happily using them.
  - barosl 12y ago
    After hacking Rust, I got the feeling that generics are hard. They are so hard that a language should consider them from the beginning to fully take advantage of them. That might be the reason why the Go team says generics are hard to implement in the current Go type system. They can also choose either C++-like code generation based on templates, or external code generating tools, but both are not perfect in my opinion.
  - ecnahc515 12y ago
    Implicit interfaces make generics a lot less trivial to implement. They also don't want to simply add an existing approach with bad trade-offs (see C++ templates). Likewise, adding a runtime based multi-dispatch based generic system is not much better than what we already have. Lot's of languages have generics, but they have trade-offs, so they aren't free, even if they can implement them using existing generics implementations. Picking what they're willing to sacrifice can be hard, even if it's something like slower compile times. Anything backwards compatible has to be in Go 2 or later, because generics are hard to make backwards compatible, we'll have to wait.
- aikah 12y ago
  it's not a "not now" approach, they are simply not going to add any new significant feature to the language (source : https://thechangelog.com/148/?utm_content=bufferf8f9d&utm_medium=twitter&utm_source=changelog&utm_campaign=buffer https://thechangelog.com/148/?utm_content=bufferf8f9d&utm_me... ) . Go will not have generics at all. People don't want generics for the sake of it, they want type safety.
howeyc 12y ago
That comment was there because my point was not about generics, but about programming language features (that are must have, the must have list of course being different for everyone) in general.
PopsiclePete 12y ago
Various core Go team members seem to have a different philosophy regarding generics. They actually don't have a united front on this. It seems Russ Cox and Rob Pike are either anti-generics or in the you-dont-really-need-them camp, but Ian Thompson and Brad Fitzpatrick have seemed very open to the idea - what they can't, however, agree on, is exactly how to implement them so that they make sense in Go. That's it. If you or anyone out there manages to produce a proposal of how they should work/look like and even a fork of Go implementing the idea, it will be taken seriously, at least by some core Go members. I have a feeling that generics are coming. And I have a feeling they'll be very Go-like - an external tool with code generation, not special syntax. Just my 2 cents.
- barosl 12y ago
  I think adding generics to a stable language is actually a hard thing to do. There's more than "that's it". Rust has had many major and minor changes regarding generics solely, which has broken backward compatibility each time. The Go team may find a brilliant way to accomplish this, but I think the only viable way left is, as you said, using code generation. Either C++-way, which is a special syntax but still a form of code generation, or an external tool. But neither of them is elegant, because you cannot fully utilize the convenience that the type system give. These might be the concerns that the Go team has.
  - PopsiclePete 12y ago
    Maybe the "elegance" is a factor as well, but I haven't seen it mentioned. All I've seen mentioned is: a) can't change syntax b) can't take huge performance hits at run time or at compile time c) can't break backwards compatibility d) talk is cheap - provide a working implementation So far, nobody has been able to show all 4 of these requirements, so nothing has been done. But when/if someone does, I expect it to be taken very seriously.
- amaranth 12y ago
  This is already a thing, no? https://blog.golang.org/generate https://blog.golang.org/generate

by adrusi 12y ago

nemothekid 12y ago

I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics. Then people bring Rust, which has only had a stable grammar for last couple months and a standard library nowhere near Gos. Would it be wise to complain that the Rust stdlib doesn't contain a HTTP server implementation?

Scarbutt 12y ago
Rust's stdlib not containing a HTTP server is a deliberate act.
- ori_b 12y ago
  Go not including generics is a deliberate act.
  - heinrich5991 12y ago
    A web server can easily be implemented as a library, generics are a language feature.
    - EugeneOZ 12y ago
      And library can be easily abandoned or just be broken after breaking changes in next version of language, and you will have to wait couple of months, while this issue will be solved. Or just fix all the things yourself.
      - heinrich5991 12y ago
        Just fixing the language is not possible without major problems though.
      - pcwalton 12y ago
        > after breaking changes in next version of language In practice Rust doesn't make breaking changes anymore. (It hasn't since beta, and in a month or so 1.0 will be declared officially stable and it will become forbidden to make them.)
wwweston 12y ago
It's not just the "not now" approach. It's the rhetoric that often goes along with it. The author of this piece picks up on it when he talks about the "we've already thought about this and we're tired of talking about it" vibe, though I might characterize a lot of the discussion around generics from the Go community at large more specifically as "you think you want/need this, but trust us, you don't, and the inconveniences you think you're experiencing are just not that big a deal, particularly compared to the inconveniences you'll experience if we do add it." And yes, if not having an HTTP server implementation in the stdlib seems like it makes your project difficult, that's a perfectly reasonable criticism of Rust. (Though one I suspect will get resolved much more quickly and cleanly than issues like generics in Go.)
- steveklabnik 12y ago
  > I suspect will get resolved much more quickly and cleanly It's pretty easy. You just add this line to your Cargo.toml: hyper = "0.3.14" And the next time you build, Cargo handles everything. You can now use hyper like any other library that's included with Rust, no biggie. This is one reason we've chosen minimalism for the standard library: It's really easy to use external libraries, and once things land in the standard library, they often don't improve much. The versions become tied to the compiler versions, contributors now need to build the entire compiler rather than just working on a single library, and everything else. We've already seen three distinct major HTTP implementations happen, had we put rust-http right in the standard library, we'd have frozen something the author has already deprecated! Choosing non-minimalism has advantages too: in this scenario, you need to know that hyper is currently the best library, for example. Engineering is all about trade-offs. (Solely chiming in on the HTTP in Rust thing here. I found the part of the article about the Gopher... lacking, and it distracted me from the rest of the author's points.)
  - cryptos 12y ago
    > Engineering is all about trade-offs. What a wonderful sentence about a simple, but often forgotten truth!
  - EugeneOZ 12y ago
MichaelGG 12y ago
> I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics. I don't use Go so I don't really care about their generics or lack thereof. What I found ... odd ... is how the Go team has apparently said they can't go generics because there's no good way to implement them. Seems like a strange thing to say when many languages are happily using them.
- barosl 12y ago
  After hacking Rust, I got the feeling that generics are hard. They are so hard that a language should consider them from the beginning to fully take advantage of them. That might be the reason why the Go team says generics are hard to implement in the current Go type system. They can also choose either C++-like code generation based on templates, or external code generating tools, but both are not perfect in my opinion.
- ecnahc515 12y ago
  Implicit interfaces make generics a lot less trivial to implement. They also don't want to simply add an existing approach with bad trade-offs (see C++ templates). Likewise, adding a runtime based multi-dispatch based generic system is not much better than what we already have. Lot's of languages have generics, but they have trade-offs, so they aren't free, even if they can implement them using existing generics implementations. Picking what they're willing to sacrifice can be hard, even if it's something like slower compile times. Anything backwards compatible has to be in Go 2 or later, because generics are hard to make backwards compatible, we'll have to wait.
aikah 12y ago
it's not a "not now" approach, they are simply not going to add any new significant feature to the language (source : https://thechangelog.com/148/?utm_content=bufferf8f9d&utm_medium=twitter&utm_source=changelog&utm_campaign=buffer https://thechangelog.com/148/?utm_content=bufferf8f9d&utm_me... ) . Go will not have generics at all. People don't want generics for the sake of it, they want type safety.

howeyc 12y ago

That comment was there because my point was not about generics, but about programming language features (that are must have, the must have list of course being different for everyone) in general.

PopsiclePete 12y ago

Various core Go team members seem to have a different philosophy regarding generics. They actually don't have a united front on this. It seems Russ Cox and Rob Pike are either anti-generics or in the you-dont-really-need-them camp, but Ian Thompson and Brad Fitzpatrick have seemed very open to the idea - what they can't, however, agree on, is exactly how to implement them so that they make sense in Go. That's it. If you or anyone out there manages to produce a proposal of how they should work/look like and even a fork of Go implementing the idea, it will be taken seriously, at least by some core Go members. I have a feeling that generics are coming. And I have a feeling they'll be very Go-like - an external tool with code generation, not special syntax. Just my 2 cents.

barosl 12y ago
I think adding generics to a stable language is actually a hard thing to do. There's more than "that's it". Rust has had many major and minor changes regarding generics solely, which has broken backward compatibility each time. The Go team may find a brilliant way to accomplish this, but I think the only viable way left is, as you said, using code generation. Either C++-way, which is a special syntax but still a form of code generation, or an external tool. But neither of them is elegant, because you cannot fully utilize the convenience that the type system give. These might be the concerns that the Go team has.
- PopsiclePete 12y ago
  Maybe the "elegance" is a factor as well, but I haven't seen it mentioned. All I've seen mentioned is: a) can't change syntax b) can't take huge performance hits at run time or at compile time c) can't break backwards compatibility d) talk is cheap - provide a working implementation So far, nobody has been able to show all 4 of these requirements, so nothing has been done. But when/if someone does, I expect it to be taken very seriously.
amaranth 12y ago
This is already a thing, no? https://blog.golang.org/generate https://blog.golang.org/generate