10 ms·
Channels in Golang
- _vya7 10y agoMy "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 agoyes, 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 agoWhile 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 agoObviously 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 agoHadn't heard of Gogland, thanks it sounds interesting.
- dispose13432 10y agohttps://news.ycombinator.com/item?id=13184713 https://news.ycombinator.com/item?id=13184713 They announced it ten days ago.
- wcummings 10y agoI'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 agoAnd it's statically compiled.
- lobster_johnson 10y agoGo'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 agoFix 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 agoWell, it's basically duck typed, but without type values you can assign. Doesn't surprise me much.
- afrancis 10y agoI 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/)
- ridiculous_fish 10y agoWhy are functions like cap, len, and close builtins instead of library functions? Is it because they have to be generic over channel types?
- kasey_junk 10y agoYes. Same for slices & maps. Go's generic support must be built into the language.
- hamandcheese 10y agoBecause the creators won't give us generics
- duaneb 10y ago...yet.
- dispose13432 10y agoI know it's a controversial point among users, but I think that if Generics were such a show stopper, Google would have implemented them. Go was invented for internal Google use, and then shared with the world, and Google is an engineering company. If engineers would have rebelled, higher management probably would have done something about it. ----- Although I don't understand why they keep fighting it. A simple style generics (Java style) shouldn't make code that ugly.
- unscaled 10y agoGenerics are not a show stopper, since they already exist (built-in support) for everything the language creators care about. Whether or not they are a show stopper for the users - well, that depends on your use case and preferences. Since show stoppers are a subjective thing. Objectively you could implement everything in Assembly or even Machine code, and people used to write rather complex programs this way. I personally know there are a lot of types of systems I would never implement in Go if given the choice, because it would be too bothersome, and I don't like RSI. YMMV.
- Animats 10y agoChannels in Go turned out to be less useful than expected. The original pitch was "share by communicating, not by sharing". But in practice, large amounts of data tend not to be sent over channels. It's common to send references over channels instead, which implies sharing across goroutine boundaries. Go doesn't have strict single ownership, like Rust, so you can send something to another goroutine without the sender losing access. This creates a potential race condition. (There are checkers for detecting this at run time, but it's not a compile time error, as it is in Rust). Channels are thus equivalent to a queue module coupled to a lightweight thread system. Go is garbage-collected, with a good concurrent garbage collector, so all this is memory safe. Mostly. Maps (Go's dictionary type) aren't concurrency-safe for performance reasons, and there's an known exploit involving slice descriptors.
- kibwen 10y ago> in practice, large amounts of data tend not to be sent over channels Can you cite a source for this, or is this your personal experience?
- SamReidHughes 10y agoThis is how the language works. Go doesn't have any sort of deep copying mechanism for channels to use, so if you want to send a buffer on the channel, it's on you to not reuse its slice.
- brobinson 10y agoCould you share some details about the exploit? This is the first I've heard of it. There was also this article about some of the problems with Go channels: http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/ http://www.jtolds.com/writing/2016/03/go-channels-are-bad-an...
- Animats 10y agoSearch for "go language slice race condition": [1] [1] http://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html http://blog.stalkr.net/2015/04/golang-data-races-to-break-me...
- duaneb 10y agoIf anyone has a clue why this was downvoted, please clue me in. It was on topic and indicating missing information. Edit: I really don't care how much I get downvoted, I'm going to highlight its uselessness until someone cares to justify it.
- duaneb 10y agoWe should really require commenting while downvoting unreplied comments. The community has gotten lazy.
- deleted 10y ago[deleted]
- duaneb 10y agoMostly it amuses me people would rather judge than converse. What's the point of even reading this echo chamber? I'm done with this community.
- SuperPaintMan 10y agoHey man, it's all good. For this reason anything that gets downvoted like your post gets a insta-upvote from meto try and balence it. It's stuffy in this box
- tomhoward 10y agoThe indications from the people who've replied to you are that they downvoted you for the same reason you're now upset: they didn't think you were making an effort to converse.
- deleted 10y ago[deleted]
- grzm 10y agoPerhaps the downvotes are because the comment is pretty empty. You could say that about effectively anything. It doesn't add to the discussion. If, for example, you have information indicating that generics are on the horizon or that Pike et al. have discussed the possibility of adding generics, that would be a lot more interesting and substantive.