Hacker News Reader

Comment by _vya7 | Hacker News Reader

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.

View on HN

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-exponenti...

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!

"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.

Well, it's basically duck typed, but without type values you can assign. Doesn't surprise me much.

Because he doesn't understand why we use languages like C++ in first place.

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.

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.

>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.

Hadn't heard of Gogland, thanks it sounds interesting.

https://news.ycombinator.com/item?id=13184713

They announced it ten days 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.

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.

> For example, having special syntax for returning errors vs a more generic solution like multiple return values or returning a tuple.

Even if this were true (which it isn't—Go uses multiple return values for returning errors), returning a tuple would in no way make analysis harder. Detecting whether a function returns (T, err) for some T is utterly trivial.

> having special syntax for returning errors vs a more generic solution like multiple return values or returning a tuple

Golang supports generic multiple returns (https://gobyexample.com/multiple-return-values). It's just much more commonly used for errors (instead of try catch).

>Golang doesn't have the library or tooling maturity or breadth to make it a real competitor to Java in the enterprise space IMHO.

This is why my company is being forced to scrap Go. It was good since it was easy to learn by devs, type checked, and fast. But the lack of libraries vs Java means it won't work for a lot of projects. One big issue is the lack of good database drivers.

> There's no solid IDE with Golang

Hmmm, I'm using it with WebStorm and the Golang support is pretty decent. Autocompletion, automatic help/function lookup, debugging, etc.

What are you looking for that's missing in a Golang IDE?

And it's statically compiled.

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/)

Reply on news.ycombinator.com