6 ms·

My "aha" moment when trying to understand channels in Go was when I realized that everything about how this feature is designed comes from their answer to the q

by _vya7 10y ago

My "aha" moment when trying to understand channels in Go was when I realized that everything about how this feature is designed comes from their answer to the question "how could we 'fix' select() in C?". In fact, pretty much every feature in Go is designed to fix some perceived flaw in C, and that's the entire philosophy behind Go. They aren't interested in language theory, or in innovating or solving problems outside of C. They were just trying to write C 2.0. Not that that's a problem, it's just, it threw me off. When it came out, I fully expected Go to be a new competitor to Java or even Python, not to C.

tapirl 10y ago
yes, Golang is really can be viewed as c plus. But it also absorbs many features from other languages. Personally, I think Golang is a Java killer. I never write one line Java code since I became familiar with Go. The main reason is it is painful to maintain a Java web project, slow compiling, slow startup, large memory consuming, so many concepts (of all sorts of frameworks) to learn, etc.
- seabrookmx 10y ago
  While I'm sure many people will agree with you, I (respectfully) don't for a couple reasons.. Golang doesn't have the library or tooling maturity or breadth to make it a real competitor to Java in the enterprise space IMHO. Golang lacks a package manager (and "go get" is not a real substitute when it completely shirks semantic versioning). There's no solid IDE with Golang support. Most of the web server and database tools are very low level, and while they provide the necessary features for a smaller project or if you're writing exclusively microservices, they leave a lot be desired if you're writing a run of the mill web app, or an enterprise system for batch processing (orders, transactions, email etc). For smaller projects, most languages are better than Java for the reasons you mention (including dynamic languages like Python for example). Golang is a novel language and it definitely has a niche, but I find it right inbetween a language like Python and a "heavy" language like C#/Java.
  - omginternets 10y ago
    Obviously Go isn't going to replace every existing piece of Java software. That's a very strange takeaway from the parent comment. The point is rather that Go occupies the same niche as Java, and does so arguably better. As such, "Java killer" means new software projects are going to increasingly favor Go over Java.
  - dispose13432 10y ago
    >There's no solid IDE with Golang support Honestly, there wasn't a solid IDE for Java for a while, and the makers of IntelliJ are working on Gogland. However, IMHO, the only thing I miss in an IDE for Go is inline debugging (but in truth, I never used IntelliJ's refactoring tools, so I could have missed out on all the benefits of a powerful IDE). Except for that, VSCode and nvi are all I (personally) need.
    - justinclift 10y ago
      Hadn't heard of Gogland, thanks it sounds interesting.
      - dispose13432 10y ago
        https://news.ycombinator.com/item?id=13184713 https://news.ycombinator.com/item?id=13184713 They announced it ten days ago.
  - wcummings 10y ago
    I'm not really a go person. I might go as far as saying I'm a go hater. But I feel compelled to defend it in this case. Golang is a deliberately simple language that lends itself well to inspection & tooling. For example, having special syntax for returning errors vs a more generic solution like multiple return values or returning a tuple. It feels awkward but makes detecting unhandled errors very simple. Seems like there's decent enough tools + emacs/vim wrappers to me. In my mind this is one of the primary merits of go.
    - 10y ago
- dispose13432 10y ago
  And it's statically compiled.
lobster_johnson 10y ago
Go's authors didn't really set out to fix C, they wanted to fix C++ [1]. To say that channels is the answer to fixing select() ignores the fact that Go doesn't support non-blocking I/O at all. select{} only works on channels, and I/O operations are always blocking. It seems like a bit of a missed opportunity to not let file descriptors and other data structures support select{}, much like they decided not to let "range" work for anything except built-ins. To wait on multiple sockets, you have to start a goroutine per socket and communicate via channels, even if all you want to do is service one event at a time. That's fine, it's Go's way. What I'm less happy about is that because of this design, you can't ever interrupt a blocking operation — reads in particular — other than by closing the file descriptor. That's why SetReadDeadline has to exist, to at least let you set a timeout. [1] https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
- duaneb 10y ago
  Fix for some value of fix. Go's lack of generics make the data structure offerings pitiful. Just look at heap: it's worse than c. There is a role for a language like that, but calling it fixing c++ ignores 90% of the reasons people use c++ in the first place. In fact, id say that go reminds me most of the version of c++ that operated as a preprocessor. It's almost exactly the same template implementation!
  - lobster_johnson 10y ago
    "Fix" in quotes, really -- I don't think the Go team ever pretended they were building a replacement, although they are certainly replacing C++ for their own work. That said, if you read Rob Pike's history of Go (previous link), they were mighty surprised to discover that Go didn't really entice C++ programmers at all; the crowd that Go appealed to were Ruby and Python developers who wanted a faster language that was still expressive and fast to compile.
    - duaneb 10y ago
      Well, it's basically duck typed, but without type values you can assign. Doesn't surprise me much.
afrancis 10y ago
I can't recall anywhere in the literature that refers to being inspired by UNIX's select(). Golang's select comes from the Bell family of languages such as select in Newsqueak or alt in Limbo. In turn, channels in these languages were inspired by CSP. Here is a link to Russ Cox's "Bell Labs and CSP Threads" (https://swtch.com/~rsc/thread/ https://swtch.com/~rsc/thread/)

by _vya7 10y ago

tapirl 10y ago

yes, Golang is really can be viewed as c plus. But it also absorbs many features from other languages. Personally, I think Golang is a Java killer. I never write one line Java code since I became familiar with Go. The main reason is it is painful to maintain a Java web project, slow compiling, slow startup, large memory consuming, so many concepts (of all sorts of frameworks) to learn, etc.

seabrookmx 10y ago
While I'm sure many people will agree with you, I (respectfully) don't for a couple reasons.. Golang doesn't have the library or tooling maturity or breadth to make it a real competitor to Java in the enterprise space IMHO. Golang lacks a package manager (and "go get" is not a real substitute when it completely shirks semantic versioning). There's no solid IDE with Golang support. Most of the web server and database tools are very low level, and while they provide the necessary features for a smaller project or if you're writing exclusively microservices, they leave a lot be desired if you're writing a run of the mill web app, or an enterprise system for batch processing (orders, transactions, email etc). For smaller projects, most languages are better than Java for the reasons you mention (including dynamic languages like Python for example). Golang is a novel language and it definitely has a niche, but I find it right inbetween a language like Python and a "heavy" language like C#/Java.
- omginternets 10y ago
  Obviously Go isn't going to replace every existing piece of Java software. That's a very strange takeaway from the parent comment. The point is rather that Go occupies the same niche as Java, and does so arguably better. As such, "Java killer" means new software projects are going to increasingly favor Go over Java.
- dispose13432 10y ago
  >There's no solid IDE with Golang support Honestly, there wasn't a solid IDE for Java for a while, and the makers of IntelliJ are working on Gogland. However, IMHO, the only thing I miss in an IDE for Go is inline debugging (but in truth, I never used IntelliJ's refactoring tools, so I could have missed out on all the benefits of a powerful IDE). Except for that, VSCode and nvi are all I (personally) need.
  - justinclift 10y ago
    Hadn't heard of Gogland, thanks it sounds interesting.
    - dispose13432 10y ago
      https://news.ycombinator.com/item?id=13184713 https://news.ycombinator.com/item?id=13184713 They announced it ten days ago.
- wcummings 10y ago
  I'm not really a go person. I might go as far as saying I'm a go hater. But I feel compelled to defend it in this case. Golang is a deliberately simple language that lends itself well to inspection & tooling. For example, having special syntax for returning errors vs a more generic solution like multiple return values or returning a tuple. It feels awkward but makes detecting unhandled errors very simple. Seems like there's decent enough tools + emacs/vim wrappers to me. In my mind this is one of the primary merits of go.
  - 10y ago
dispose13432 10y ago
And it's statically compiled.

lobster_johnson 10y ago

Go's authors didn't really set out to fix C, they wanted to fix C++ [1]. To say that channels is the answer to fixing select() ignores the fact that Go doesn't support non-blocking I/O at all. select{} only works on channels, and I/O operations are always blocking. It seems like a bit of a missed opportunity to not let file descriptors and other data structures support select{}, much like they decided not to let "range" work for anything except built-ins. To wait on multiple sockets, you have to start a goroutine per socket and communicate via channels, even if all you want to do is service one event at a time. That's fine, it's Go's way. What I'm less happy about is that because of this design, you can't ever interrupt a blocking operation — reads in particular — other than by closing the file descriptor. That's why SetReadDeadline has to exist, to at least let you set a timeout. [1] https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

duaneb 10y ago
Fix for some value of fix. Go's lack of generics make the data structure offerings pitiful. Just look at heap: it's worse than c. There is a role for a language like that, but calling it fixing c++ ignores 90% of the reasons people use c++ in the first place. In fact, id say that go reminds me most of the version of c++ that operated as a preprocessor. It's almost exactly the same template implementation!
- lobster_johnson 10y ago
  "Fix" in quotes, really -- I don't think the Go team ever pretended they were building a replacement, although they are certainly replacing C++ for their own work. That said, if you read Rob Pike's history of Go (previous link), they were mighty surprised to discover that Go didn't really entice C++ programmers at all; the crowd that Go appealed to were Ruby and Python developers who wanted a faster language that was still expressive and fast to compile.
  - duaneb 10y ago
    Well, it's basically duck typed, but without type values you can assign. Doesn't surprise me much.

afrancis 10y ago

I can't recall anywhere in the literature that refers to being inspired by UNIX's select(). Golang's select comes from the Bell family of languages such as select in Newsqueak or alt in Limbo. In turn, channels in these languages were inspired by CSP. Here is a link to Russ Cox's "Bell Labs and CSP Threads" (https://swtch.com/~rsc/thread/ https://swtch.com/~rsc/thread/)