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

Three Months of Go from a Haskeller’s perspective (2016)

memo.barrucadu.co.uk

Post reply on HN
Print view View original

161–162 of 162 posts

Re: Three Months of Go from a Haskeller’s perspective (2016)

#161

Post by eru »

mcguire wrote: post #140
wwright wrote: post #82

Earlier quoted context omitted.

Ada has this without general dependent types AFAIK

Yes and no. The definitions are in the type system, but the checks are done at runtime, just like you would do manually. You don't really get the benefit of typing. The reason I can say that: you don't have to provide proofs that a value has to be positive to get things to compile.

Checks at runtime are also a good idea, but yes, very different from static dependent types.

There's some interesting work on making such contracts work well in a lazy language with higher-order functions.

Re: Three Months of Go from a Haskeller’s perspective (2016)

#162

Post by simiones »

bankisan wrote: post #119
simiones wrote: post #113

Earlier quoted context omitted.

Given that there is no way to make a non-pointer map in Go, there is no workaround for the example they gave. The broader point is that there is no way in Go to ensure that data passed over a channel will not be modified concurrently without modifying the type of the data specifically for the channel use case. A deep_copy() primitive would fix this.

Right, but they mentioned sending immutable structs which is why I gave the struct example. But you're right that every declared map is a just a pointer. With respect to your second point, I see what you mean but I still don't think that's a negative of Go. You can pass in copied values without having to have a deep_copy() primitive (loop map values and copy to new map, dereferencing a pointer, etc.). Like other part…

> With respect to your second point, I see what you mean but I still don't think that's a negative of Go.

It is a negative of Go, because Go pushes you into the pit of failure by its design: it is much, much harder to do the right thing (send deep copies of objects over channels) than it is to do the wrong things (send pointers or shallow copies over channels).

Post reply on HN