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

21–30 of 91 posts

Re: Simplicity and the ideas Go left behind

#21

Post by misframer »

bsder wrote: post #10
codexon wrote: post #3

I was using Go recently and I ran into some simplicity issues. It is not straightforward to create a map of net.IPs or manipulate netmasks. You will have to copy to and from a separate array/integer.

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.

Re: Simplicity and the ideas Go left behind

#22

Post by WalterBright »

nexneo wrote: post #16
iopq wrote: post #13

Consider the following: it is actually more difficult to code in a language that's simple Why? Because a more feature-complete language allows you to ELIMINATE the concept of `nil` through an `Option` type. An `Option` type is an `enum` that consists of either `Some(x)` or `None`. That means it is always checked. You can never accidentally use a value that is `None` because the type checker would not let you use `Opt…

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

One of the goals of the D programming language is to render add-on tools like 'lint' and 'coverity' redundant.

Re: Simplicity and the ideas Go left behind

#23

Post by WalterBright »

panic wrote: post #14
iopq wrote: post #13

Consider the following: it is actually more difficult to code in a language that's simple Why? Because a more feature-complete language allows you to ELIMINATE the concept of `nil` through an `Option` type. An `Option` type is an `enum` that consists of either `Some(x)` or `None`. That means it is always checked. You can never accidentally use a value that is `None` because the type checker would not let you use `Opt…

Exactly. If simplicity were the most important thing, we'd all be writing code in Forth or some sort of macro assembler.

It's true that assembler is actually pretty simple. It's just that the simple instructions combine in hard to understand ways.

Re: Simplicity and the ideas Go left behind

#24

Post by misframer »

codexon wrote: post #3

I was using Go recently and I ran into some simplicity issues. It is not straightforward to create a map of net.IPs or manipulate netmasks. You will have to copy to and from a separate array/integer.

net.IP is implemented as a []byte. Byte slices are not valid keys (you can't use the "==" operator).

An alternative would be to use [16]byte as your map keys and then subslice the array for net.IP.

Re: Simplicity and the ideas Go left behind

#25

Post by kmontrose »

misframer wrote: post #19
kmontrose wrote: post #9

This oversells golang's simplicity I think. Not a lot, but enough to rub me the wrong way a tiny bit. --- > Go programs are built from just their source, which includes all the information needed to fully build the program. Still have to deal with GOPATH, vendor your dependencies, and have everything a `go generate` comment wants to invoke. It's certainly better than makefiles, but it's hardly just the source. > C# i…

Package users should not have to run "go generate". It's mainly for package writers to generate code and then distribute it.

And? Presumably some of these packages get updated, handed off, or are collaborative in the first place. Re-generating is part of continuing development.

Re: Simplicity and the ideas Go left behind

#26

Post by davecheney »

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…

I am not a member of the Go team, just a contributor. I represent only my own opinions, please don't put words into my mouth.

Re: Simplicity and the ideas Go left behind

#27

Post by iopq »

nexneo wrote: post #16
iopq wrote: post #13

Consider the following: it is actually more difficult to code in a language that's simple Why? Because a more feature-complete language allows you to ELIMINATE the concept of `nil` through an `Option` type. An `Option` type is an `enum` that consists of either `Some(x)` or `None`. That means it is always checked. You can never accidentally use a value that is `None` because the type checker would not let you use `Opt…

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

That's the answer for everything in the Go community. More ad-hoc tools to replace the type system. Have concurrency bugs? Use a tool that detects some types of data races. Have problems with errors? Have a tool that detects not checking for errors.

How is approaching every single problem with a different tool more simple than using the type system as the one tool for static checking? The Go ecosystem is creating a ad-hoc, informally-specified, bug-ridden, slow implementation of half of the type checker of Haskell.

Re: Simplicity and the ideas Go left behind

#28

Post by davecheney »

fineIllregister wrote: post #5

>He currently works at Canonical, where part of his work involves porting Go to ARM 64. That's interesting. Has Canonical stated what their interest in Go is?

Go is an open source project, Canonical sponsor Go in part by paying my salary. Canonical have been building products in Go for three years.

Re: Simplicity and the ideas Go left behind

#29

Post by misframer »

kmontrose wrote: post #25
misframer wrote: post #19

Earlier quoted context omitted.

Package users should not have to run "go generate". It's mainly for package writers to generate code and then distribute it.

And? Presumably some of these packages get updated, handed off, or are collaborative in the first place. Re-generating is part of continuing development.

Sure, but that's not specific to any language. Is it Go's fault that package writers work a certain way?

Re: Simplicity and the ideas Go left behind

#30

Post by TheDong »

codexon wrote: post #3

I was using Go recently and I ran into some simplicity issues. It is not straightforward to create a map of net.IPs or manipulate netmasks. You will have to copy to and from a separate array/integer.

That is not a simplicity issue.

"Something that is simple may take longer to write and might be more verbose" -- from the article.

In a simple language, there should not be functions that do exactly what you want to do; that would be a sign of the language being complex and featureful, which are enemies of simple.

(and yes, this is a bit tongue-in-cheek)

Post reply on HN