a[low:high:max] in Golang – A Rare Slice Trick • Hacker News Board

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

#101

Post by TwentyPosts » Sun, Mar 19, 2023, 9:20 AM UTC

throwaway894345 wrote: post #74

wyager wrote: post #11

Earlier quoted context omitted.

This is a pretty good vignette of how Go is designed. "Users don't need this feature (immutability, polymorphism, etc.), let's not include it. Ah crap, turns out we actually need it for a core language feature. Is there a lesson we can take away here? Nah, just make an ad-hoc implementation of the functionality in this one place."

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 ties into Go's error handling, which continues to be a major talking point.

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

#102

Post by pjmlp » Sun, Mar 19, 2023, 9:24 AM UTC

wyager wrote: post #11

Groxx wrote: post #9

Earlier quoted context omitted.

But also strings are actually immutable sometimes (at the very least when hardcoded), and they can be converted to a `[]byte` slice that looks mutable, but panics when modified. AFAIK no other slice-like data in Go behaves like this. Fun!

This is a pretty good vignette of how Go is designed. "Users don't need this feature (immutability, polymorphism, etc.), let's not include it. Ah crap, turns out we actually need it for a core language feature. Is there a lesson we can take away here? Nah, just make an ad-hoc implementation of the functionality in this one place."

Ironically that is exactly the same approach they had with C, so at least they are consistent.

"Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own."

-- https://www.bell-labs.com/usr/dmr/www/chist.html

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

#103

Post by pjmlp » Sun, Mar 19, 2023, 9:25 AM UTC

Thaxll wrote: post #63

wyager wrote: post #11

Earlier quoted context omitted.

This is a pretty good vignette of how Go is designed. "Users don't need this feature (immutability, polymorphism, etc.), let's not include it. Ah crap, turns out we actually need it for a core language feature. Is there a lesson we can take away here? Nah, just make an ad-hoc implementation of the functionality in this one place."

Which modern languages do const properly?

Any ML derived language.

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

#104

Post by morelisp » Sun, Mar 19, 2023, 9:41 AM UTC

MrBuddyCasino wrote: post #96

morelisp wrote: post #40

Earlier quoted context omitted.

> It means there is special protection for strings that is not available to anything else Lots of languages have no C/C++-style const objects yet immutable strings. It's weird to pick on Go specifically for this. (Since it's the JVM model, at this point it may even be a majority of mainstream languages.) If you mean specifically the panic when modifying a static string, is this not just the default `mprotect` on roda…

> Since it's the JVM model Java model. Kotlin collections are immutable by default (not sure about Scala, but I suspect they behave the same).

I'm pretty sure it's the JVM model. Kotlin collections are "immutable" in that they have no mutating accessors, which is not the same thing as a memory region defined to be immutable by the specification which can be relied on to e.g. trivialize certain compiler optimizations. (I plead ignorance about Kotlin Native, maybe it does such things.)

You can also look at what kinds of things are allowed in class constant pools; you will not find any collections.

https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...

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

#105

Post by morelisp » Sun, Mar 19, 2023, 9:52 AM UTC

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…

Is the excellent tooling not also a property of a minimal language? Lisp has the "least" syntax/semantics and the best tooling, because it's so easy to write tools. Go has more complex syntax/semantics, but still much easier to wrangle e.g. control flow out of an AST, compared to other Algol derivatives.

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

#106

Post by morelisp » Sun, Mar 19, 2023, 10:01 AM UTC

throwaway894345 wrote: post #69

tedunangst wrote: post #14

Earlier quoted context omitted.

I don't think you can convert a string to []byte without unsafe except by copying?

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.

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

#107

Post by morelisp » Sun, Mar 19, 2023, 10:08 AM UTC

iainmerrick wrote: post #58

morelisp wrote: post #55

Earlier quoted context omitted.

You cannot "overrun the buffer" nor can a callee add stuff to the end of your list; you can give them a memory buffer with unused space and they may use it, and then you can also mistakenly use it later. Honestly, you seem to be too detached to understand this. If you really want to know how it works go through some official Go documentation. It's not fundamentally different than some feature in other languages, it's…

I coincidentally was just looking at some docs, and I think I have a handle on it (to it?:) now. The specific strange design decision in Go is that you can create a child slice that has its own starting offset and length, but may or may not inherit its parent’s capacity. Just because it’s well-defined doesn’t mean it isn’t tricky. Even if you kept the semantics the same but made cap=len for subslices by default, sure…

I mean, if you want Java, it's right there.

The advantage is that you get the fast path by default. Since Go programs are generally not awash in buffer reuse bugs despite its semantic trickiness, this seems like something different languages can reasonably prioritize differently.

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

#108

Post by hdhrufjdi » Sun, Mar 19, 2023, 11:10 AM UTC

throwaway894345 wrote: post #76

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…

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

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

#109

Post by MrBuddyCasino » Sun, Mar 19, 2023, 11:46 AM UTC

morelisp wrote: post #104

MrBuddyCasino wrote: post #96

Earlier quoted context omitted.

> Since it's the JVM model Java model. Kotlin collections are immutable by default (not sure about Scala, but I suspect they behave the same).

I'm pretty sure it's the JVM model. Kotlin collections are "immutable" in that they have no mutating accessors, which is not the same thing as a memory region defined to be immutable by the specification which can be relied on to e.g. trivialize certain compiler optimizations. (I plead ignorance about Kotlin Native, maybe it does such things.) You can also look at what kinds of things are allowed in class constant po…

If you specifically mean RO memory pages, then yes, thats not the same thing. The language and the runtime will enforce collection immutability though, throwing an exception if you attempt to mutate. Poking at the underlying byte code will defeat this, of course.

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

#110

Post by hamdouni » Sun, Mar 19, 2023, 12:08 PM UTC

H4ZB7 wrote: post #64

why do people write articles about go features? when PHP was in its prime, almost nobody wrote blogs explaining how they found some philosophy in PHP. there's a reason for that. when you see someone open their article explaining a language feature by talking of the implementation details or specific use cases, that's a language smell (of course all industrial PLs stink). ironically go is the only post 80s language th…

Oh, I rather use this version :

  package main

  func main() {
    a := [2]int{1, 2}
    b := a[0:1:1]
    c := b[0:2]
    println(b[0], c[1])
  }