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

Go Data Structures: Interfaces (2009)

research.swtch.com

Post reply on HN
Print view View original

51–60 of 80 posts

Re: Go Data Structures: Interfaces (2009)

#51

Post by foldr »

debugnik wrote: post #41
foldr wrote: post #34

Earlier quoted context omitted.

It’s obvious that this is O(n), no? You’re casting something immutable to something mutable, so it has to be copied.

And decoding subsequences of UTF-8 code units (bytes) into Unicode scalars (runes), which also forces a copy. But why did Go pick the same syntax for cheap conversions and expensive ones, though? I'd expect this to be a standard function, not a type conversion.

Don't all conversions require copying the value at the level of the language semantics? You can cast a float to an int, but you can't assign an integer value to a float variable (leaving aside whatever optimizations the compiler might make). Casting a float to an int is only cheap because a float is a fixed size. So it seems unsurprising to me that casting a larger value results in a proportionally larger copy.

Re: Go Data Structures: Interfaces (2009)

#53

Post by neonsunset »

rednafi wrote: post #52
neonsunset wrote: post #48

Earlier quoted context omitted.

[flagged]

[flagged]

> Bob Nystrom worked on Dart at Google and wrote the amazing Crafting Interpreters book. Rob Pike referenced this article in his 2023 talk, Go: What We Got Right, What We Got Wrong, while discussing the trade-offs between CSP and coroutine-driven concurrency.

I know, which is the exact reason the reply states "uncharacteristically". And yet, it fails to acknowledge existing terminology and tradeoffs and just states at the end in a couple paragraphs how Goroutines shall deliver us all from evil (which could not be demonstrably further from the truth). Surely we need to expect better from one of the Dart's authors than forgetting to mention all the caveats virtual threading via stackful coroutines comes with?

And this completely ignores that Go applications end up having to reimplement .NET's task system system anyway and that Goroutines are poorly suited for "fine-grained" concurrency. Even the UX of Goroutines is bad. Want to return a value when one exits? Be sure to not screw up synchronizing and passing the data by hand. One must imagine Gophers writing all that boilerplate happy. I suppose, it's a preferred pastime to learning the internals and ceasing to post the same tired shibboleths.

Re: Go Data Structures: Interfaces (2009)

#54

Post by PhilipRoman »

nlitened wrote: post #24
saghm wrote: post #19

Earlier quoted context omitted.

Yeah, I have plenty of criticisms of Go, but this is something that it got right. For those who aren't familiar with the issue, in Java you can assign an array of a subclass to a variable declared as an array of the superclass, which leads to issues if you actually try to mutate it. Imagine if Cat and Dog both inherit from Animal, assigning a Dog[] to an Animal[] is totally valid, but then setting one of the elements…

I can’t help but keep noticing that all of the notorious problems with OOP are not due to inheritance, but due to mutability.

The mutability is a red herring here. It depends on what methods your object has and where the generic type resides within the signature. It just so happens that an immutable array has only one relevant "method":

    get :: Int -> T
Here, T is on the right/return side, therefore an immutable array type would be covariant. But a mutable array also has a

    set :: Int, T -> void
which has T on the left/parameter side and therefore requires contravariance (and you cannot have both, therefore you get invariance). But the issue is not with mutability, since you could just as well have something like

    setImmutable :: Int, T -> Array(T)
and you still wouldn't be able to make Array(T) covariant.

And for the record, it is only raw arrays in Java that have this issue, generic types like List are invariant (of course you can explicitly ask for a List if you want to only call "setter" type methods on it, or List for getters, aka methods where T appears only on return side).

Re: Go Data Structures: Interfaces (2009)

#55

Post by dfawcus »

rollcat wrote: post #37
rednafi wrote: post #20

Earlier quoted context omitted.

One thing I like about Go is that you can read a decade-old blog and still find it somewhat relevant. Python was the first language I made money with. However, these days, I struggle to read and make sense of type-ridden, generic-filled, Pydantic-infested Python code.

> Python was the first language I made money with. However, these days, I struggle to read and make sense of type-ridden, generic-filled, Pydantic-infested Python code. I'm in the same boat. Python was great when it was a snake. I liked additions like the "with" statement - they were very pythonic. I think it's good when the language evolves, although the direction Python took feels more like grafting - oh people lik…

Re tuples, I guess you mean the multiple return values, and this assignment form: https://go.dev/play/p/vxm6lV7JS4z

However how would real first class tuples be an improvement in Go? Alef had them, and allowed various manipulations, as well as returning them, and passing them to functions.

I note that they are present in Hare, but not present in Odin. Where the latter has the Go inspired multiple return values, but (AFAICS) no tuples, but does add tagged unions.

Generally I'd not want to store a tuple, preferring a struct with named fields.

So the only uses I can think of are those temporary ones for multiple return values and assignments, which are already covered.

Re: Go Data Structures: Interfaces (2009)

#56

Post by rednafi »

neonsunset wrote: post #53
rednafi wrote: post #52

Earlier quoted context omitted.

[flagged]

> Bob Nystrom worked on Dart at Google and wrote the amazing Crafting Interpreters book. Rob Pike referenced this article in his 2023 talk, Go: What We Got Right, What We Got Wrong, while discussing the trade-offs between CSP and coroutine-driven concurrency. I know, which is the exact reason the reply states " uncharacteristically ". And yet, it fails to acknowledge existing terminology and tradeoffs and just states…

[flagged]

Re: Go Data Structures: Interfaces (2009)

#57

Post by neonsunset »

rednafi wrote: post #56
neonsunset wrote: post #53

Earlier quoted context omitted.

> Bob Nystrom worked on Dart at Google and wrote the amazing Crafting Interpreters book. Rob Pike referenced this article in his 2023 talk, Go: What We Got Right, What We Got Wrong, while discussing the trade-offs between CSP and coroutine-driven concurrency. I know, which is the exact reason the reply states " uncharacteristically ". And yet, it fails to acknowledge existing terminology and tradeoffs and just states…

[flagged]

[flagged]

Re: Go Data Structures: Interfaces (2009)

#58

Post by nlitened »

PhilipRoman wrote: post #54
nlitened wrote: post #24

Earlier quoted context omitted.

I can’t help but keep noticing that all of the notorious problems with OOP are not due to inheritance, but due to mutability.

The mutability is a red herring here. It depends on what methods your object has and where the generic type resides within the signature. It just so happens that an immutable array has only one relevant "method": get :: Int -> T Here, T is on the right/return side, therefore an immutable array type would be covariant. But a mutable array also has a set :: Int, T -> void which has T on the left/parameter side and ther…

This setImmutable would return a new instance of Array which would not be Array like the original, and would contain any mix of cats and dogs.

So immutability resolves the covariance problem, I think?

Re: Go Data Structures: Interfaces (2009)

#59

Post by saurik »

sltkr wrote: post #44
saurik wrote: post #4

Earlier quoted context omitted.

Is that really a "quirk" of specifically Go? I am pretty sure Java--the implementation of which defined a lot of how numerous languages handle this kind of thing--has the same behavior: you can cast String[] to Object, but not Object[].

Actually in Java you can cast String[] to Object[] although this is technically unsound. This how generic methods like Arrays.sort() are implemented.

Huh, fair enough!! What's then funny in the context of this thread is that, while I am sure I knew that 20-25 years ago, it feels so wrong that it would support that -- and more like a "quirk" that it ever would -- that it surprises me (though it certainly doesn't shock me: most things have many quirks).

Re: Go Data Structures: Interfaces (2009)

#60

Post by dwattttt »

nlitened wrote: post #58
PhilipRoman wrote: post #54

Earlier quoted context omitted.

The mutability is a red herring here. It depends on what methods your object has and where the generic type resides within the signature. It just so happens that an immutable array has only one relevant "method": get :: Int -> T Here, T is on the right/return side, therefore an immutable array type would be covariant. But a mutable array also has a set :: Int, T -> void which has T on the left/parameter side and ther…

This setImmutable would return a new instance of Array which would not be Array like the original, and would contain any mix of cats and dogs. So immutability resolves the covariance problem, I think?

I've never quite understood enough about types to know why, but: it's more like the difference between read-only and write-only.

One of the variances is safe if you only read, and one is safe if you only write.

Post reply on HN