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

Half a decade with Go

blog.golang.org

Post reply on HN
Print view View original

141–150 of 257 posts

Re: Half a decade with Go

#141

Post by pjmlp »

enneff wrote: post #88
meowface wrote: post #75

Earlier quoted context omitted.

Going by Paul Graham's "Blub" essay ( http://www.paulgraham.com/avg.html ), I'd say the problem is that languages like Go and Java are simply not high in the rankings when it comes to power.

The underlying assumption is that the problem that modern programming languages should solve is lack of power. But I don't see that problem in modern codebases. In my experience, the problem is complexity.

> In my experience, the problem is complexity.

Simple languages led to complex code bases.

Many of the Enterprise Java sins were caused by the language limitations and developers trying to work around them.

Re: Half a decade with Go

#142

Post by ansible »

wwweston wrote: post #57
ansible wrote: post #47

Earlier quoted context omitted.

So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)? As discussed elsewhere on this page, Go is not the most feature-rich language out there. But it does have features that seem to help my solve my problems with a minimum amount of fuss. Like using interfaces liberally, instead of having to define classes. Having lex…

I like functions as first-class values and closures. If they weren't present, I might well have bailed months ago. :) And from various experiences doing OO with other languages, I can kindof buy that Go interfaces are often 80% of what you want. Most of what I've been working on is a Rest API. Here's an example of a problem that felt like it should be something for which I'd be able to write an abstraction to deal wi…

(Incidentally, though I moved past my then really poor understanding of Go interfaces, I wasn't able to apply the respondent's answer or my new general knowledge to achieve the abstraction I was looking for, and settled for just grinding out the same code for the dozen entities/endpoints it applied to.)

I definitely can't deny that using interfaces instead of regular OO classes takes some getting used to.

Though I don't understand why you had to grind out duplicate code for all the entities / endpoints though. I hacked up things a bit to get it to run on the playground, but as Jesse McNelis wrote, just passing the pointer to foo worked for the code you wrote.

http://play.golang.org/p/jNpK5CRBfv

Re: Half a decade with Go

#143

Post by Artemis2 »

callesgg wrote: post #119

I would really like to see go binaries that is not like a 1mb in size. In practice is not like I don't have space for 1MB But I still want proper linking to a shared "golib"

Only Go developers install the Go toolchain, so there's very little chance that your executable will work where you intend it to.

Re: Half a decade with Go

#144

Post by MetaCosm »

_pmf_ wrote: post #134
MetaCosm wrote: post #102

Earlier quoted context omitted.

Composition. That is the single biggest thing that has impressed me as my codebase has grown. Concurrency and messaging is nice, but I come from Erlang... I am not easily impressed by concurrency and messaging. Composition, the power of interfaces in complex systems is the key for me. It is what makes me stay with Go, and why I will probably stick around for a long time. It is so obnoxiously useful, without ever gett…

> Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). I've implemented InputStreams from byzantine transport layers in Java that work with the standard library. I don't quite understand what is special about this concept in Go (maybe it's nice for people coming from typeless, messy dynamic languages or nice languages with horribly inflexible and…

Go has nothing unique (and maybe that makes it special). I mean that sincerely, everything it has, has been done dozens of times. Interfaces in Go are implicit (which is important, IMHO) and really, tremendously simple. These two features make them exceptional easy to use, and ACTUALLY used.

I have used interfaces (or equivalent concepts) in dozens of languages and they always felt like far more of a chore, explicitly using X interface or Y interface, ugly complex declarative specs, etc. Go just makes it painless.

Re: Half a decade with Go

#145

Post by ansible »

ansible wrote: post #131
Animats wrote: post #96

Go has a rather specific purpose. It's intended for writing server-side web systems that will run fast and scale well. Since that's what Google does to make money, that makes sense. The available libraries reflect this - good support for dealing with many network connections at once, no GUI support. It's not suitable for writing an OS, hard real time, highly generic libraries, or GUI programs. Within its niche, it's…

The lack of exceptions forces far too many lines of "if err != nil { return err}", (or worse, a goto) which takes 3 lines of text every time. If I could go back in time, and discuss one thing with the designers, it would be to fix this. I'd rather see some kind of Option type (like in Rust) baked deep into the language. Maybe there would be a scheme where you could use these Option types as regular values. The moment…

The idiomatic way to do that in Go, however, can mask errors, like say if Close() returned an error, you might not see it if you just did a 'defer foobar.Close()' Those errors should go somewhere... somehow.

You can, of course fix that, by wrapping your Close() in an anonymous function that logs an error if Close() had a problem. But I don't see that often in other people's code, and it is cumbersome. There ought to be a better and more concise way to do this.

Re: Half a decade with Go

#146

Post by aangeles »

ansible wrote: post #142
wwweston wrote: post #57

Earlier quoted context omitted.

I like functions as first-class values and closures. If they weren't present, I might well have bailed months ago. :) And from various experiences doing OO with other languages, I can kindof buy that Go interfaces are often 80% of what you want. Most of what I've been working on is a Rest API. Here's an example of a problem that felt like it should be something for which I'd be able to write an abstraction to deal wi…

(Incidentally, though I moved past my then really poor understanding of Go interfaces, I wasn't able to apply the respondent's answer or my new general knowledge to achieve the abstraction I was looking for, and settled for just grinding out the same code for the dozen entities/endpoints it applied to.) I definitely can't deny that using interfaces instead of regular OO classes takes some getting used to. Though I do…

Regarding the sample code is "bson_*" is a bson code convention? I notice Mixed Caps [1]is the idiomatic code for go? TIA

[1]http://golang.org/doc/effective_go.html#mixed-caps

Re: Half a decade with Go

#147

Post by jesstaa »

_pmf_ wrote: post #134
MetaCosm wrote: post #102

Earlier quoted context omitted.

Composition. That is the single biggest thing that has impressed me as my codebase has grown. Concurrency and messaging is nice, but I come from Erlang... I am not easily impressed by concurrency and messaging. Composition, the power of interfaces in complex systems is the key for me. It is what makes me stay with Go, and why I will probably stick around for a long time. It is so obnoxiously useful, without ever gett…

> Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). I've implemented InputStreams from byzantine transport layers in Java that work with the standard library. I don't quite understand what is special about this concept in Go (maybe it's nice for people coming from typeless, messy dynamic languages or nice languages with horribly inflexible and…

You can make an io.Reader interface in any language. Interfaces don't really shine until you start composing them.

Say you have a type that implements the io.Reader, io.Writer, io.Closer and io.Seeker interfaces, eg. an os.File. This type would also automatically implement io.ReadCloser, io.WriteCloser, io.ReadWriter and io.ReadWriteCloser, io.ReadSeeker, io.ReadWriteSeeker, io.ReadWriteSeekerCloser, io.WriteSeeker, io.SeekCloser etc.

Re: Half a decade with Go

#148

Post by coldtea »

wwweston wrote: post #39

OK, I'll admit it. I've spent six months with Go. I keep waiting for the moment when I understand it, maybe even develop some enthusiasm for it, and reach Pike-enlightenment. And I pretty much hate the language. I feel like I'm writing in something that combines the worst weaknesses of Pascal and Java. In fact, Mark Dominus' comments about Java ( http://blog.plover.com/prog/Java.html ) approximate my experience Go fa…

>People who seem to be smart nevertheless keep talking it up... some not even as just a good tool but as their favorite language.

Being good enough, not knowing any better PL-wise, and the Stockhold Syndrome explains that.

Re: Half a decade with Go

#149

Post by coldtea »

MetaCosm wrote: post #102
wwweston wrote: post #39

OK, I'll admit it. I've spent six months with Go. I keep waiting for the moment when I understand it, maybe even develop some enthusiasm for it, and reach Pike-enlightenment. And I pretty much hate the language. I feel like I'm writing in something that combines the worst weaknesses of Pascal and Java. In fact, Mark Dominus' comments about Java ( http://blog.plover.com/prog/Java.html ) approximate my experience Go fa…

Composition. That is the single biggest thing that has impressed me as my codebase has grown. Concurrency and messaging is nice, but I come from Erlang... I am not easily impressed by concurrency and messaging. Composition, the power of interfaces in complex systems is the key for me. It is what makes me stay with Go, and why I will probably stick around for a long time. It is so obnoxiously useful, without ever gett…

>It reads data from reader and writes to writer... simple. Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). The first way you will probably use it will be to copy between some stream and a file without having to eat up all the memory to store the buffer (not using ioutil.ReadAll for example)... but then you realize you can use a gzip compressor on the writer side, or a network socket, or your own code... and io.Copy works with anything that fulfills its interface

And how is that any different than any language with interfaces? (Besides the implicit thing?).

Re: Half a decade with Go

#150

Post by Solarsail »

Svip wrote: post #132
stinos wrote: post #127

Earlier quoted context omitted.

Composition I read your comment, but this seems more like A sane standard library with proper interfaces and not a language feature per se (also composition to me sounds like the pattern where you create objects which are composed of other objects but that's not what you mean, right)? What you display here can be done in pretty much any language suporting inheritance (or I'm missing something), so your point is those…

I think the point here is implicit inheritance. There are many interfaces in Go, but you don't need to specify which interface you are implementing. So you can easily implement io.Reader and io.Writer among many others, without extending your type declaration for lines on end. This means that many standard types in Go implements either io.Reader and/or io.Writer. That's neat. The implicit interface implementation is…

Structural types, as opposed to nominal types?
Post reply on HN