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

Go(lang): Robust generic functions on slices

go.dev

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Go(lang): Robust generic functions on slices

#61

Post by d-z-m »

bufio wrote: post #53
stouset wrote: post #36

I feel like I’m taking crazy pills. How are these APIs even remotely defensible? slices.Sort(s) // fine slices.Compact(s) // broken s = slices.Compact(s) // fine s := slices.Compact(s) // broken (!!!) slices.Delete(s, …) // broken s = slices.Delete(s, …) // fine How is one intended to remember which functions require overwriting (due to invalidating) their input and which don’t? Why does the language make it so easy…

Don't you understand how slices work?

perhaps you should invoke bufio.ScanWords?

Re: Go(lang): Robust generic functions on slices

#62

Post by bobbylarrybobby »

never_inline wrote: post #5
jerf wrote: post #2

A missing tidbit that may help contextualize this post: One of the things about Go that surprised me is that if you have a slice which does not represent the full capacity of the underlying array, you can go ahead and reslice it up to that full capacity even though it's a panic to access the things you're reslicing directly: https://go.dev/play/p/oThz2bNFwgr Consequently, the GC has to assume that anything forward of…

It is reinforcing my belief that language design is hard. Go is supposed to be a simple language, one may write it for long time, but there will be some trap you discover once in a while.

Language design is hard, but... Jesus Christ, Go really just threw away 50 years of CS language research/experience in the name of “simplicity”.

Re: Go(lang): Robust generic functions on slices

#63

Post by pjmlp »

kaba0 wrote: post #56
renhanxue wrote: post #45

Earlier quoted context omitted.

It's golang, it has a long and proud tradition of being footguns all the way down.

It’s the C tradition, continued.

C versus the systems languages since 1958 (JOVIAL, NEWP, ALGOL, PL/I...), Go versus the languages since Fortran until 2009.

Re: Go(lang): Robust generic functions on slices

#64

Post by timmattison »

chrishill89 wrote: post #52
stouset wrote: post #36

I feel like I’m taking crazy pills. How are these APIs even remotely defensible? slices.Sort(s) // fine slices.Compact(s) // broken s = slices.Compact(s) // fine s := slices.Compact(s) // broken (!!!) slices.Delete(s, …) // broken s = slices.Delete(s, …) // fine How is one intended to remember which functions require overwriting (due to invalidating) their input and which don’t? Why does the language make it so easy…

I recently wanted to split and iterate on a String (`char *`) in the Git project. I was not feeling good that it had come to this point since I'm not a C programmer. ChatGPT told me that I wanted `strtok`. So I tried that but then the compiler complained that it was banned (via a macro).[1] Looking at the commit log I found out that `string_list.h` in the project was something that I could use. There's functions and…

I haven’t used strtok in a long time but my recollection is that it mutates the original string by placing a NULL value at the next delimiter so “hello world” would become “helloworld” if splitting on spaces. This lets you loop with the same string passed to strtok until it is done.

It’s ugly. Would not recommend. 0/10

Re: Go(lang): Robust generic functions on slices

#65

Post by aatd86 »

masklinn wrote: post #59
aatd86 wrote: post #58

Earlier quoted context omitted.

The way it is listed, it definitely looks problematic. I had to dig a little and in fact, once we remember that a slice is a view into an array and that "some" of these methods return slices, it's actually fine. The only issue is perhaps s:=slices.Compact() But that's not even because of the API. It's because of the short variable assignment that may allow shadowing, unfortunately. The issue is probably overblown her…

> once we remember that a slice is a view into an array and that "some" of these methods return slices, it's actually fine. Only in the meme sense, it does not actually solve or help solve the problem in any way.

If the problem is that slices are somewhat complex, allowing aliasing sure.

But then it's a problem of understanding what slices are so it does help in practice.

I am more concerned by the difficulty of mutating a slice (deleting and appending element) while iterating over it for instance. Done it and that's more difficult, ceremonious.

Re: Go(lang): Robust generic functions on slices

#66

Post by bananapub »

bobbylarrybobby wrote: post #62
never_inline wrote: post #5

Earlier quoted context omitted.

It is reinforcing my belief that language design is hard. Go is supposed to be a simple language, one may write it for long time, but there will be some trap you discover once in a while.

Language design is hard, but... Jesus Christ, Go really just threw away 50 years of CS language research/experience in the name of “simplicity”.

it's got all the latest features from the 1980s built right in

Re: Go(lang): Robust generic functions on slices

#67

Post by bsaul »

shakow wrote: post #30
TheDong wrote: post #7

The problems with the API they point out are almost all things that rust's ownership system was built to solve. Things like: slices.Sort(s) // correct slices.Compact(s) // incorrect slices.Delete(s, ...) // incorrect s := slices.Delete(s, ...) // incorrect if 's' is referenced again in the outer scope s = slices.Delete(s, ...) // correct All of those are solved by having functions like 'slices.Sort' take a '&mut' ref…

IMHO, all these comes from the million dollar mistake that Go made from the very beginning, with slices being a bastard between both an owned and non-owned data container. Indeed, any function accepting a slice may simply use it as an immutable view on whatever data it needs, or modify it, potentially re-alloc it, and wreak havoc by invalidating all previous references to it and/or its elements. And God forbid you pa…

my feeling with slices is that go wanted to really make programmers mindful of the cost of allocating new space on array operations.

By having this weird API on slices, they force you to be explicit on allocating new memory.

Re: Go(lang): Robust generic functions on slices

#68

Post by masklinn »

aatd86 wrote: post #65
masklinn wrote: post #59

Earlier quoted context omitted.

> once we remember that a slice is a view into an array and that "some" of these methods return slices, it's actually fine. Only in the meme sense, it does not actually solve or help solve the problem in any way.

If the problem is that slices are somewhat complex, allowing aliasing sure. But then it's a problem of understanding what slices are so it does help in practice. I am more concerned by the difficulty of mutating a slice (deleting and appending element) while iterating over it for instance. Done it and that's more difficult, ceremonious.

> If the problem is that slices are somewhat complex, allowing aliasing sure.

No, the problem is what I put at the top, that slices are hopelessly confused, they have two completely different and incompatible purposes and Go does not let you differentiate between the two.

Understanding what slices are does not help, neither in theory nor in practice.

Re: Go(lang): Robust generic functions on slices

#69

Post by masklinn »

bsaul wrote: post #67
shakow wrote: post #30

Earlier quoted context omitted.

IMHO, all these comes from the million dollar mistake that Go made from the very beginning, with slices being a bastard between both an owned and non-owned data container. Indeed, any function accepting a slice may simply use it as an immutable view on whatever data it needs, or modify it, potentially re-alloc it, and wreak havoc by invalidating all previous references to it and/or its elements. And God forbid you pa…

my feeling with slices is that go wanted to really make programmers mindful of the cost of allocating new space on array operations. By having this weird API on slices, they force you to be explicit on allocating new memory.

None of that makes any sense. Slices don't force you to be explicit on allocating new memory in any way. you can literally do this:

    s := []int{}
    for i := range 29754 {
        s = append(s, i)
    }
do you see explicit allocation of new memory? As far as I'm concerned that's not in any way more explicit than e.g.

    var s = new List();
    foreach(var i in Enumerable.Range(0, 29754)) {
        s.Add(i);
    }

Re: Go(lang): Robust generic functions on slices

#70

Post by bsaul »

masklinn wrote: post #69
bsaul wrote: post #67

Earlier quoted context omitted.

my feeling with slices is that go wanted to really make programmers mindful of the cost of allocating new space on array operations. By having this weird API on slices, they force you to be explicit on allocating new memory.

None of that makes any sense. Slices don't force you to be explicit on allocating new memory in any way. you can literally do this: s := []int{} for i := range 29754 { s = append(s, i) } do you see explicit allocation of new memory? As far as I'm concerned that's not in any way more explicit than e.g. var s = new List(); foreach(var i in Enumerable.Range(0, 29754)) { s.Add(i); }

s = append(s,i) makes you realize something happened to the memory behind s. Otherwise you would simply call s.append(i)
Post reply on HN