Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: My notes on Working with Go

github.com

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Show HN: My notes on Working with Go

#81

Post by amscanne »

axaxs wrote: post #75
yencabulator wrote: post #74

Earlier quoted context omitted.

Much like the github link, you're confusing slices with arrays. Slices can be nil (data=nil, len=cap=0) or non-nil (data points somewhere, len and cap are what they are), but arrays are just arrays, there's no such thing as an uninitialized [3]byte.

I'm not. I've been a Go programmer for years, and I literally quoted your comment above mine - it says (or slices)

I believe your comment is wrong though. Those two things will use exactly the same amount of memory.

The data pointer in the slice points to an array-type of size zero. All allocations for objects of size zero return a fixed address in the data section (so there is a distinction between a nil and non-nil object, but a pointer to a zero sized object does not actually take any space).

See line 909: https://golang.org/src/runtime/malloc.go

Re: Show HN: My notes on Working with Go

#82

Post by axaxs »

amscanne wrote: post #81
axaxs wrote: post #75

Earlier quoted context omitted.

I'm not. I've been a Go programmer for years, and I literally quoted your comment above mine - it says (or slices)

I believe your comment is wrong though. Those two things will use exactly the same amount of memory. The data pointer in the slice points to an array-type of size zero. All allocations for objects of size zero return a fixed address in the data section (so there is a distinction between a nil and non-nil object, but a pointer to a zero sized object does not actually take any space). See line 909: https://golang.org/s…

Flip the first line between true and false, you'll see different memory usage based on declaration type. I haven't analyzed the compiler code, but my assumption is it's forced to return an actual slice object when one is declared with :=. But I'd be happy to be better educated here -

https://play.golang.org/p/wVyv0qhj9rp

Re: Show HN: My notes on Working with Go

#83

Post by dang »

bruhlollol wrote: post #4

Note nº 1: don't!

Please don't post unsubstantive comments to HN, and please don't do programming language flamewars here. They're tedious and shallow and usually turn nasty.. We're hoping for something more interesting on this site.

https://news.ycombinator.com/newsguidelines.html

Re: Show HN: My notes on Working with Go

#84

Post by dang »

hombre_fatal wrote: post #11
rsa25519 wrote: post #5

Earlier quoted context omitted.

Care to elaborate?

Do we really need to entertain throwaway accounts created just for the boring "lang {good,bad}!" interjection? If you want to see it, there are so many places we have that discussion. And that discussion can be found so many times online. Look at any Go version release on HN if you want to find more. Even making a top-level comment like "Can anyone explain some quick pros/cons of $lang?" would go farther than these i…

Obviously the root comment was lame and should not have been fed, but please don't take the thread further off topic.

Re: Show HN: My notes on Working with Go

#85

Post by dang »

rsa25519 wrote: post #5
bruhlollol wrote: post #4

Note nº 1: don't!

Care to elaborate?

The HN guidelines include a version of please don't feed the trolls. It goes like this: "Don't feed egregious comments by replying; flag them instead."

https://news.ycombinator.com/newsguidelines.html

Re: Show HN: My notes on Working with Go

#86

Post by yencabulator »

axaxs wrote: post #82
amscanne wrote: post #81

Earlier quoted context omitted.

I believe your comment is wrong though. Those two things will use exactly the same amount of memory. The data pointer in the slice points to an array-type of size zero. All allocations for objects of size zero return a fixed address in the data section (so there is a distinction between a nil and non-nil object, but a pointer to a zero sized object does not actually take any space). See line 909: https://golang.org/s…

Flip the first line between true and false, you'll see different memory usage based on declaration type. I haven't analyzed the compiler code, but my assumption is it's forced to return an actual slice object when one is declared with :=. But I'd be happy to be better educated here - https://play.golang.org/p/wVyv0qhj9rp

[]int{} is a non-nil slice, which allocates. The zero-length optimization probably doesn't exist for arrays in this context, because no sane code does this.

This still has nothing to do with "declaring" vs "initializing" (Go makes no such distinction; all values are always "initialized"), or direct use of arrays.

Re: Show HN: My notes on Working with Go

#87

Post by zero_shift »

erik_seaberg wrote: post #80
nobleach wrote: post #29

Earlier quoted context omitted.

Go has a GC. Specifying the need for manual memory-management might be moving the goal-posts a bit. Edit Phone auto-correct from memory management to measurement.

To be fair, it's possible to write code that does no heap allocation in each of these languages. None of them guard against mistakes that create GC work, and Java would not be my choice for this.

True. I've even had the "interesting" experience of writing low-allocation JavaScript (for 3D mostly).

Re: Show HN: My notes on Working with Go

#88

Post by amscanne »

yencabulator wrote: post #86
axaxs wrote: post #82

Earlier quoted context omitted.

Flip the first line between true and false, you'll see different memory usage based on declaration type. I haven't analyzed the compiler code, but my assumption is it's forced to return an actual slice object when one is declared with :=. But I'd be happy to be better educated here - https://play.golang.org/p/wVyv0qhj9rp

[]int{} is a non-nil slice, which allocates. The zero-length optimization probably doesn't exist for arrays in this context, because no sane code does this. This still has nothing to do with "declaring" vs "initializing" (Go makes no such distinction; all values are always "initialized"), or direct use of arrays.

> The zero-length optimization probably doesn't exist for arrays in this context

This is no distinction for arrays for non-array. E.g. [0]int is a valid type, and it's size is zero. It is treated exactly the same as all other zero-sized types. This is not a special optimization: there are may cases of zero-sized types.

The slice itself is a value type. So foo := []int{} would occupy 24-bytes (data pointer, len, cap) and not necessarily escape to the heap, exactly the same as var foo []string.

Re: Show HN: My notes on Working with Go

#89

Post by [deleted] »

axaxs wrote: post #82
amscanne wrote: post #81

Earlier quoted context omitted.

I believe your comment is wrong though. Those two things will use exactly the same amount of memory. The data pointer in the slice points to an array-type of size zero. All allocations for objects of size zero return a fixed address in the data section (so there is a distinction between a nil and non-nil object, but a pointer to a zero sized object does not actually take any space). See line 909: https://golang.org/s…

Flip the first line between true and false, you'll see different memory usage based on declaration type. I haven't analyzed the compiler code, but my assumption is it's forced to return an actual slice object when one is declared with :=. But I'd be happy to be better educated here - https://play.golang.org/p/wVyv0qhj9rp

[deleted]

Re: Show HN: My notes on Working with Go

#90

Post by amscanne »

axaxs wrote: post #82
amscanne wrote: post #81

Earlier quoted context omitted.

I believe your comment is wrong though. Those two things will use exactly the same amount of memory. The data pointer in the slice points to an array-type of size zero. All allocations for objects of size zero return a fixed address in the data section (so there is a distinction between a nil and non-nil object, but a pointer to a zero sized object does not actually take any space). See line 909: https://golang.org/s…

Flip the first line between true and false, you'll see different memory usage based on declaration type. I haven't analyzed the compiler code, but my assumption is it's forced to return an actual slice object when one is declared with :=. But I'd be happy to be better educated here - https://play.golang.org/p/wVyv0qhj9rp

This is a total red herring.

I don't know why the numbers are consistently different for the different programs, but the compiler is completely optimizing out the function call in both cases.

Consider the example where you do two prints: https://play.golang.org/p/Y1GUutEQkzx

Here is the compiled object code, which is identical for true and false: main.go:15 0x49b640 64488b0c25f8ffffff MOVQ FS:0xfffffff8, CX main.go:15 0x49b649 483b6110 CMPQ 0x10(CX), SP main.go:15 0x49b64d 7624 JBE 0x49b673 main.go:15 0x49b64f 4883ec08 SUBQ $0x8, SP main.go:15 0x49b653 48892c24 MOVQ BP, 0(SP) main.go:15 0x49b657 488d2c24 LEAQ 0(SP), BP main.go:16 0x49b65b 0f1f440000 NOPL 0(AX)(AX*1) main.go:16 0x49b660 e89bfeffff CALL main.printStats(SB) main.go:21 0x49b665 e896feffff CALL main.printStats(SB) main.go:22 0x49b66a 488b2c24 MOVQ 0(SP), BP main.go:22 0x49b66e 4883c408 ADDQ $0x8, SP main.go:22 0x49b672 c3 RET

Notice how there's nothing between the printStats calls?

Post reply on HN