5 ms·
I'd argue that the Go example is worse than the equivalent in C, because Go has a garbage collector and C does not. In C, precisely because of the lack of a gar
by kccqzy 2y ago
I'd argue that the Go example is worse than the equivalent in C, because Go has a garbage collector and C does not. In C, precisely because of the lack of a garbage collector, people need to explicitly and carefully document who is responsible for deallocating the memory. This makes things clear who is owning that memory. And this by extension leads to an intuition on whether the append is acceptable on the original slice or not. If a C function returns such a slice and is documented that the caller should free it, you can call realloc and add to it; if the C function documents that the caller should not free it, you naturally wouldn't even try to append to it: you would copy it first.
In Go, this garbage collector frees people from thinking about freeing memory. But it doesn't free people from thinking about owned vs borrowed memory. And that's where bugs can happen.
- kbolino 2y agoThis isn't really a practical problem. If you created the slice, you control it and you can modify its elements, append to it, etc. If you didn't create the slice, you don't control it. If you want to modify it or append to it, you should copy it first. This has reflected how I've seen Go used professionally by people experienced in the language. The language could offer more help (but probably never will), but it's not hardly a regression from C. The real regression from C is the lack of const pointers.
- pjmlp 2y agoAnd enums, type Colours (Red, Blue, Green) //.... c := Colours.Blue a := pred(c) b := succ(c) for x := range Colours { //.... } 1976's Pascal style is unthinkable to ever land in Go, but we have iota and const, lets not complain.
- kbolino 2y agoGo's "enums" are worse than a lot of other languages, but they're not worse than C.
- pjmlp 2y agoIndeed, then again maybe we should not design languages with features worse than C in the 21st century, having 60 years of field experience.
- kbolino 2y agoIt's not worse. It's just only slightly better. The most damning thing you can say about Go is not that it doesn't improve upon C, it's that it improves only on C (and only in the ways cared about). The authors of Go really didn't examine other languages very closely. So starting with the authors' goals (light on the page, bounds checked, concurrency with message passing, easy to pick up, fast to compile) and a fairly deep knowledge of C (but little else) you pretty much get Go (especially early Go).
- pjmlp 2y agoEven that isn't really the case, as Go, as it started, was basically Inferno's Limbo in a new clothing, with some influence from Oberon-2 method syntax and the SYSTEM package as unsafe. Unfortunately afterwards they decided to follow Wirth's quest in Oberon-07 minimalism, instead of Active Oberon.
- baranul 2y agoI've always felt that the behavior of Go's ownership, in regards to minimalism, is a reflection of it being considered a solution for their internal problems. This is something outside of what users are requesting or needing. People have to look at Go alternative languages like Goplus, V (Vlang), Borogo, etc... for wanted features or greater responsiveness to user demands.
- 9rx 2y agoGo enums are the same as in every single other language. After all, all an enum does is count. There isn't anything more you can do with it. You can introduce data structures and types that utilize enums, with some languages taking that idea further than others, but that's well beyond enums themselves.
- kccqzy 2y agoThe practical problem is about transferring the control. Without it, you end up doing way too much defensive copying.
- zellyn 2y agoI happen to like the way Go did it, but now that generics and iterators have landed, it should be possible to create an always-make-a-copy vector type (although it'll need to use `get` and `set` like Java Lists, not [42] like slices/arrays). It's not like you could have appended twice to the same List in Java and expected to get two disjoint arrays, unless you copy first, and `slices.Clone()` makes that easy in Go now too.