6 ms·

Why hasn't it happened to me? I've been writing Go for over 3 years, and I prefer the language stay as is. I'm more concerned about porting it to more platforms

Why hasn't it happened to me? I've been writing Go for over 3 years, and I prefer the language stay as is. I'm more concerned about porting it to more platforms. Perhaps that's a reason I'm motivated to desire less language changes.

omarforgotpwd 10y ago
I'm curious, what platform do you want to go to support that it doesn't already? Platform support seems pretty good already, at least for my needs.
- shurcooL 10y ago
  A really big and popular platform where Go isn't officially supported yet is the web (browser). I'm trying to push that direction as much as I can by contributing to GopherJS [0], which is IMO our best bet until wasm [1] comes out and has adds support for GC languages [2]. I agree the rest of the platform support is absolutely fantastic. We have the big 3 desktop OSes, as well as iOS and Android already. But so much of what we do today is on the web, and I don't want to keep using JavaScript or to keep crossing the Go <-> JS boundary inconsistencies. That's not the kind of future I want to invest in. [0] https://github.com/gopherjs/gopherjs#readme https://github.com/gopherjs/gopherjs#readme [1] https://webassembly.github.io/ https://webassembly.github.io/ [2] https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/master/FutureFeat...
coldtea 10y ago
>Why hasn't it happened to me? Well, don't know about your case, but I've seen e.g. people who are religious about being DRY and dislike any kind of useless boilerplate, and others just copy paste code with wild abandon and couldn't care at all.
- eknkc 10y ago
  Also, I'm generally fine with language tradeoffs, If there is a good reason that I need to copy paste something, so be it. I'll do it. Go and Generics issue on the other hand, feels a little different to me. It is a solved problem. Go does not have an inherent show stopper for generics. It's just not there because of.. What? Stubbornness? I'm not sure. But then it irritates me to copy paste stuff.
  - shurcooL 10y ago
    > It is a solved problem. This is debatable. Is it a problem that's solved well? Is it solved in the best way possible and there could never be a better way to do generics? I think not. I think it's solved adequately, but not great. Compared to the other facilities that Go offers, generics are typically pretty messy and add significant complexity to the language, tools, parsing, reasoning, compilation times, etc. > It's just not there because of.. What? Stubbornness? I'm not sure. But then it irritates me to copy paste stuff. This statement is ill-informed. Have you seen https://github.com/golang/go/issues/15292 https://github.com/golang/go/issues/15292 and https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-...? Have you considered all the ways in which it will affect the language and the trade-offs? Once generics are added to Go, they will forever be there, together with all the disadvantages and missed opportunities, and we'll have to live with them. That's not a thing to be taken lightly. In comparison, maybe copying a little here and there isn't all that bad.
- shurcooL 10y ago
  I used to care about DRY to a _very_ great degree [0], and I still do. But I've come to realize DRY is much better to apply for high level _concepts_, ideas, and architectures, not unexported helper code. It's unhelpful to try to apply it to little snippets of code and helpers. It's much less expensive to copy a snippet that's needed and duplicate it 1-2 times before starting to worry about factoring it out. By the time it's repeated 3+ times, you'll have a much better idea how to structure it. [0] https://github.com/shurcooL/Conception#motivation https://github.com/shurcooL/Conception#motivation

omarforgotpwd 10y ago

I'm curious, what platform do you want to go to support that it doesn't already? Platform support seems pretty good already, at least for my needs.

shurcooL 10y ago
A really big and popular platform where Go isn't officially supported yet is the web (browser). I'm trying to push that direction as much as I can by contributing to GopherJS [0], which is IMO our best bet until wasm [1] comes out and has adds support for GC languages [2]. I agree the rest of the platform support is absolutely fantastic. We have the big 3 desktop OSes, as well as iOS and Android already. But so much of what we do today is on the web, and I don't want to keep using JavaScript or to keep crossing the Go <-> JS boundary inconsistencies. That's not the kind of future I want to invest in. [0] https://github.com/gopherjs/gopherjs#readme https://github.com/gopherjs/gopherjs#readme [1] https://webassembly.github.io/ https://webassembly.github.io/ [2] https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/master/FutureFeat...

coldtea 10y ago

>Why hasn't it happened to me? Well, don't know about your case, but I've seen e.g. people who are religious about being DRY and dislike any kind of useless boilerplate, and others just copy paste code with wild abandon and couldn't care at all.

eknkc 10y ago
Also, I'm generally fine with language tradeoffs, If there is a good reason that I need to copy paste something, so be it. I'll do it. Go and Generics issue on the other hand, feels a little different to me. It is a solved problem. Go does not have an inherent show stopper for generics. It's just not there because of.. What? Stubbornness? I'm not sure. But then it irritates me to copy paste stuff.
- shurcooL 10y ago
  > It is a solved problem. This is debatable. Is it a problem that's solved well? Is it solved in the best way possible and there could never be a better way to do generics? I think not. I think it's solved adequately, but not great. Compared to the other facilities that Go offers, generics are typically pretty messy and add significant complexity to the language, tools, parsing, reasoning, compilation times, etc. > It's just not there because of.. What? Stubbornness? I'm not sure. But then it irritates me to copy paste stuff. This statement is ill-informed. Have you seen https://github.com/golang/go/issues/15292 https://github.com/golang/go/issues/15292 and https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-...? Have you considered all the ways in which it will affect the language and the trade-offs? Once generics are added to Go, they will forever be there, together with all the disadvantages and missed opportunities, and we'll have to live with them. That's not a thing to be taken lightly. In comparison, maybe copying a little here and there isn't all that bad.
shurcooL 10y ago
I used to care about DRY to a _very_ great degree [0], and I still do. But I've come to realize DRY is much better to apply for high level _concepts_, ideas, and architectures, not unexported helper code. It's unhelpful to try to apply it to little snippets of code and helpers. It's much less expensive to copy a snippet that's needed and duplicate it 1-2 times before starting to worry about factoring it out. By the time it's repeated 3+ times, you'll have a much better idea how to structure it. [0] https://github.com/shurcooL/Conception#motivation https://github.com/shurcooL/Conception#motivation