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

Simplicity and the ideas Go left behind

sourcegraph.com

Post reply on HN
Print view View original

61–70 of 91 posts

Re: Simplicity and the ideas Go left behind

#61

Post by Padding »

Daishiman wrote: post #12

This answer is slightly infuriating: > Q: Lack of generic collection classes like in Java’s Guava library?A: For 90% of cases, slices and maps do what you need. For the other 10%, you might consider whether your package should own the logic of those special containers, instead of using an external package. I read this as: "We're not willing to put in the hard work on thinking of a decent generics implementation, desp…

> despite decades of working solutions

Which "working" solutions? Has anyone solved creating a type system that offers OO/inheritance, generics, mutability and isn't mind-bogglingly complex?

What is your definition for a "working" solution? I don't think any of the current languages we have fit this description, since all of them are capable of producing type errors that are way too complex to comprehend.

> with a myriad of choices in tradeoffs

Yeah, but how do you decide on which tradeoff to settle for? And why is the tradeoff to not engage in this mess not a just as valid one?

> so you'll have to do the hard work of integrating a dozen different collections libraries and who knows how many different, after-the-fact, mediocre strategies to the generics issue, each slighly off, all of them conceptually incomplete somehow

You're missing the point. Solving the generics issue for a specialized case, even if just on a library-level, is much easier and has much less impact on applications than solving the general case and forcing that solution onto every bit of code in that language.

I don't think the author is advocating using a general purpose 3rd-party library for containers, but rather writing your own special-purpose ones for the few cases where the on-board tools aren't enough.

> with the slight bugs that come from not having a well-trodden path

Localized bugs are easier to solve than the type errors common to that "well-trodden path" you talk about, which may span an entire application.

..not that there is any consesus on what exactly that "well-trodden path" is, since as you mentioned there's a myriad of tradeoffs.

Re: Simplicity and the ideas Go left behind

#62

Post by MichaelGG »

0x434D53 wrote: post #56
MichaelGG wrote: post #45

Earlier quoted context omitted.

Why isn't a byte slice a valid key? If anything, there should be a pretty straightforward equality check on an array of bytes.

A slice is not an array of bytes. That's exactly the point. See http://blog.golang.org/go-slices-usage-and-internals to get a basic understanding

OK so I've read it. Slices sound exactly like one would guess, using the word from other languages. A view into an array.

So exactly why are they not suitable for equality? Even that article starts with "Slices are analogous to arrays in other languages". Please elaborate on this basic thing.

Re: Simplicity and the ideas Go left behind

#64

Post by 0x434D53 »

MichaelGG wrote: post #62
0x434D53 wrote: post #56

Earlier quoted context omitted.

A slice is not an array of bytes. That's exactly the point. See http://blog.golang.org/go-slices-usage-and-internals to get a basic understanding

OK so I've read it. Slices sound exactly like one would guess, using the word from other languages. A view into an array. So exactly why are they not suitable for equality? Even that article starts with "Slices are analogous to arrays in other languages". Please elaborate on this basic thing.

For an array (which are value types in go) you have the obvious element-wise equality.

For slices? Also element-wise? Even with different capacities? If the refer to the same window in the underlying array? Is there a need to copy the slice for inserting it to the map? Probably yes, because otherwise you could mutate the key from outside. But then it would be inconsistent to assignment (slices are reference types).

I have no idea how this could be done concisely.

Re: Simplicity and the ideas Go left behind

#65

Post by NateDad »

manu3000 wrote: post #20
nexneo wrote: post #16

Earlier quoted context omitted.

Go depends on tools to check correctness that type system doesn't cover. Check, http://blog.golang.org/error-handling-and-go and https://github.com/kisielk/errcheck

errcheck actually tries to give you what you get for free with a type system (if you have option types)

You and I have vastly different definitions of "free", I think.

Re: Simplicity and the ideas Go left behind

#66

Post by MichaelGG »

0x434D53 wrote: post #64
MichaelGG wrote: post #62

Earlier quoted context omitted.

OK so I've read it. Slices sound exactly like one would guess, using the word from other languages. A view into an array. So exactly why are they not suitable for equality? Even that article starts with "Slices are analogous to arrays in other languages". Please elaborate on this basic thing.

For an array (which are value types in go) you have the obvious element-wise equality. For slices? Also element-wise? Even with different capacities? If the refer to the same window in the underlying array? Is there a need to copy the slice for inserting it to the map? Probably yes, because otherwise you could mutate the key from outside. But then it would be inconsistent to assignment (slices are reference types). I…

Yes, element wise, why anything else? Different lengths are not equal; if capacity is externally visible, then that needs to be part of the compare.

As far as the whole ownership issue, that's a bit more than just ==, isn't it? Equality was the only thing I was questioning.

Re: Simplicity and the ideas Go left behind

#67

Post by SixSigma »

SixSigma wrote: post #57
justincormack wrote: post #54

Earlier quoted context omitted.

Ok, here is strace of date(1), which is dynamically linked, on Alpine Linux which uses Musl libc not glibc. execve("/bin/date", ["date"], [/* 16 vars */]) = 0 mprotect(0x7777dcd5a000, 4096, PROT_READ) = 0 mprotect(0xdc2d89a3000, 4096, PROT_READ) = 0 arch_prctl(ARCH_SET_FS, 0xdc2d89a4268) = 0 set_tid_address(0xdc2d89a4298) = 2439 clock_gettime(CLOCK_REALTIME, {1424769563, 611556639}) = 0 open("/etc/localtime", O_RDONL…

That is worlds apart.

OpenBSD's ktrace is similar

31144 date CALL readlink(0x3c001c16,0xcfbe7048,0x3f)

31144 date NAMI "/etc/malloc.conf"

31144 date RET readlink -1 errno 2 No such file or directory

31144 date CALL open(0x3c001967,0)

31144 date NAMI "/etc/localtime"

31144 date RET open 3

31144 date CALL open(0xcfbde9d4,0)

31144 date NAMI "/usr/share/zoneinfo/posixrules

31144 date RET open 3

Re: Simplicity and the ideas Go left behind

#68

Post by SixSigma »

lmm wrote: post #60
SixSigma wrote: post #41

It is interesting that the OP things that static binaries is related to being born in Google. The thing is that Plan9 doesn't have shared libraries, all binaries are statically linked. And the reason for this is that plan9 is a networked operating system, needing to load multiple files at runtime would severely harm startup time for a binary. Run trace on a Linux binary and see the slew of "file not found" errors fro…

Static binaries are bad design as soon as a library has a security flaw. Remember when there was a double free in zlib and Apple had to release a 1.3GB patch to update everything that linked it in statically - and even that only fixed the problem for Apple-official programs, not for anything the user had installed?

recompiling all of plan9 takes about 15 minutes

Re: Simplicity and the ideas Go left behind

#69

Post by peterfirefly »

misframer wrote: post #21
bsder wrote: post #10

Earlier quoted context omitted.

Congratulations. Welcome to why you don't use Go. Lack of generic access to data structures is one of their bigger fails. However, they don't see it that way. One point of Go was to prevent needing to describe things before being able to compile it. Most things that people regard as "failures" in Go were deliberate choices to enable large codebases.

No, that's not why you don't use go. What the parent comment is dealing with is the fact that you can't have maps keyed by a net.IP, which is implemented as a []byte. Byte slices are not valid keys. This isn't really about generics.

It is very much about polymorphism and generics.

Re: Simplicity and the ideas Go left behind

#70

Post by peterfirefly »

Padding wrote: post #61
Daishiman wrote: post #12

This answer is slightly infuriating: > Q: Lack of generic collection classes like in Java’s Guava library?A: For 90% of cases, slices and maps do what you need. For the other 10%, you might consider whether your package should own the logic of those special containers, instead of using an external package. I read this as: "We're not willing to put in the hard work on thinking of a decent generics implementation, desp…

> despite decades of working solutions Which "working" solutions? Has anyone solved creating a type system that offers OO/inheritance, generics, mutability and isn't mind-bogglingly complex? What is your definition for a "working" solution? I don't think any of the current languages we have fit this description, since all of them are capable of producing type errors that are way too complex to comprehend. > with a my…

What would you want OO for? First-class functions + HM + typeclasses work fine.
Post reply on HN