10 ms·

How Go was Made

104 points by beliu 11y ago

incepted 11y ago
... by ignoring the last decade in programming language design research?
- seanmcdirmid 11y ago
  Not very accurate. Rob Pike pursued a unique line of PL design research from a systems perspective that was never integrated into mainstream PL design research. There is nothing particularly wrong with this, it is what happen when communities are isolated (they develop technologies independently, see the Americas vs. Europe/Asia before Columbus). The fact that the world is much smaller now (via globalization and the internet) means that diversity necessarily decreases to converge on an identified local optimum. Go is interesting since it rejects this pressure and explores an alternative path where PL technology could go, which seems to have paid off (it has use cases and has attracted users).
  - vezzy-fnord 11y ago
    Rob Pike pursued a unique line of PL design research from a systems perspective that was never integrated into mainstream PL design research. This is correct. Pike's chief PL research interest has always been in concurrency as a first-class construct, particularly CSP.
  - f2f 11y ago
    if you want to invoke the America vs Europe rift you'll probably be interested in an earlier talk from the same conference given by Robert Griesemer on the evolution of Go: https://sourcegraph.com/blog/live/gophercon2015/123645585015 https://sourcegraph.com/blog/live/gophercon2015/123645585015 in short, Go's design is not from a unique line of programming languages, it just goes back further than you think. the argument made in the talk is that Go combines the European heritage of Algol (Pascal/Oberon) with the American one (C).
    - seanmcdirmid 11y ago
      Well, natives of America actually crossed over from Asia in multiple waves, bringing mainland technology over available at the time while there was a land bridge! So in a sense, the analogy is still quite apt.
    - rsc 11y ago
      Sourcegraph's live blog is fantastic, but they do miss some nuance. Robert prefaced this by saying twice that you really really should not read too much into this observation about America vs Europe. He just found it interesting that the two lines branching off of Algol-60 do seem to have come back together in an interesting way in Go.
      - f2f 11y ago
        point taken. i would love to see the videos of those talks.
        rsc 11y ago
        My understanding is that the videos will be out in two weeks.
      - beliu 11y ago
        Just updated the post to make sure those comments aren't meant to be taken too seriously. Sorry that did not come across in the original post!
  - tsuraan 11y ago
    I still can't figure out what Go is supposed to bring to the table that Erlang doesn't. From [0], CSP mostly differs from Actors in that multiple actors can listen on the same channel? Is that a unique line of PL research? Or was it just a success to replace Erlang's funny syntax and minimal type system with a C-inspired syntax and an embarrasingly bad type system? I guess my real question is, what does Go do better than Erlang? [0] - http://programmers.stackexchange.com/questions/206784/erlang-and-go-concurrent-programming-objective-differences-between-csp-and-acto http://programmers.stackexchange.com/questions/206784/erlang...
    - ansible 11y ago
      The differences aren't that huge, maybe the biggest ones are FP orientation, and static typing. That and Go is relatively simple. Thee tooling for Go is excellent, and the network effect of that is huge. People like to complain about the type system or genetics, but it doesn't seem to be a big problem in practice.
    - MetaCosm 11y ago
      As someone who has shipped both Erlang and Go in production, I feel I can somewhat answer this. Teams. Go does "teams" better. Shipping an Erlang app to production was simultaneously one of the happiest and most depressing points in my career. Happiest because it did exactly what we intended with minimal code and it was done early and under budget (yey!). The initial group liked Erlang, already knew Erlang and simply were able to bang it out -- delightful! Depressing because of everything that happened after... trying to teach DevOps crew was a nightmare, they HATED us -- all that introspection you can get on an Erlang system only makes sense after lots of experience. Trying to hire people who already knew Erlang was borderline impossible. Worse still, hiring people who didn't know Erlang and trying to train them up was swimming upstream in multiple ways -- it just didn't work. Erlang is really a bit of its own thing -- and if you are absolutely new to it, very hard to get over the hump... it is a weird pragmatic FP actor system and lacks any sense of purity or type niftyness. ... For initial development, Go was less elegant than Erlang, but due to simplicity and really solid tooling probably slightly more productive, but not so much that I would favor it over Erlang. But the magic happened when we involved other people. Handing off to DevOps was a DREAM... it was just a binary that logged stuff. They didn't need to know anything about what was in the black box. Hiring people is already relatively easy for Go, and training up developers in it is a AMAZING. You can hire basically any competent developer and a week later you have a competent Go developer... 50 page spec and dead simple language works wonders. No debates about code formatting, builds static binaries in seconds, super-easy to experiment with from minute one (versus getting your head around OTP). I consider myself a programming language geek, I program in dozens and dozens of languages, and love building my own little DSLs. Go is -- breathtakingly boring as a language, "exceptionally unexceptional". Honestly, it isn't much fun at all to program in, it is a bit of a grind. However, Go as a tool (when the language isn't the point, the product is, your customers are) is amazing... it is viciously focused on getting things done on teams, and so far, it has been an incredible asset to our team. I still follow and toy with Elixir in hopes that it will hit critical mass, but wasn't willing to bet my livelihood on it as a founder.
deleted 11y ago
[deleted]
jaytaylor 11y ago
The article indirectly raised a few questions for me: Why is there a massive skew favoring Googlers having their proposals implemented compared to plebes? Did the stats change after rob's talk in 2012?
- droopybuns 11y ago
  The skeptic in me points at android and deduces that the whole focus of Google open source is skewing ecosystems towards google revenue and or hiring models.
  - howeman 11y ago
    I don't understand this. How is enabling Go to run on android skewing the ecosystem? You'd rather them not allow it?
    - droopybuns 11y ago
      Sorry, I see why that was unclear. Android is a different example of the behavior OP was observing: Why is there a massive skew favoring Googlers having their proposals implemented compared to plebes? The AOSP acceptance decisions are made by Google employees. You are free to fork android, but Google favors features that are aligned with their objectives for the platform. See this thread for a tangible example: https://news.ycombinator.com/item?id=8803118 https://news.ycombinator.com/item?id=8803118
  - rsc 11y ago
    The focus of Go's open source project is making a language that works well for the kind of networked software Google and many other companies write, roughly "cloud software". I am not sure what ecosystem that would skew toward Google revenue: maybe cloud providers, but Go works just as well on Amazon and Azure and Heroku as it does on Google's products. I am not sure what "hiring models" means, but I've literally never thought about anything related to the hiring process while working on Go. For more about Go and open source, see my opening gophercon keynote, at blog.golang.org/open-source.
gull 11y ago
Although Go is more popular than ever, I'm not sure the following observations are good signs. Something about them makes me uncomfortable. "The decision process was consensus driven." "The first Go program was the prime sieve." "In July 2008, the project became more serious."
- rsc 11y ago
  Can I ask why those make you uncomfortable?
  - gull 11y ago
    Good question. Design by consensus generally produces inferior results. The first version of the most noteworthy innovations are often the result of a single person's effort. But it's also evident big projects are the results of teams. You can't produce something big without a team. So what makes me uncomfortable is that I don't see one of the inventors of Go having produced a rough version one before pulling other people in (but to be fair, I simply don't know). I'm more suspicious about the first Go program. Was computing a prime sieve the number one problem the Go creators had? Doubtful. When C was being written, the authors were also writing an application they deeply needed: UNIX. Finally, the thought of making something "serious" spoils the general hack flavor of innovative solutions. It's like a beacon that ideas are about to start being policed, which sounds like the opposite effect consensus intends to produce. It may be a good idea to keep a project non-serious as long as possible instead of optimizing it prematurely.
    - Artemis2 11y ago
      > I don't see one of the inventors of Go having produced a rough version one before pulling other people in Well, Ken Thompson did create B...
      - pjmlp 11y ago
        Actually, he adapted BCPL by changing a bit the syntax and taking a few things out to fit into the PDP, but even the manuals were almost a copy from the BCPL ones. https://vimeo.com/132192250 https://vimeo.com/132192250
gull 11y ago
A separate issue - I never know exactly what people mean when they say this: "Diverse teams are more innovative and adaptable than monocultures."
- seanmcdirmid 11y ago
  Just that groups of different people with different thinking styles are able to come up with solutions to problems faster than a team of people who think alike or are beaten into group think by a strong central authority. It really follows the pattern of biological diversity in ecosystems: a diverse ecosystem is able to thrive and overcome troubles more than a non-diverse one, which is actually quite fragile.
  - ageek123 11y ago
    But natural ecosystems have a very stringent natural selection operating, so you always end up with diversity that represents an objective improvement, something that isn't guaranteed when diversity is driven by a company's philosophical notion of justice.
    - seanmcdirmid 11y ago
      Diversity to improve performance has little to do with justice, though past injustices have definitely led to less actual diversity today.
    - not_with_retard 11y ago
      > so you always end up with diversity that represents an objective improvement Not at all how it functions.
  - gumpton456 11y ago
    But a 'diverse' team is code for a team with both black and white people, men and women, straight and gay, etc. So when you say that 'groups of different people with different thinking styles' you are implying that, for example, black people think differently from white people for the sole reason that they are black and other people are white. Or in other words, that if you get a random black person off the street you can assume his views will be different from a white person's? Isn't that kind of grouping and assumption exactly what we don't want to promote? I can't reconcile this in my mind. Anonymous because I don't want to be shamed as a racist when I'm not, but a genuine question.
nickpsecurity 11y ago
Start with an existing language (Brand X). Reimplement it almost identically with modern-looking syntax. Improve and worsen it with some change. Give it a new name. Apparently a method that works: http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/ In all seriousness, though, they could've just independently rediscovered a lot of wise design decisions. Strange if they'd never seen this one studying programming language history, though. I'm with the author wishing they applied the innovations that have happened in recent decades or even new ones. Julia is an example of an imperative one that tries to do that.
- mseepgood 11y ago
  > Strange if they'd never seen this one studying programming language history Read this summary of Robert Griesemer's talk (The Evolution of Go) then you don't have to speculate: https://sourcegraph.com/blog/live/gophercon2015/123645585015 https://sourcegraph.com/blog/live/gophercon2015/123645585015
  - nickpsecurity 11y ago
    Thanks for the talk as it was interesting! A friend who pushes Go on other forums talked about how it reminded him of programming in his favorite, Wirth-style languages. Interesting that re-creating that experience was an explicit design goal with them drawing on good features of Wirth languages, ALGOL60 (not ALGOL68), and others. The ALGOL60 quote was similarly impressive: "Hoare said of it, 'Here is a language so far ahead of its time, that it was not only an improvement on its predecessors, but also nearly all its successors.'" Quite an achievement. It was had by using only experienced language designers on the committee. Modern committee-driven actions could learn from this technique of using people with brains and experience. One of their smartest moves was how they marketed it. Many nice language designs happen but don't get any traction. Their design choices, tooling efforts, and big company support have been much better than the Java rollout and many minor attempts. My hope for the language is that it replaces the use of C# and Java in as many places as possible so people don't have to learn all that mess in maintenance phase. The simpler language should make for nice legacy code work, I think. Bookmarking the article.
AdieuToLogic 11y ago
> Go began with Robert Griesemer, Rob Pike, and Ken Thompson. “What should a modern programming language look like” (the story goes as they were waiting for some C++ to compile). Cute. Nice to keep a dig[1] going. Since that horse has been kicked quite a few times over the years, how about those in the Go community address these language criticisms: http://yager.io/programming/go.html http://yager.io/programming/go.html For specific examples from the aforementioned link: The "correct" way to build generic data structures in Go is to cast things to the top type and then put them in the data structure. This is how Java used to work, circa 2004. And: Go has the null pointer (nil). I consider it a shame whenever a new language, tabula rasa, chooses to re-implement this unnecessary bug-inducing feature. Of which the latter has been regretted by its inventor[2] for years. 1 - "[C++] certainly has its good points. But by and large I think it's a bad language." (source: https://en.wikiquote.org/wiki/Ken_Thompson https://en.wikiquote.org/wiki/Ken_Thompson) 2 - http://www.wisdomandwonder.com/link/2015/tony-hoare-sorry-for-inventing-the-null-pointer http://www.wisdomandwonder.com/link/2015/tony-hoare-sorry-fo...
- pcwalton 11y ago
  Here, I'll address one of them: "It is an extremely common occurrence for a programmer to accidentally forget to account for the possibility that a pointer may be null, potentially leading to (at best) crashes and (at worst) exploitable vulnerabilities." Null pointers won't result in exploitable vulnerabilities in Go (not counting straightforward DoS-by-causing-the-program-to-panic). They might, in very rare cases, result in something exploitable in C or C++, because dereference of null is undefined behavior and the compiler is free to optimize accordingly. But in Golang the language semantics require the runtime to panic on nil dereference, so that won't result in something like RCE as it technically could in C or C++ (but isn't likely to).
  - AdieuToLogic 11y ago
    > But in Golang the language semantics require the runtime to panic on nil dereference, so that won't result in something like RCE as it technically could in C or C++ (but isn't likely to). While you thoughtfully address the concerns Mr. Yager presents regarding the potential result of using a null pointer in Go, IMHO the more relevant fact is that Mr. Hoare identified in his own words a mistake he made _fifty years ago_ (1965) by introducing "null." The fact that Mr. Gerrand stated in the submitted article: “What should a modern programming language look like” Begs the questions: Why is this mistake oft addressed in _other_ languages repeated in Go? What are the benefits of _intentionally_ introducing this boundary condition into the language? Put bluntly, there is no benefit to dragging 0x0 forward in "a modern programming language." The lack of an answer to a function/method call is trivially encoded with some form of an option[1] type. 1 - https://en.wikipedia.org/wiki/Option_type https://en.wikipedia.org/wiki/Option_type
iopq 11y ago
Go was made in China over 2500 years ago at which point it was called yì (弈). Then some guy had to name his programming language Go and make "Go programming" hard to search for.
- not_with_retard 11y ago
  That's why you search for "Golang" instead.
- aleksi 11y ago
  Search for "golang".
  - Artemis2 11y ago
    What if you want to search algorithms related to the game?
    - kid0m4n 11y ago
      LMGTFY "go game algorithm"
    - Lrigikithumer 11y ago
      It's also called baduk and weiqi, both should give good results
  - iopq 11y ago
    I'm searching for techniques to make my Go bot stronger, not for the language
    - ticviking 11y ago
      I've found the baduk is the new preffered search term for the game.
      - toufka 11y ago
amelius 11y ago
I have a question about the design of the garbage collector of Go. Does it also clean up goroutines that are waiting on a "forgotten" channel? And does this apply for processes waiting for each other in a cycle?
- dsymonds 11y ago
  No, goroutines are never cleaned up until they exit. If they are blocked on a channel that no-one else references then they'll be blocked forever.

How Go was Made

104 points by beliu 11y ago

incepted 11y ago

... by ignoring the last decade in programming language design research?

seanmcdirmid 11y ago
Not very accurate. Rob Pike pursued a unique line of PL design research from a systems perspective that was never integrated into mainstream PL design research. There is nothing particularly wrong with this, it is what happen when communities are isolated (they develop technologies independently, see the Americas vs. Europe/Asia before Columbus). The fact that the world is much smaller now (via globalization and the internet) means that diversity necessarily decreases to converge on an identified local optimum. Go is interesting since it rejects this pressure and explores an alternative path where PL technology could go, which seems to have paid off (it has use cases and has attracted users).
- vezzy-fnord 11y ago
  Rob Pike pursued a unique line of PL design research from a systems perspective that was never integrated into mainstream PL design research. This is correct. Pike's chief PL research interest has always been in concurrency as a first-class construct, particularly CSP.
- f2f 11y ago
  if you want to invoke the America vs Europe rift you'll probably be interested in an earlier talk from the same conference given by Robert Griesemer on the evolution of Go: https://sourcegraph.com/blog/live/gophercon2015/123645585015 https://sourcegraph.com/blog/live/gophercon2015/123645585015 in short, Go's design is not from a unique line of programming languages, it just goes back further than you think. the argument made in the talk is that Go combines the European heritage of Algol (Pascal/Oberon) with the American one (C).
  - seanmcdirmid 11y ago
    Well, natives of America actually crossed over from Asia in multiple waves, bringing mainland technology over available at the time while there was a land bridge! So in a sense, the analogy is still quite apt.
  - rsc 11y ago
    Sourcegraph's live blog is fantastic, but they do miss some nuance. Robert prefaced this by saying twice that you really really should not read too much into this observation about America vs Europe. He just found it interesting that the two lines branching off of Algol-60 do seem to have come back together in an interesting way in Go.
    - f2f 11y ago
      point taken. i would love to see the videos of those talks.
      - rsc 11y ago
        My understanding is that the videos will be out in two weeks.
    - beliu 11y ago
      Just updated the post to make sure those comments aren't meant to be taken too seriously. Sorry that did not come across in the original post!
- tsuraan 11y ago
  I still can't figure out what Go is supposed to bring to the table that Erlang doesn't. From [0], CSP mostly differs from Actors in that multiple actors can listen on the same channel? Is that a unique line of PL research? Or was it just a success to replace Erlang's funny syntax and minimal type system with a C-inspired syntax and an embarrasingly bad type system? I guess my real question is, what does Go do better than Erlang? [0] - http://programmers.stackexchange.com/questions/206784/erlang-and-go-concurrent-programming-objective-differences-between-csp-and-acto http://programmers.stackexchange.com/questions/206784/erlang...
  - ansible 11y ago
    The differences aren't that huge, maybe the biggest ones are FP orientation, and static typing. That and Go is relatively simple. Thee tooling for Go is excellent, and the network effect of that is huge. People like to complain about the type system or genetics, but it doesn't seem to be a big problem in practice.
  - MetaCosm 11y ago
    As someone who has shipped both Erlang and Go in production, I feel I can somewhat answer this. Teams. Go does "teams" better. Shipping an Erlang app to production was simultaneously one of the happiest and most depressing points in my career. Happiest because it did exactly what we intended with minimal code and it was done early and under budget (yey!). The initial group liked Erlang, already knew Erlang and simply were able to bang it out -- delightful! Depressing because of everything that happened after... trying to teach DevOps crew was a nightmare, they HATED us -- all that introspection you can get on an Erlang system only makes sense after lots of experience. Trying to hire people who already knew Erlang was borderline impossible. Worse still, hiring people who didn't know Erlang and trying to train them up was swimming upstream in multiple ways -- it just didn't work. Erlang is really a bit of its own thing -- and if you are absolutely new to it, very hard to get over the hump... it is a weird pragmatic FP actor system and lacks any sense of purity or type niftyness. ... For initial development, Go was less elegant than Erlang, but due to simplicity and really solid tooling probably slightly more productive, but not so much that I would favor it over Erlang. But the magic happened when we involved other people. Handing off to DevOps was a DREAM... it was just a binary that logged stuff. They didn't need to know anything about what was in the black box. Hiring people is already relatively easy for Go, and training up developers in it is a AMAZING. You can hire basically any competent developer and a week later you have a competent Go developer... 50 page spec and dead simple language works wonders. No debates about code formatting, builds static binaries in seconds, super-easy to experiment with from minute one (versus getting your head around OTP). I consider myself a programming language geek, I program in dozens and dozens of languages, and love building my own little DSLs. Go is -- breathtakingly boring as a language, "exceptionally unexceptional". Honestly, it isn't much fun at all to program in, it is a bit of a grind. However, Go as a tool (when the language isn't the point, the product is, your customers are) is amazing... it is viciously focused on getting things done on teams, and so far, it has been an incredible asset to our team. I still follow and toy with Elixir in hopes that it will hit critical mass, but wasn't willing to bet my livelihood on it as a founder.

deleted 11y ago

[deleted]

jaytaylor 11y ago

The article indirectly raised a few questions for me: Why is there a massive skew favoring Googlers having their proposals implemented compared to plebes? Did the stats change after rob's talk in 2012?

droopybuns 11y ago
The skeptic in me points at android and deduces that the whole focus of Google open source is skewing ecosystems towards google revenue and or hiring models.
- howeman 11y ago
  I don't understand this. How is enabling Go to run on android skewing the ecosystem? You'd rather them not allow it?
  - droopybuns 11y ago
    Sorry, I see why that was unclear. Android is a different example of the behavior OP was observing: Why is there a massive skew favoring Googlers having their proposals implemented compared to plebes? The AOSP acceptance decisions are made by Google employees. You are free to fork android, but Google favors features that are aligned with their objectives for the platform. See this thread for a tangible example: https://news.ycombinator.com/item?id=8803118 https://news.ycombinator.com/item?id=8803118
- rsc 11y ago
  The focus of Go's open source project is making a language that works well for the kind of networked software Google and many other companies write, roughly "cloud software". I am not sure what ecosystem that would skew toward Google revenue: maybe cloud providers, but Go works just as well on Amazon and Azure and Heroku as it does on Google's products. I am not sure what "hiring models" means, but I've literally never thought about anything related to the hiring process while working on Go. For more about Go and open source, see my opening gophercon keynote, at blog.golang.org/open-source.

gull 11y ago

Although Go is more popular than ever, I'm not sure the following observations are good signs. Something about them makes me uncomfortable. "The decision process was consensus driven." "The first Go program was the prime sieve." "In July 2008, the project became more serious."

rsc 11y ago
Can I ask why those make you uncomfortable?
- gull 11y ago
  Good question. Design by consensus generally produces inferior results. The first version of the most noteworthy innovations are often the result of a single person's effort. But it's also evident big projects are the results of teams. You can't produce something big without a team. So what makes me uncomfortable is that I don't see one of the inventors of Go having produced a rough version one before pulling other people in (but to be fair, I simply don't know). I'm more suspicious about the first Go program. Was computing a prime sieve the number one problem the Go creators had? Doubtful. When C was being written, the authors were also writing an application they deeply needed: UNIX. Finally, the thought of making something "serious" spoils the general hack flavor of innovative solutions. It's like a beacon that ideas are about to start being policed, which sounds like the opposite effect consensus intends to produce. It may be a good idea to keep a project non-serious as long as possible instead of optimizing it prematurely.
  - Artemis2 11y ago
    > I don't see one of the inventors of Go having produced a rough version one before pulling other people in Well, Ken Thompson did create B...
    - pjmlp 11y ago
      Actually, he adapted BCPL by changing a bit the syntax and taking a few things out to fit into the PDP, but even the manuals were almost a copy from the BCPL ones. https://vimeo.com/132192250 https://vimeo.com/132192250

gull 11y ago

A separate issue - I never know exactly what people mean when they say this: "Diverse teams are more innovative and adaptable than monocultures."

seanmcdirmid 11y ago
Just that groups of different people with different thinking styles are able to come up with solutions to problems faster than a team of people who think alike or are beaten into group think by a strong central authority. It really follows the pattern of biological diversity in ecosystems: a diverse ecosystem is able to thrive and overcome troubles more than a non-diverse one, which is actually quite fragile.
- ageek123 11y ago
  But natural ecosystems have a very stringent natural selection operating, so you always end up with diversity that represents an objective improvement, something that isn't guaranteed when diversity is driven by a company's philosophical notion of justice.
  - seanmcdirmid 11y ago
    Diversity to improve performance has little to do with justice, though past injustices have definitely led to less actual diversity today.
  - not_with_retard 11y ago
    > so you always end up with diversity that represents an objective improvement Not at all how it functions.
- gumpton456 11y ago
  But a 'diverse' team is code for a team with both black and white people, men and women, straight and gay, etc. So when you say that 'groups of different people with different thinking styles' you are implying that, for example, black people think differently from white people for the sole reason that they are black and other people are white. Or in other words, that if you get a random black person off the street you can assume his views will be different from a white person's? Isn't that kind of grouping and assumption exactly what we don't want to promote? I can't reconcile this in my mind. Anonymous because I don't want to be shamed as a racist when I'm not, but a genuine question.

nickpsecurity 11y ago

Start with an existing language (Brand X). Reimplement it almost identically with modern-looking syntax. Improve and worsen it with some change. Give it a new name. Apparently a method that works: http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/ In all seriousness, though, they could've just independently rediscovered a lot of wise design decisions. Strange if they'd never seen this one studying programming language history, though. I'm with the author wishing they applied the innovations that have happened in recent decades or even new ones. Julia is an example of an imperative one that tries to do that.

mseepgood 11y ago
> Strange if they'd never seen this one studying programming language history Read this summary of Robert Griesemer's talk (The Evolution of Go) then you don't have to speculate: https://sourcegraph.com/blog/live/gophercon2015/123645585015 https://sourcegraph.com/blog/live/gophercon2015/123645585015
- nickpsecurity 11y ago
  Thanks for the talk as it was interesting! A friend who pushes Go on other forums talked about how it reminded him of programming in his favorite, Wirth-style languages. Interesting that re-creating that experience was an explicit design goal with them drawing on good features of Wirth languages, ALGOL60 (not ALGOL68), and others. The ALGOL60 quote was similarly impressive: "Hoare said of it, 'Here is a language so far ahead of its time, that it was not only an improvement on its predecessors, but also nearly all its successors.'" Quite an achievement. It was had by using only experienced language designers on the committee. Modern committee-driven actions could learn from this technique of using people with brains and experience. One of their smartest moves was how they marketed it. Many nice language designs happen but don't get any traction. Their design choices, tooling efforts, and big company support have been much better than the Java rollout and many minor attempts. My hope for the language is that it replaces the use of C# and Java in as many places as possible so people don't have to learn all that mess in maintenance phase. The simpler language should make for nice legacy code work, I think. Bookmarking the article.

AdieuToLogic 11y ago

> Go began with Robert Griesemer, Rob Pike, and Ken Thompson. “What should a modern programming language look like” (the story goes as they were waiting for some C++ to compile). Cute. Nice to keep a dig[1] going. Since that horse has been kicked quite a few times over the years, how about those in the Go community address these language criticisms: http://yager.io/programming/go.html http://yager.io/programming/go.html For specific examples from the aforementioned link: The "correct" way to build generic data structures in Go is to cast things to the top type and then put them in the data structure. This is how Java used to work, circa 2004. And: Go has the null pointer (nil). I consider it a shame whenever a new language, tabula rasa, chooses to re-implement this unnecessary bug-inducing feature. Of which the latter has been regretted by its inventor[2] for years. 1 - "[C++] certainly has its good points. But by and large I think it's a bad language." (source: https://en.wikiquote.org/wiki/Ken_Thompson https://en.wikiquote.org/wiki/Ken_Thompson) 2 - http://www.wisdomandwonder.com/link/2015/tony-hoare-sorry-for-inventing-the-null-pointer http://www.wisdomandwonder.com/link/2015/tony-hoare-sorry-fo...

pcwalton 11y ago
Here, I'll address one of them: "It is an extremely common occurrence for a programmer to accidentally forget to account for the possibility that a pointer may be null, potentially leading to (at best) crashes and (at worst) exploitable vulnerabilities." Null pointers won't result in exploitable vulnerabilities in Go (not counting straightforward DoS-by-causing-the-program-to-panic). They might, in very rare cases, result in something exploitable in C or C++, because dereference of null is undefined behavior and the compiler is free to optimize accordingly. But in Golang the language semantics require the runtime to panic on nil dereference, so that won't result in something like RCE as it technically could in C or C++ (but isn't likely to).
- AdieuToLogic 11y ago
  > But in Golang the language semantics require the runtime to panic on nil dereference, so that won't result in something like RCE as it technically could in C or C++ (but isn't likely to). While you thoughtfully address the concerns Mr. Yager presents regarding the potential result of using a null pointer in Go, IMHO the more relevant fact is that Mr. Hoare identified in his own words a mistake he made _fifty years ago_ (1965) by introducing "null." The fact that Mr. Gerrand stated in the submitted article: “What should a modern programming language look like” Begs the questions: Why is this mistake oft addressed in _other_ languages repeated in Go? What are the benefits of _intentionally_ introducing this boundary condition into the language? Put bluntly, there is no benefit to dragging 0x0 forward in "a modern programming language." The lack of an answer to a function/method call is trivially encoded with some form of an option[1] type. 1 - https://en.wikipedia.org/wiki/Option_type https://en.wikipedia.org/wiki/Option_type

iopq 11y ago

Go was made in China over 2500 years ago at which point it was called yì (弈). Then some guy had to name his programming language Go and make "Go programming" hard to search for.

not_with_retard 11y ago
That's why you search for "Golang" instead.
aleksi 11y ago
Search for "golang".
- Artemis2 11y ago
  What if you want to search algorithms related to the game?
  - kid0m4n 11y ago
    LMGTFY "go game algorithm"
  - Lrigikithumer 11y ago
    It's also called baduk and weiqi, both should give good results
- iopq 11y ago
  I'm searching for techniques to make my Go bot stronger, not for the language
  - ticviking 11y ago
    I've found the baduk is the new preffered search term for the game.
    - toufka 11y ago

amelius 11y ago

I have a question about the design of the garbage collector of Go. Does it also clean up goroutines that are waiting on a "forgotten" channel? And does this apply for processes waiting for each other in a cycle?

dsymonds 11y ago
No, goroutines are never cleaned up until they exit. If they are blocked on a channel that no-one else references then they'll be blocked forever.