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

221–230 of 257 posts

Re: Half a decade with Go

#221

Post by howeman »

_ak wrote: post #168
lmm wrote: post #130

Earlier quoted context omitted.

There is no escape. The language thinks it knows better than you. The standard library is allowed to do things that your code isn't.

Like what? The standard library is no more special, other than where it resides in the filesystem. You can write C and assembly code as well and link it to your Go code. And I'm not talking about cgo, I mean [568][ac], the Plan 9 C compiler and assembler that come with Go.

Actually, the c compiler just got deleted.

https://groups.google.com/forum/#!topic/golang-codereviews/A...

Re: Half a decade with Go

#222

Post by AnimalMuppet »

dllthomas wrote: post #220
ansible wrote: post #219

Earlier quoted context omitted.

If I am unaware of an interface, I don't know to avoid the names used in that interface, and I don't know to abide by the invariants assumed in that interface. That seems like it will bite people who've done nothing wrong. If I am providing a library, I can't possibly be aware of every interface anyone might define in code that uses it. I've no clue how frequently this will occur, in practice. That's not a problem wi…

It's entirely possible that I just don't know enough about go's interfaces. Wasn't it explicitly stated up-thread that you don't need to name the interfaces you support? If that's the case, I don't see how you get around the possibility of a type seeming to support (because of what's defined for it) an interface that it doesn't (because those functions actually do other things - obviously or subtly).

Here's a (very contrived) example of what I think you mean.

Here's a container interface. It has a sort() method, which sorts the elements of the container.

Here's a different container interface. It's got a method that tells you what kind of concrete container you have, so you can understand how expensive actions like insert and sort are going to be. But the author was from England, and so called that method "sort".

You can see how that's going to (fail to) work out when you define a "sortable" interface...

Re: Half a decade with Go

#223

Post by dllthomas »

AnimalMuppet wrote: post #222
dllthomas wrote: post #220

Earlier quoted context omitted.

It's entirely possible that I just don't know enough about go's interfaces. Wasn't it explicitly stated up-thread that you don't need to name the interfaces you support? If that's the case, I don't see how you get around the possibility of a type seeming to support (because of what's defined for it) an interface that it doesn't (because those functions actually do other things - obviously or subtly).

Here's a (very contrived) example of what I think you mean. Here's a container interface. It has a sort() method, which sorts the elements of the container. Here's a different container interface. It's got a method that tells you what kind of concrete container you have, so you can understand how expensive actions like insert and sort are going to be. But the author was from England, and so called that method "sort".…

Right, thank you!

Traditional (but even more contrived) examples include "draw" and "fire" doing unexpected things when applied to a gun as opposed to an image or an employee.

Re: Half a decade with Go

#224

Post by ansible »

dllthomas wrote: post #220
ansible wrote: post #219

Earlier quoted context omitted.

If I am unaware of an interface, I don't know to avoid the names used in that interface, and I don't know to abide by the invariants assumed in that interface. That seems like it will bite people who've done nothing wrong. If I am providing a library, I can't possibly be aware of every interface anyone might define in code that uses it. I've no clue how frequently this will occur, in practice. That's not a problem wi…

It's entirely possible that I just don't know enough about go's interfaces. Wasn't it explicitly stated up-thread that you don't need to name the interfaces you support? If that's the case, I don't see how you get around the possibility of a type seeming to support (because of what's defined for it) an interface that it doesn't (because those functions actually do other things - obviously or subtly).

OK, now I understand. It may be possible to muck things up if you've got two different types (from different packages) that have the exact same signatures for all the functions defined in the interfaces.

It doesn't seem like a high probability that this would happen on accident, though it might be possible to contrive an example.

I'll have to think about that.

Re: Half a decade with Go

#225

Post by raverbashing »

lucozade wrote: post #201
raverbashing wrote: post #187

Earlier quoted context omitted.

Just keep in mind Go IS NOT like python, but instead it's a better C I'd say it's a better C, not a better C++ (or Java/C#)

As a language maybe but for usage, not so much. For me, most modern uses of C fall into 3 camps: + extreme portability + complete, low level resource control + foundational libraries And Go doesn't really qualify for any of these. For the latter 2 largely because of the GC. I think in practice, that its engineering bent i.e. no frills language and high quality tooling, will more likely see it being used in the server…

"As a language maybe but for usage, not so much"

Yeah, I agree with your points. Which is a shame really.

Re: Half a decade with Go

#226

Post by lmm »

jshen wrote: post #217
lmm wrote: post #137

Earlier quoted context omitted.

> If languages like Haskell and Erlang gave a competitive advantage, wouldn't we see companies which used them succeeding over those that don't? We are. WhatsApp generated a flurry of interest around Erlang. Heroku uses it. I'm sure there are more examples. Google is at this point already a large corporation and probably already in decline (IMO). The tools they use are optimized for interchangeability of mediocre pro…

You are seeing companies that use those languages suceeding at a higher rate than those that don't? I bet I can find 10 succeeding that use ruby or node for everyone that uses Erlang. We could also look at the open source world. For every riak there are 10 java sucesses of a similar kind. We'd need to do some real statistics but my bet is that we see no benefit from those languages in terms of success of the business…

> I bet I can find 10 succeeding that use ruby or node for everyone that uses Erlang.

But that's not the question, is it? There are a lot of companies succeeding with ruby or node, but also a lot of companies failing with them. I'll bet the strike rate is better for Erlang companies.

Re: Half a decade with Go

#227

Post by MetaCosm »

jesstaa wrote: post #147
_pmf_ wrote: post #134

Earlier quoted context omitted.

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

Yeah, I simply think that this is hard to explain in a comment how useful and easy it is. But, I gave it my best Go...

Re: Half a decade with Go

#228

Post by AnimalMuppet »

meowface wrote: post #75
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…

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 problem with the Blub essay is precisely the assumption that all languages can be ranked on a one-dimensional axis called "power". That assumption is false. (I know this is heresy to say on HN, but in this essay, PG is simply wrong.)

I'm repeating myself here, but: A Haskell user and a Lisp user are both sure that they're at the top of the power curve, and they're both sure that they're looking down when they're looking at the other language, and they can both tell you precisely why they're sure they're looking down ("It doesn't even have a decent type system" and "It doesn't even have macros", respectively). But they can't both be looking down. What's wrong here?

What's wrong is the assumption that all languages can be ranked by a one-dimensional attribute called "power".

Or look at it another way: Power? Power for what? Well, for writing programs. But what kind of programs? General programs? I've never written a general program in my life; I've only written specific ones. Then "power" is whatever's going to make it easier to write the program I need to write. Whatever language does that is the "most powerful" language for the problem I'm facing.

What power is Go shooting for? It's the power to write a ten-million-line application and have it be maintainable for two or three decades. (That's not my guess; it's what Rob Pike said the language goals are.) If you face that kind of problem, Go may in fact be a very powerful language.

Re: Half a decade with Go

#229

Post by dllthomas »

ansible wrote: post #224
dllthomas wrote: post #220

Earlier quoted context omitted.

It's entirely possible that I just don't know enough about go's interfaces. Wasn't it explicitly stated up-thread that you don't need to name the interfaces you support? If that's the case, I don't see how you get around the possibility of a type seeming to support (because of what's defined for it) an interface that it doesn't (because those functions actually do other things - obviously or subtly).

OK, now I understand. It may be possible to muck things up if you've got two different types (from different packages) that have the exact same signatures for all the functions defined in the interfaces. It doesn't seem like a high probability that this would happen on accident, though it might be possible to contrive an example. I'll have to think about that.

Certainly the larger an interface is, the less likely that someone supports all of it by accident. Of course, that's both good and bad - if the accidental support would have been correct then we're missing out, but I think most of the time we shouldn't count on that.

One could possibly force the issue by including an unused function with a deliberately unique name (supports_interface_foo, or maybe a UUID or both) as part of the interface. Can functions added later fill parts of interfaces? If so, this approach would make the situation roughly that of Haskell typeclasses. If not, then this approach makes the situation roughly that of Java interfaces. In either case, it might be appropriate to some pickier interfaces.

Re: Half a decade with Go

#230

Post by AnimalMuppet »

wwweston wrote: post #44
kjksf wrote: post #16

Earlier quoted context omitted.

You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer. Some people see languages as a bag of features (immutability! generic programming! laziness! operator overloading! algebraic types! hindley-miller type inference! pattern matching! exceptions! manual memory management!). See http://yager.io/programming/go.html for an example of that line of think…

> You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer. This line of thinking serves more to call in to question the engineering and management cultures we have than it does to reflect poorly on Haskell and Erlang, and if it's true that Go's essential strength compared to them is that it is well-fitted to these cultures, that's not particularly flat…

That sounds almost like denial to me. "If everybody doesn't adopt what I think they should, it has to be because they're dysfunctional! It can't be because the stuff I like is less generally applicable than I think it is!"

If people disagree with you, your default assumption should be that they are looking at different evidence than you, not that they are incompetent or stupid.

Post reply on HN