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

a[low:high:max] in Golang – A Rare Slice Trick

build-your-own.org

Post reply on HN
Print view View original

121–130 of 131 posts

Re: a[low:high:max] in Golang – A Rare Slice Trick

#121

Post by morelisp »

andromeduck wrote: post #95
kosherhurricane wrote: post #79

Earlier quoted context omitted.

TLDR: The best part of Go is that there is very little magic in Go. If you understand that slices are just fat pointers implemented as a built-in, there is nothing confusing about them. I can understand every part of a Go program, all the way down to the language syntax that generate assembly. I don't have to be afraid of or be mystified by any language feature, because 1) there are few, 2) they are just programs imp…

Why not just use c at that point?

Why not use C instead of Better C? Is that what you're asking?

Re: a[low:high:max] in Golang – A Rare Slice Trick

#122

Post by throwaway894345 »

TwentyPosts wrote: post #101
throwaway894345 wrote: post #74

Earlier quoted context omitted.

I mean, what language got everything exactly right from day 0? Yes, Go started from a minimalist position, but that’s been a wildly successful decision—Go lacks a lot of the cruft of other languages. Go is an easily understandable language, it compiles super quickly, it has top notch tooling (e.g., compiling almost any Go project on any system with ‘go build’ and even cross compile by changing a couple of env vars),…

A cynical view is that 80% of Go's success is a result of the excellent tooling, and the fact that it's associated for and pushed by Google, while the underlying language is "mediocre" at best. In theory I agree with Go's minimalist perspective, it just also feels inconsistent, and like they made a whole lot of bad decisions along the way. Favoring C-style enums over proper sum-types is one of the biggest one, and ti…

I fully agree with the enums thing—that’s by far my biggest gripe with the language. But even still, I can be a lot more productive in Go than I can in any other mainstream language, including languages that have sum types (Rust, OCaml, etc) which isn’t to say sum types make me less productive but rather that those languages have other productivity issues that outweigh the benefits afforded by sum types. Basically, Go gets a whole lot of little things right that most languages miss, but everyone fixates on “generics” and “sum types” which are, overall, quite small things IMHO.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#123

Post by throwaway894345 »

morelisp wrote: post #106
throwaway894345 wrote: post #69

Earlier quoted context omitted.

Agreed. You can copy a string into a byte slice, but I don’t think you can convert one into a byte slice that panics on mutation.

Is it panicking on mutation because Go has some special logic, or is it panicking because the text segment is PROT_READ? If it's the latter, sure you can do that too.

I don’t know what PROT_READ is, but as far as I know, Go doesn’t allow you to convert a string into a byte slice apart from ‘unsafe’ (and presumably you’re free to modify that without panicking, but even if not, you used unsafe so the onus is on you to know what you’re doing). There’s syntax support for creating a byte slice by copying a string’s data, but that won’t panic on mutation.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#124

Post by throwaway894345 »

hdhrufjdi wrote: post #108
throwaway894345 wrote: post #76

Earlier quoted context omitted.

I haven’t heard many gripes about the syntax, but I have heard plenty of gripes about how long it took them to add them. Frankly my biggest grievance with Go’s generics is the goofy dictionary implementation that makes performance difficult to reason about. I also think the people who complain the loudest about missing generics were often just unaware that there are other (often simpler) ways to achieve the same thin…

I had to add a code generator, because of the lack of generics

Yeah, like I said, there are some cases where generics are genuinely helpful. It’s just a small percentage of the code I tend to write (generics have been out for quite a while, and I still avoid them in Go despite my familiarity with languages like Rust, TypeScript, etc that use them extensively).

Re: a[low:high:max] in Golang – A Rare Slice Trick

#125

Post by Groxx »

the_gipsy wrote: post #97
fooster wrote: post #86

Earlier quoted context omitted.

If you are going to make such a claim then please back it up rather than state opinions as facts.

https://go101.org/generics/888-the-status-quo-of-go-custom-g...

Yeah. Go generics are quite crippled. I'm still very, very glad that they exist though - even crippled, they're a vast improvement.

I think they took a... rather extremely-conservative step towards what their generics will eventually be, at which point they'll probably be pretty reasonable. As it stands now they're kinda weird and and very incomplete, though thankfully simple (in behavior).

They did at least leave syntactic and semantic room to improve them though, so I think it'll happen eventually. It was cut off at a safe point. They just need to be brow-beaten further, hopefully this small success won't stop the pressure.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#126

Post by yencabulator »

andrewstuart2 wrote: post #7
tedunangst wrote: post #5

Earlier quoted context omitted.

There are no immutable arrays. If you have a slice of capacity ten with four elements, you can write a fifth element to it. If you reduce the capacity to four, then a new slice must be allocated to store five elements. The backing store for a slice is just a pointer. The rule is you don't give people pointers that you don't want them to write to.

That's just not true. There are immutable arrays in length. [4]int cannot be appended to. The backing of all slices are array types and array doubling is used for appends that go beyond the capacity. https://go.dev/ref/spec#Array_types

No array can change its length, the length is part of the type. There really are no "immutable array"s.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#127

Post by emidoots »

kjksf wrote: post #75
jeffparsons wrote: post #62

Earlier quoted context omitted.

I think in this context "ad hoc" refers to the context in which that syntax was added. IIRC the original creators were against generics ever being added to Golang, so they wouldn't have thought about their eventual introduction when choosing Go's initial syntax. The result is that the generics that eventually were added feel awkward and "bolted on" to many people. (I don't have any strong opinions on it personally, b…

Maybe you shouldn't play game of telephone like that. Go generics are exceptionally well designed. The reason it took so long for Go to get generics is because Go designers took their time to arrive at a design that fits with the rest of Go. It's not rushed, it's not "bolted on". They did several designs that they rejected before they accepted the design that got implemented.

I'm a big fan of Go, have been using it since r59 (pre 1.0), professionally working with it the past ~8 years at one of the earliest companies to adopt it.

The fact that you cannot have a generic method at all, and instead have to rewrite methods as functions.. that seems like a pretty glaring flaw.

I'm happy Go got some form of generics, definitely, but they really do feel bolted on to the language.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#128

Post by klodolph »

or10nx wrote: post #89
klodolph wrote: post #43

Earlier quoted context omitted.

In C++, until C++20’s std::span, you would just use std::vector for stuff you can modify and const std::vector for stuff you can’t. I think the real problem is that Go’s type system doesn’t catch the common error of keeping a reference to something you don’t own, or similar errors. C# catches some of these errors by letting you return a IReadOnlyList or some other restricted type. Golang has ways to narrow certain ty…

> People fret about the difference between T[] and List in C# That doesn't align with my experience. I've worker for small (4 programmers) and large (100s of programmers) C# shops, and I don't recall people "fretting" about T[] and List . People see T[] as a non-growable, less useful version of List . HashSet vs List seems to cause much more trouble for novice (and sometimes experienced) C# programmers.

I'm thinking more about the places where people care about performance, since accessing a T[] is faster than accessing a List (less indirection).

Re: a[low:high:max] in Golang – A Rare Slice Trick

#129

Post by Groxx »

iainmerrick wrote: post #77
Groxx wrote: post #68

Earlier quoted context omitted.

cap==len is effectively the default - most slicing is done with [start:end], not [start:end:additional-cap]

No it’s not -- I just checked the language specification and it says: After slicing the array a a := [5]int{1, 2, 3, 4, 5} s := a[1:4] the slice s has type []int, length 3, capacity 4 Many of us here are arguing that the default should be cap==len==3, but it’s not, it’s 4.

Welp. TIL.

Yeah, that's much more error prone I think. It's the sort of thing that only kinda makes sense on zero-valued arrays... and even then it's dubious at best.

Bleh. I'm gonna go review some old code now D:

Re: a[low:high:max] in Golang – A Rare Slice Trick

#130

Post by nutate »

morelisp wrote: post #119
nutate wrote: post #118

Earlier quoted context omitted.

the ability to cast nil as a zero length array means there's no difference between a function that returns a zero length array and a function that returns nil (assuming some casting process takes place). It could be a subtle and annoying bug to track down the difference.

nil isn't cast to an empty slice (Go doesn't have casts, except maybe the new pointer-to-array syntax if you want to count that), nil is the default value of a slice, and that value is also empty. Other empty slices may be non-nil, because they may have capacity, or have been sliced out of another buffer, etc. Of the various legitimate issues around nil (box vs. unboxed, nil receivers, nilability of all pointers), th…

Oddly the first issue I came across today was folks being confused about this. I haven't gotten to the bottom of where the code is now, but this go library was messing up len == 0 vs nility and someone forked it to fix it: https://github.com/algorithmiaio/mapstructure/pull/1 It may not be a common bug but that doesn't make it less of a pitfall.
Post reply on HN