8 ms·

What's happening in Go tip

78 points by radimm 13y ago

jzelinskie 13y ago
Does Rust have an equivalent location to get nice summaries of future development?
- newgame 13y ago
  There is 'This Week in Rust': http://cmr.github.io/blog/categories/this-week-in-rust/ http://cmr.github.io/blog/categories/this-week-in-rust/
  - dbaupp 13y ago
    That is literally just the past week; there's not really anything for future stuff (there is so much future stuff that keeping track of it all would almost be more work than just going out and implementing it ;) ) other than skimming the mailing list, the weekly meetings and sometimes the devs blogs (which normally get posted to the mailing list and /r/rust on reddit); although the significant discussions do get linked in TWiR, so I guess I kinda lied.
- gtani 13y ago
  dunno how up to date this is (last edited 3 months ago https://github.com/mozilla/rust/wiki/Note-development-roadmap https://github.com/mozilla/rust/wiki/Note-development-roadma... and release notes https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes https://github.com/mozilla/rust/wiki/Doc-detailed-release-no...
MartinMond 13y ago
Go looks like a really nice language, but then I discovered that they don't _want_ to have exceptions. Crazy. I'm sticking with Erlang, "Let It Crash" (and handle the crash) is better than "add if(err) after everything and good luck with that"
- nolok 13y ago
  > "Let It Crash" (and handle the crash) panic() and recover() does that. It's not exceptions, but it does exactly that.
  - lazyjones 13y ago
    It's the supervisor trees that are missing and cannot currently be implemented though.
    - AeroNotix 13y ago
      As a built-in language feature they are missing, but you can and some codebases do implement a kill channel for child goroutines.
    - jerf 13y ago
      As it happens, I've spent the last two days implementing supervision trees for Go, as I'm looking to port some stuff out of Erlang into Go. (There are a couple of existing libraries out there, but they are pretty weak tea, no offense to the authors in question, one of which is kind enough to label their effort with "this is my first Go code".) You can't implement Erlang-style trees without loss, and it's tricky due to some other things, but it can be done and you do get a substantial portion of the benefits, but also certainly not all. When I pop it up on github here soon, I'm planning on accompanying it by a blog post that will probably end up being longer than the entire library (including test suite and documentation) discussing all the whats and whys of how much you can and can not bring over of Erlang's approach.
    - JulianMorrison 13y ago
      Can be, easily. Your goroutine defers a function that calls recover and notifies the supervisor if it was panicking. It's exactly what Erlang does, just done slightly more manually.
    - dragonwriter 13y ago
      > It's the supervisor trees that are missing and cannot currently be implemented though. On a language level the support seems to be there, and not radically different from what Erlang offers. The pre-built libraries that make up OTP for Erlang aren't there and you have to build your own, but the underlying structure seems to be there.
StevePerkins 13y ago
I'm a professional Java developer, and thought I was fairly trendy because I've introduced Scala in my company's services tier. About a month ago I started reading HN, and discovered that I'm irrelevant because I'm still using Scala rather than Clojure. I ordered a Manning book, but before it even arrived I discovered that I'm irrelevant because I'm learning Clojure rather than Node.js. So I started a couple of personal projects based on Express. However, before I was completely comfortable with callbacks vs. promises, I discovered last week that I'm irrelevant because I'm working with Node.js rather than Go. Go has been my favorite of the bunch so far. However, I was just started to learn about goroutines and channels, when I discovered three days ago that I'm irrelevant because I'm using Golang rather than Rust. I like this board, but it should come with a warning label! I haven't been approaching it with the grain of salt that it requires.
- jacquesm 13y ago
  Priceless comment. The alternative, to be like me, a stuck-in-the-past old guy who knows how to use only a few tools really well is probably also not optimal. But the chase-the-next-fad attitude can be just as lethal for your productivity as having no options at all.
  - StevePerkins 13y ago
    I'm being a more than a bit tongue-in-cheek here. Of course I do enjoy learning new languages, and accumulating at least a basic understanding of the technologies discussed here. However, I notice that languages wash over HN like waves. A few weeks ago there were a glut of back-to-back Clojure posts. Last week it was all-Go-all-the-time, and over the past few days Rust has surged. This wave pattern is a cultural quirk of HN, rather than serious indicators of what you should be pushing for within your company, or where you should be taking your career long-term.
    - jacquesm 13y ago
      I'm about to deep-dive into Erlang so consider me still susceptible to temptation :)
songgao 13y ago
I'm a bit confused. caption is supposed to be length of underlying array of a slice. What does it mean, concepturally, to create a new slice out of an existing one but with a different length of underlying array? Another thing is, maybe I'm worrying too much but, what if Go becomes more and more complicated that simplicity is not one of its advantages anymore, and people who're new to the language will get scared?
- lucian1900 13y ago
  While I don't think the slice changes are particularly out of character for Go, its simplicity is in general somewhat superficial. The type system is unsound and lacks power (although the interfaces are mostly nice), there are no generics (except for builtin collections), error handling is hard to compose (except in non-idiomatic ways), no real type inference (although single assignments are easier). Its simplicity is not composable.
- yiyus 13y ago
  Well, conceptually it means you limit how much you can extend the length of the slice inside the array, not that the array has a different length. For example, we have: full := []int{0, 1, 2, 3, 4, 5} half1 := full[:3] // [0, 1, 2] half2 := full[3:] // [3, 4, 5] Now, the capacity of half1 is 6, so it can "grow inside" half2, such that: append(half1, 666) // Now, half2 is [666, 4, 5] This may happen even when you are not using append, for example you could do: half1 = half1[:5] and get into half2 again. The new syntax solves this problem such that, after defining half1 as full[:3:3], if you try half1[:5] you will get an error (the length cannot be larger than the capacity) and if you use append, a new array will be allocated, leaving the contents of half2 intact in any case.
knodi 13y ago
Can't wait for 1.2 RC, there is some good stuff in the pipeline.
coldtea 13y ago
>Now, why is this an issue in real code? Imagine you’re writing your own memory allocator based on []byte – something that’s common when dealing with a lot of tiny allocations that shouldn’t slow down the GC. When the user asks for N bytes of memory, you return a slice that is a slice somewhere from that []byte, with length N. Now the user does something stupid: He appends to it. As we’ve seen before, this append will “leak” into memory beyond the length of the slice, and beyond what the memory allocator intended. You just overwrote someone else’s memory! So, first: "writing your own memory allocator [is] common when dealing with a lot of tiny allocations that shouldn’t slow down the GC". Second: "Now the user does something stupid: He appends to it. As we’ve seen before, this append will “leak” into memory beyond the length of the slice, and beyond what the memory allocator intended. You just overwrote someone else’s memory!". Is this what we want to be dealing with in a 2013 language? I'd rather have full C-like control than such BS edge cases and having to re-implement memory management myself.

78 points by radimm 13y ago

jzelinskie 13y ago

Does Rust have an equivalent location to get nice summaries of future development?

newgame 13y ago
There is 'This Week in Rust': http://cmr.github.io/blog/categories/this-week-in-rust/ http://cmr.github.io/blog/categories/this-week-in-rust/
- dbaupp 13y ago
  That is literally just the past week; there's not really anything for future stuff (there is so much future stuff that keeping track of it all would almost be more work than just going out and implementing it ;) ) other than skimming the mailing list, the weekly meetings and sometimes the devs blogs (which normally get posted to the mailing list and /r/rust on reddit); although the significant discussions do get linked in TWiR, so I guess I kinda lied.
gtani 13y ago
dunno how up to date this is (last edited 3 months ago https://github.com/mozilla/rust/wiki/Note-development-roadmap https://github.com/mozilla/rust/wiki/Note-development-roadma... and release notes https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes https://github.com/mozilla/rust/wiki/Doc-detailed-release-no...

MartinMond 13y ago

Go looks like a really nice language, but then I discovered that they don't _want_ to have exceptions. Crazy. I'm sticking with Erlang, "Let It Crash" (and handle the crash) is better than "add if(err) after everything and good luck with that"

nolok 13y ago
> "Let It Crash" (and handle the crash) panic() and recover() does that. It's not exceptions, but it does exactly that.
- lazyjones 13y ago
  It's the supervisor trees that are missing and cannot currently be implemented though.
  - AeroNotix 13y ago
    As a built-in language feature they are missing, but you can and some codebases do implement a kill channel for child goroutines.
  - jerf 13y ago
    As it happens, I've spent the last two days implementing supervision trees for Go, as I'm looking to port some stuff out of Erlang into Go. (There are a couple of existing libraries out there, but they are pretty weak tea, no offense to the authors in question, one of which is kind enough to label their effort with "this is my first Go code".) You can't implement Erlang-style trees without loss, and it's tricky due to some other things, but it can be done and you do get a substantial portion of the benefits, but also certainly not all. When I pop it up on github here soon, I'm planning on accompanying it by a blog post that will probably end up being longer than the entire library (including test suite and documentation) discussing all the whats and whys of how much you can and can not bring over of Erlang's approach.
  - JulianMorrison 13y ago
    Can be, easily. Your goroutine defers a function that calls recover and notifies the supervisor if it was panicking. It's exactly what Erlang does, just done slightly more manually.
  - dragonwriter 13y ago
    > It's the supervisor trees that are missing and cannot currently be implemented though. On a language level the support seems to be there, and not radically different from what Erlang offers. The pre-built libraries that make up OTP for Erlang aren't there and you have to build your own, but the underlying structure seems to be there.

StevePerkins 13y ago

I'm a professional Java developer, and thought I was fairly trendy because I've introduced Scala in my company's services tier. About a month ago I started reading HN, and discovered that I'm irrelevant because I'm still using Scala rather than Clojure. I ordered a Manning book, but before it even arrived I discovered that I'm irrelevant because I'm learning Clojure rather than Node.js. So I started a couple of personal projects based on Express. However, before I was completely comfortable with callbacks vs. promises, I discovered last week that I'm irrelevant because I'm working with Node.js rather than Go. Go has been my favorite of the bunch so far. However, I was just started to learn about goroutines and channels, when I discovered three days ago that I'm irrelevant because I'm using Golang rather than Rust. I like this board, but it should come with a warning label! I haven't been approaching it with the grain of salt that it requires.

jacquesm 13y ago
Priceless comment. The alternative, to be like me, a stuck-in-the-past old guy who knows how to use only a few tools really well is probably also not optimal. But the chase-the-next-fad attitude can be just as lethal for your productivity as having no options at all.
- StevePerkins 13y ago
  I'm being a more than a bit tongue-in-cheek here. Of course I do enjoy learning new languages, and accumulating at least a basic understanding of the technologies discussed here. However, I notice that languages wash over HN like waves. A few weeks ago there were a glut of back-to-back Clojure posts. Last week it was all-Go-all-the-time, and over the past few days Rust has surged. This wave pattern is a cultural quirk of HN, rather than serious indicators of what you should be pushing for within your company, or where you should be taking your career long-term.
  - jacquesm 13y ago
    I'm about to deep-dive into Erlang so consider me still susceptible to temptation :)

songgao 13y ago

I'm a bit confused. caption is supposed to be length of underlying array of a slice. What does it mean, concepturally, to create a new slice out of an existing one but with a different length of underlying array? Another thing is, maybe I'm worrying too much but, what if Go becomes more and more complicated that simplicity is not one of its advantages anymore, and people who're new to the language will get scared?

lucian1900 13y ago
While I don't think the slice changes are particularly out of character for Go, its simplicity is in general somewhat superficial. The type system is unsound and lacks power (although the interfaces are mostly nice), there are no generics (except for builtin collections), error handling is hard to compose (except in non-idiomatic ways), no real type inference (although single assignments are easier). Its simplicity is not composable.
yiyus 13y ago
Well, conceptually it means you limit how much you can extend the length of the slice inside the array, not that the array has a different length. For example, we have: full := []int{0, 1, 2, 3, 4, 5} half1 := full[:3] // [0, 1, 2] half2 := full[3:] // [3, 4, 5] Now, the capacity of half1 is 6, so it can "grow inside" half2, such that: append(half1, 666) // Now, half2 is [666, 4, 5] This may happen even when you are not using append, for example you could do: half1 = half1[:5] and get into half2 again. The new syntax solves this problem such that, after defining half1 as full[:3:3], if you try half1[:5] you will get an error (the length cannot be larger than the capacity) and if you use append, a new array will be allocated, leaving the contents of half2 intact in any case.

knodi 13y ago

Can't wait for 1.2 RC, there is some good stuff in the pipeline.

coldtea 13y ago

>Now, why is this an issue in real code? Imagine you’re writing your own memory allocator based on []byte – something that’s common when dealing with a lot of tiny allocations that shouldn’t slow down the GC. When the user asks for N bytes of memory, you return a slice that is a slice somewhere from that []byte, with length N. Now the user does something stupid: He appends to it. As we’ve seen before, this append will “leak” into memory beyond the length of the slice, and beyond what the memory allocator intended. You just overwrote someone else’s memory! So, first: "writing your own memory allocator [is] common when dealing with a lot of tiny allocations that shouldn’t slow down the GC". Second: "Now the user does something stupid: He appends to it. As we’ve seen before, this append will “leak” into memory beyond the length of the slice, and beyond what the memory allocator intended. You just overwrote someone else’s memory!". Is this what we want to be dealing with in a 2013 language? I'd rather have full C-like control than such BS edge cases and having to re-implement memory management myself.