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

31–40 of 91 posts

Re: Simplicity and the ideas Go left behind

#31

Post by TheDong »

davecheney wrote: post #26
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.

He is not putting words in your mouth, he's stating his own interpretation.

No sane person would read "I read this as" and assume that this is in fact exactly what the speaker said, nor should any speaker assume "I read this as" is meant as a defamation or misquote.

In addition, you being a contributor not a core team member does not change what you said in the least. A language's design, even if it seems like there's a tight core, is ultimately decided in part by all contributors and the community around it as well.

Re: Simplicity and the ideas Go left behind

#32

Post by TheDong »

misframer wrote: post #29
kmontrose wrote: post #25

Earlier quoted context omitted.

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?

Go encourages working in that way, so yes, it is.

With other languages, you might do code generation through powerful macros (e.g. as rust has) or some other tooling which is not literally just "run a program in the user's path".

Re: Simplicity and the ideas Go left behind

#33

Post by pacala »

iopq wrote: post #27
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

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 a…

The jury is out on whether, for large time frames and for large communities, having a centralized type system is better than having a decentralized set of independent tools.

I'm not very excited by GHC's model of language extensions, https://downloads.haskell.org/~ghc/6.12.2/docs/html/users_gu.... And in spite of the large number of Haskell extensions, there are still pragmatic niches that aren't covered, see for example Rust's encoding of memory management in the type system.

In a sense, GHC contains a ad-hoc, informally-specified, bug-ridden, slow implementation of half of the type checker of Coq ;) Which is to say that there are many flavors of sophisticated type systems, and it's not clear which flavor is most conducive for writing good software on a tight time budget.

Re: Simplicity and the ideas Go left behind

#34

Post by davecheney »

TheDong wrote: post #31
davecheney wrote: post #26

Earlier quoted context omitted.

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.

He is not putting words in your mouth, he's stating his own interpretation. No sane person would read "I read this as" and assume that this is in fact exactly what the speaker said, nor should any speaker assume "I read this as" is meant as a defamation or misquote. In addition, you being a contributor not a core team member does not change what you said in the least. A language's design, even if it seems like there'…

The use of the opening phrase "We're not willing ... " implies that the OP interpreted my statements as a policy of the wider Go team.

I have no knowledge of any such policy and represent only myself on stage. You can think what you like about my statements, just don't generalise them to anyone else.

Re: Simplicity and the ideas Go left behind

#35

Post by Daishiman »

davecheney wrote: post #26
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.

This is my own personal opinion on core dev's position and no one else's, but to me generics and dependency management have always been the pink elephant in the room.

I can wait for features; I'm patient. But the downright refusal of Go's core team to even begin to address this issue is not just a technical problem, but a communications one. This is clearly big for a lot of people, and I have yet to see any serious responses aside from either "you domain model's wrong if you need generics" or "deal with it".

In contrast (just picking this language for its community outreach, not because of any perceived technical competition), Rust's core devs have been forthcoming about practically every objection they've gotten. Their answers are clear, detailed, not demeaning, and constructive. When they don't know, they're honest about it, and when answers are hard, they take the time to explain. But I have never heard of anyone being belittled for not understanding lifetimes or the borrow checker.

Yet it seems that somehow if I have a bone to pick with Go not being able to dispatch functions by argument or arity, or with how its simplicity ends up with codebases a lot of people would consider much more verbose than necessary, it's just that I don't "get it". The problem isn't even in the accusation; I just don't even receive examples or reasonable explanations, something I'm used to in related language discussions.

I was willing to give the language a pass on these things when it was just getting started and a lot of the classical, early product criticisms were abound. But it's gotten tiring; the number of unanswered questions is remarkable by now.

Re: Simplicity and the ideas Go left behind

#36

Post by kmontrose »

misframer wrote: post #29
kmontrose wrote: post #25

Earlier quoted context omitted.

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?

My point is that `go generate` requires more than just source, and thus isn't "simpler" in the manner claimed in the article.

I'm not judging the existence of `go generate` or it's merits relative to some other environments. Except makefiles. Makefiles are worse.

Re: Simplicity and the ideas Go left behind

#37

Post by threeseed »

georgemcbay wrote: post #8
dengnan wrote: post #7

Earlier quoted context omitted.

IIRC, Canonical joined the go community around 2010/2011 when docker has not been created. They are actually one of the early adopters of Go. Some major projects from Canonical using Go are juju[0], mgo[1], etc. 0. https://juju.ubuntu.com/ 1. https://labix.org/mgo Edit: format.

Also go-qml

Interesting.

Perhaps Go becomes the language for Ubuntu Phone apps ?

Re: Simplicity and the ideas Go left behind

#38

Post by chorizos22 »

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.

What?. A map key type should be parameterized type. Ergo, it is about generics.

Re: Simplicity and the ideas Go left behind

#39

Post by mpweiher »

Animats wrote: post #15
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…

> Better ways to plug programs together are needed

Yes! Maybe a language with direct support for software architecture, such as defining + (re-)using your own connectors.

Re: Simplicity and the ideas Go left behind

#40

Post by rtpg »

TheDong wrote: post #30
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)

Even in a simple language, simple things should be simple. Granted, it's easy to make complex things sound simple, but the example given seems simple.
Post reply on HN