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

11–20 of 91 posts

Re: Simplicity and the ideas Go left behind

#11

Post by bsder »

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…

I like the fact that the Go guys continue to avoid talking in detail about Rust and Clojure.

That tells me that the don't think they can win the comparison.

Re: Simplicity and the ideas Go left behind

#12

Post by Daishiman »

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, despite decades of working solutions with a myriad of choices in tradeoffs, 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, and with the slight bugs that come from not having a well-trodden path for an essential component of most programming languages."

Re: Simplicity and the ideas Go left behind

#13

Post by iopq »

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 `Option` instead of `T` itself.

The code snippets on the websites are far from simple. You HAVE TO remember to do `if err != nil` in every single function. A more advanced type system would actually make this a requirement.

So what is more important, the simplicity of the language or lack of bugs?

Re: Simplicity and the ideas Go left behind

#14

Post by panic »

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.

Re: Simplicity and the ideas Go left behind

#15

Post by Animats »

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…

This oversells golang's simplicity I think. Not a lot, but enough to rub me the wrong way a tiny bit.

True. Go is a good language for server-side web stuff. That alone is enough to make it very useful. It is a good language for when you want to get server stuff done and it has to go fast. That's enough. It doesn't need to be overhyped.

Go is helping pioneer a command-line renaissance that reintroduces a generation of programmers to the idea of writing tools that fit together like segments in a pipe (the original Unix philosophy).

That's inherently a batch processing approach. The "strings through a one-way pipe" approach was never that great. It's brittle. If anything goes wrong, the options are to abort the whole thing, or print a message to stderr which will probably be ignored.

Better ways to plug programs together are needed, but Go doesn't do much new in that direction. Today, plugging programs together probably involves a number of programs which use protocol buffers to communicate, running on, say, Amazon AWS. There's much work going on in tools for doing that. They aren't typically pipe-oriented.

Re: Simplicity and the ideas Go left behind

#16

Post by nexneo »

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

Re: Simplicity and the ideas Go left behind

#17

Post by [deleted] »

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.

[deleted]

Re: Simplicity and the ideas Go left behind

#18

Post by nostrademons »

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

Isn't this just layering another, non-standard type system on top of the language itself? After all, a type system is no more than a tool to check the correctness of programs. (And often, document the assumptions that the programmer made.)

I don't think this is a bad thing in and of itself - I like how languages like Python, Lisp, Javascript, and Erlang have been able to layer typesystems on top without building them into the language itself. But I wouldn't exactly hold it up as an example of simplicity, particularly since in those languages the community hasn't agreed on any one type system.

Re: Simplicity and the ideas Go left behind

#19

Post by misframer »

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.

Re: Simplicity and the ideas Go left behind

#20

Post by manu3000 »

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

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