U= hm I might be mistaken, but I guess [8192]byte is an array, and []byte ar= e
slices - therefore they are different types.

yes, exactly. i suppose this implies that different size arra= ys are not type compatable
(yea pascal). also the fu :=3D bar[:] lo= oks a lot like the tedious casting from c, and implies
dynamic alloc= ation of the slice, i'm guessing.

- erik

On Sun, May 24, 2015 at 5:55 PM, erik quanstrom <= ;quanstro@quanstro.net> wrote:

and implies dynamic allocation of the slice, i'm guessing= .

Don't guess. Please read the links I provided, = they explain all this.
Arrays in Go are not like arrays in C and Pas= cal, slices are more
close. Go arrays are values, so copying one is = an O(n) operation.

= On Sun, May 24, 2015 at 11:55 AM, erik quanstrom <quanstro@quanstro.ne= t> wrote:

= > Uhm I might be mistaken, but I guess [8192]byte is an array, and []byt= e are
> slices - therefore they are different types.
>

yes, exactly.=C2=A0 i suppose this implies that different size array= s are not type compatable
(yea pascal).=C2=A0 also the fu :=3D bar[:] looks a lot like the tedious ca= sting from c, and implies
dynamic allocation of the slice, i'm guessing.

You can also argue that C arrays are pascal style. char x[8192]= and

char y[4096] do not have compatible types.

In fact. how could different array types be really compatible in a = C like

language?

void f(int a[50]);

even though you can pass a (pointer to) array of 25 in= ts, I doubt the

function would do the right thing.

If you pass both the pointer and the length to the function,= then you're

just emulating a Go slice (without the capacity)= .

In essence, Go's array is not directly relat= ed to C's, it's more like a C

array wrapped in a struct. = A slice is what C programmers normally

use to pass an array.

Regarding the boring comment, I agree to some extent. = There isn't

many fancy features that other languages have, bu= t that's exactly the

advantage of Go, and it's the price = to pay when you want readability.

(i.e. you don't need ~65 pa= ges of style guide just to tell you how to

write acceptable code.= )

--001a1144dc220dc15c0516da8bc4-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <0de965508a7a944ef6bf0c0af1082091@brasstown.quanstro.net> From: C Cirello Date: Mon, 25 May 2015 03:26:00 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] ot: pascal rides again? Topicbox-Message-UUID: 553cc2ec-ead9-11e9-9d60-3106f5b1d025 2015-05-24 23:25 GMT+02:00 minux : > > Regarding the boring comment, I agree to some extent. There isn't > many fancy features that other languages have, but that's exactly the > advantage of Go, and it's the price to pay when you want readability. > (i.e. you don't need ~65 pages of style guide just to tell you how to > write acceptable code.) This is a plan9 list - so I really don't want to extend the debate further. Being a simpler language, it means also you can write a style guide which says "you are free to use the whole language" instead of the usual C++ recommendations : "use this subset of the language". BTW, that's what happened with Plan 9's C - they simplified the language by trimming the preprocessor and forcing few stylistic choices in syntax (like ANSI C function declarations over K&R function declarations). By the same token we can say Go is boring, we can say Plan 9 is boring: rio does less with a much simpler design than X11, but it delivers much more - including window recursion and the ability to run X11 itself. In Plan 9 too, less is exponentially more. - CC From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Mon, 25 May 2015 07:39:23 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] ot: pascal rides again? Topicbox-Message-UUID: 5541ac08-ead9-11e9-9d60-3106f5b1d025 > (i.e. you don't need ~65 pages of style guide just to tell you how to > write acceptable code.) I think it's wasteful to defend Go. Let history do that... Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Sun, 24 May 2015 17:25:54 EDT." References: <0de965508a7a944ef6bf0c0af1082091@brasstown.quanstro.net> Date: Mon, 25 May 2015 00:59:05 -0700 From: Bakul Shah Message-Id: <20150525075905.32952B827@mail.bitblocks.com> Subject: Re: [9fans] ot: pascal rides again? Topicbox-Message-UUID: 554da21a-ead9-11e9-9d60-3106f5b1d025 On Sun, 24 May 2015 17:25:54 EDT minux wrote: > > On Sun, May 24, 2015 at 11:55 AM, erik quanstrom > wrote: > > > > Uhm I might be mistaken, but I guess [8192]byte is an array, and []byte > > are > > > slices - therefore they are different types. > > > > > > > yes, exactly. i suppose this implies that different size arrays are not > > type compatable > > (yea pascal). also the fu := bar[:] looks a lot like the tedious casting > > from c, and implies > > dynamic allocation of the slice, i'm guessing. > > > > You can also argue that C arrays are pascal style. char x[8192] and > char y[4096] do not have compatible types. In C arrays are not first class objects. In Pascal they are. They are passed by value (unless explicitly passed as a ref). In C you can't even do a = b Where a & b are the same size and type arrays. > In fact. how could different array types be really compatible in a C like > language? > > void f(int a[50]); > > even though you can pass a (pointer to) array of 25 ints, I doubt the > function would do the right thing. > > If you pass both the pointer and the length to the function, then you're > just emulating a Go slice (without the capacity). To pass a ref parameter, in Pascal you can do, for example, function f(var a:array[0..3][0..3] of integer) You can easily pass a subarray to f as: var a: array[0..99][0..99] of integer ... f(a[3..5][4..7]) And any modifications in f will update a. It is upto the compiler to do the right thing. [you can implement this a couple of different ways] You can even pass a var array parameter by value later (and the compiler will do the appropriate copying). I think that by exposing "slice" as a user visible type, Go gave up some things. Referencing a sub-array and extending an array are two very different things but a go slice is used for both and you can get some bizarre results. Try something like func f(b []int) { b = append(b, 55) } func main() { a := []int{0,1,2,3,4,5} f(a[0:2]) fmt.Printf("a=%v\n", a) f(a[5:]) fmt.Printf("a=%v\n", a) } To a newbie it would be very suprising that 2 got overwritten with 55 but the second 55 got lost! An experienced Go programmer would navigate around such sandbars but such behavior is disconcerting. > Regarding the boring comment, I agree to some extent. There isn't > many fancy features that other languages have, but that's exactly the > advantage of Go, and it's the price to pay when you want readability. > (i.e. you don't need ~65 pages of style guide just to tell you how to > write acceptable code.) Boring != simple. Plan9 is simple but not boring. Scheme is simple but not boring. Go lacks some features but it is not simple (nor orthogonal -- though I don't think that was a stated goal). In Go's favor, the Go code *is* easy to read and overall it is a well engineered practical language (that is what I meant by boring).