6 ms·

This could be done, of course. But how likely is such an approach to succeed? It would effectively create a new language and in turn to a new ecosystem. Why not

This could be done, of course. But how likely is such an approach to succeed? It would effectively create a new language and in turn to a new ecosystem. Why not just use a different language (Rust comes to mind) then?

_ph_ 7y ago
First of all, Rust is quite a different language to Go, so I wouldn't consider it a drop-in replacement. But this also means, that those, who don't like too many features of Go might really be happier with Rust. But adding features to Go by popular demand would make it a new language and a new ecosystem. So if that is what people want, they should go ahead with it. Even if it just is an engineering prototype, which showcases features that Google should add to the Go main line.
weego 7y ago
Sure, but that's a different issue. If it doesn't gain traction then the decisions made by Google are clearly considered the best approach, at which point what relevance does the openess have?
- remus 7y ago
  > If it doesn't gain traction then the decisions made by Google are clearly considered the best approach I don't think this is necessarily true. There are a lot of fuzzy factors that go in to making a language successful and it's tricky at best to get these right, even if openGo was a better language. As a practical example, go effectively has one person who's full time job is keeping the testing infra happy. It'd take time and money to establish this in a go fork and going without it would make development of the fork much harder.
  - bonesss 7y ago
    > It'd take time and money to [develop a language] Isn't that part of the fundamental conundrum though? If your need is so great, and so common, and so beneficial to get solved then the cost of development should be less than the benefits accrued, and smart business would bring that money and time to bear on the challenge and solve it. As Google has done with the main project... Saying there isn't time enough or money enough to solve the technical challenges sounds like saying those challenges aren't important, or valuable, enough to be prioritized. Which is to say our wallets are in agreement with Googles wallet on the issue of generics in Go. The considered 'best approach' from the community isn't the best technical approach to the technical issues, it's the best balance of pragmatic solutions for produced benefit (ie ROI), that create a sustainable project/product.
- Cthulhu_ 7y ago
  What has happened in the past is that features developed in a fork make their way back to the mainline - iirc in the Java world this was a thing with the virtual machine, particularly garbage collection. If a hypothetical OpenGo can solve the generics problem in a satisfactory way then it could make its way back into Go. Well, licensing and such notwithstanding.
- jacques_chester 7y ago
  A major thesis of the article is that even if something was successful outside of the core team, they would ignore it in favour of their own ideas. Go modules is the reference case.
  - pflats 7y ago
    Go modules is exactly the reference case, but let me expand on that a smidge, because that was when this become crystal-clear to me. There's one exchange in a blog post linked from the article[1] about dep/modules that I think is illustrative of the entire issue (double >> are quotes in the article from Google/go, single > are commentary from the linked blog author): >>Although it was a successful experiment, Dep is not the right approach for the next decade of Go development. It has many very serious problems. A few: >>Dep does not support using multiple major versions of a program in a single build. This alone is a complete showstopper. Go is meant for large-scale work, and in a large-scale program different parts will inevitably need different versions of some isolated dependency. >Russ [a member of the Go team] has asserted this from day one, and has brought several examples out in evidence, but has simply not convinced the committee that it’s true. Calling it a serious problem, let alone a showstopper, is a significant overstatement. The strongest claim that can be made on this point is that it’s a matter of opinion. That, to me, is that. Go is Google's language, and Google said that for them, not supporting multiple versions of a dependency was a showstopper. The community read that and saw it as a point for debate, and the author continues to try to debate it in the article. And that's the issue! It was not a point for debate. Google was being forthright. Google was saying "from day one" it was a literal showstopper, and the community seems to have read it as a figurative showstopper. Who was right in this instance is irrelevant; if the community wants to litigate Google's decisions rather than integrate them into their tools/patches/etc., then the community will not get those things adopted into go. [1] https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html https://peter.bourgon.org/blog/2018/07/27/a-response-about-d...
    - josefx 7y ago
      > Google was saying "from day one" it was a literal showstopper, For a long time people on the C++ standards committee insisted that we need trigraphs because it had to support systems that didn't even have ASCII. We still don't have pragma once as a standard replacement for include guards because other people seem to compile on some crazy network typologies where it cannot reliably identify files. Taking every "literal showstopper" serious without questioning its merits gets you stuck with C++98 and a lot of quickly accumulating legacy cruft.
jonathanstrange 7y ago
Rust is not a suitable replacement for Go.
- cryptos 7y ago
  Why not? I consider Rust to be superior in almost all respects apart from learnability and compile times. So if these two downsides are not more relevant than the downsides of Go (in a certain context), I don't see any reason why Go could not be replaced by Rust.
  - jonathanstrange 7y ago
    Ah, the Rust fanboys who vote down comments of anyone who criticizes Rust. They are actively trolling forums and spoil Rust for the rest of us. (IMHO, similar behaviour played a big role in the relative lack of success of CommonLisp, which is another language that I really like.) So I know both languages, have chosen Go instead of Rust for a larger programming project recently, and have 30+ years of programming experience, so I feel somewhat qualified to answer the question you ask---if you meant it seriously, which I doubt. People use Go for its simplicity, good tooling, good backwards compatibility, fast and modern automatic garbage collection, extensive libraries, and fast compilation speed. Yes, Rust is hard to learn, puts a constant high cognitive load on its users even once they have learned it, is relatively fast moving - meaning code you write now will likely not be idiomatic in a few years from now -, and has slow compilation speed. It has many other strengths, as you rightly point out, but most of them will not be a reason for someone who uses Go to switch to Rust. For example, most people who use Go do not need or want to quench the last performance out of their CPU and are less obsessed with zero-cost abstractions. Many C++ programmers, on the other hand, might appreciate these features of Rust. Rust and Go are simply not languages that compete with each other. Go is a competitor to Python, VisualBasic/Xojo, and various server-side scripting languages like Ruby and PHP. Rust is a competitor to C and some uses of C++, and maybe to languages like Ada and Haskell in some safety-relevant domains that do not require a formal language specification. The OP could have just as well suggested to use Ada instead of Go. It is possible to write Ada like Pascal, making it almost as easy to use as Go, but the suggestion still doesn't make much sense.
jussij 7y ago
> It would effectively create a new language and in turn to a new ecosystem. And that new language would be Go++ (i.e. Go with generics) and what would be wrong with that? Consider how C++ started. It was nothing more than a preprocessor extension to the C language called C with classes. There is nothing stopping that Go++ turning into the Go equivalent of C++. So back to the previous OPs question, what's stopping someone from forking it?
- pjmlp 7y ago
  Because after his experience being forced to drop into BCPL from Simula, Bjarne sweared not to do it ever again. So when tasked to write his distributed network application in C at Bell Labs, his first step was to build something that would bring his Simula back, instead of bare bones C.
  - deleted 7y ago
    [deleted]

_ph_ 7y ago

First of all, Rust is quite a different language to Go, so I wouldn't consider it a drop-in replacement. But this also means, that those, who don't like too many features of Go might really be happier with Rust. But adding features to Go by popular demand would make it a new language and a new ecosystem. So if that is what people want, they should go ahead with it. Even if it just is an engineering prototype, which showcases features that Google should add to the Go main line.

weego 7y ago

Sure, but that's a different issue. If it doesn't gain traction then the decisions made by Google are clearly considered the best approach, at which point what relevance does the openess have?

remus 7y ago
> If it doesn't gain traction then the decisions made by Google are clearly considered the best approach I don't think this is necessarily true. There are a lot of fuzzy factors that go in to making a language successful and it's tricky at best to get these right, even if openGo was a better language. As a practical example, go effectively has one person who's full time job is keeping the testing infra happy. It'd take time and money to establish this in a go fork and going without it would make development of the fork much harder.
- bonesss 7y ago
  > It'd take time and money to [develop a language] Isn't that part of the fundamental conundrum though? If your need is so great, and so common, and so beneficial to get solved then the cost of development should be less than the benefits accrued, and smart business would bring that money and time to bear on the challenge and solve it. As Google has done with the main project... Saying there isn't time enough or money enough to solve the technical challenges sounds like saying those challenges aren't important, or valuable, enough to be prioritized. Which is to say our wallets are in agreement with Googles wallet on the issue of generics in Go. The considered 'best approach' from the community isn't the best technical approach to the technical issues, it's the best balance of pragmatic solutions for produced benefit (ie ROI), that create a sustainable project/product.
Cthulhu_ 7y ago
What has happened in the past is that features developed in a fork make their way back to the mainline - iirc in the Java world this was a thing with the virtual machine, particularly garbage collection. If a hypothetical OpenGo can solve the generics problem in a satisfactory way then it could make its way back into Go. Well, licensing and such notwithstanding.
jacques_chester 7y ago
A major thesis of the article is that even if something was successful outside of the core team, they would ignore it in favour of their own ideas. Go modules is the reference case.
- pflats 7y ago
  Go modules is exactly the reference case, but let me expand on that a smidge, because that was when this become crystal-clear to me. There's one exchange in a blog post linked from the article[1] about dep/modules that I think is illustrative of the entire issue (double >> are quotes in the article from Google/go, single > are commentary from the linked blog author): >>Although it was a successful experiment, Dep is not the right approach for the next decade of Go development. It has many very serious problems. A few: >>Dep does not support using multiple major versions of a program in a single build. This alone is a complete showstopper. Go is meant for large-scale work, and in a large-scale program different parts will inevitably need different versions of some isolated dependency. >Russ [a member of the Go team] has asserted this from day one, and has brought several examples out in evidence, but has simply not convinced the committee that it’s true. Calling it a serious problem, let alone a showstopper, is a significant overstatement. The strongest claim that can be made on this point is that it’s a matter of opinion. That, to me, is that. Go is Google's language, and Google said that for them, not supporting multiple versions of a dependency was a showstopper. The community read that and saw it as a point for debate, and the author continues to try to debate it in the article. And that's the issue! It was not a point for debate. Google was being forthright. Google was saying "from day one" it was a literal showstopper, and the community seems to have read it as a figurative showstopper. Who was right in this instance is irrelevant; if the community wants to litigate Google's decisions rather than integrate them into their tools/patches/etc., then the community will not get those things adopted into go. [1] https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html https://peter.bourgon.org/blog/2018/07/27/a-response-about-d...
  - josefx 7y ago
    > Google was saying "from day one" it was a literal showstopper, For a long time people on the C++ standards committee insisted that we need trigraphs because it had to support systems that didn't even have ASCII. We still don't have pragma once as a standard replacement for include guards because other people seem to compile on some crazy network typologies where it cannot reliably identify files. Taking every "literal showstopper" serious without questioning its merits gets you stuck with C++98 and a lot of quickly accumulating legacy cruft.

jonathanstrange 7y ago

Rust is not a suitable replacement for Go.

cryptos 7y ago
Why not? I consider Rust to be superior in almost all respects apart from learnability and compile times. So if these two downsides are not more relevant than the downsides of Go (in a certain context), I don't see any reason why Go could not be replaced by Rust.
- jonathanstrange 7y ago
  Ah, the Rust fanboys who vote down comments of anyone who criticizes Rust. They are actively trolling forums and spoil Rust for the rest of us. (IMHO, similar behaviour played a big role in the relative lack of success of CommonLisp, which is another language that I really like.) So I know both languages, have chosen Go instead of Rust for a larger programming project recently, and have 30+ years of programming experience, so I feel somewhat qualified to answer the question you ask---if you meant it seriously, which I doubt. People use Go for its simplicity, good tooling, good backwards compatibility, fast and modern automatic garbage collection, extensive libraries, and fast compilation speed. Yes, Rust is hard to learn, puts a constant high cognitive load on its users even once they have learned it, is relatively fast moving - meaning code you write now will likely not be idiomatic in a few years from now -, and has slow compilation speed. It has many other strengths, as you rightly point out, but most of them will not be a reason for someone who uses Go to switch to Rust. For example, most people who use Go do not need or want to quench the last performance out of their CPU and are less obsessed with zero-cost abstractions. Many C++ programmers, on the other hand, might appreciate these features of Rust. Rust and Go are simply not languages that compete with each other. Go is a competitor to Python, VisualBasic/Xojo, and various server-side scripting languages like Ruby and PHP. Rust is a competitor to C and some uses of C++, and maybe to languages like Ada and Haskell in some safety-relevant domains that do not require a formal language specification. The OP could have just as well suggested to use Ada instead of Go. It is possible to write Ada like Pascal, making it almost as easy to use as Go, but the suggestion still doesn't make much sense.

jussij 7y ago

> It would effectively create a new language and in turn to a new ecosystem. And that new language would be Go++ (i.e. Go with generics) and what would be wrong with that? Consider how C++ started. It was nothing more than a preprocessor extension to the C language called C with classes. There is nothing stopping that Go++ turning into the Go equivalent of C++. So back to the previous OPs question, what's stopping someone from forking it?

pjmlp 7y ago
Because after his experience being forced to drop into BCPL from Simula, Bjarne sweared not to do it ever again. So when tasked to write his distributed network application in C at Bell Labs, his first step was to build something that would bring his Simula back, instead of bare bones C.
- deleted 7y ago
  [deleted]