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

Replacing Clever Code with Unremarkable Code in Go

vividcortex.com

Post reply on HN
Print view View original

131–140 of 140 posts

Re: Replacing Clever Code with Unremarkable Code in Go

#131

Post by mietek »

masklinn wrote: post #127
enneff wrote: post #118

Earlier quoted context omitted.

What I get from your comment is that option types work well in Haskell and Scala. This doesn't surprise me, as both languages places a strong emphasis on the type system, and so they are easily supported. For option types to work well in Go you would need to add more support to the type system. But we don't want a more complex type system. That's a tradeoff we made. Again, I'm not really sure why people keep getting…

> What I get from your comment is that option types work well in Haskell and Scala. This doesn't surprise me, as both languages places a strong emphasis on the type system, and so they are easily supported. Option types need no type system support beyond having option types at all. Think of an option type as a container. It's either empty, or it has a single element inside it. You can manipulate your container by che…

Yes. Also, these low-level primitives already exist in Go, as support for pointers, or references. The missing bit is requiring references to be explicitly annotated as nullable or non-nullable.

Re: Replacing Clever Code with Unremarkable Code in Go

#132

Post by mietek »

dsymonds wrote: post #125
azth wrote: post #123

Earlier quoted context omitted.

I was mainly referring to function arguments. Any function that takes a pointer type has to have null checks at the beginning, since any of the pointer arguments may be null.

"has to" is a bit strong. The standard assumption is that pointer arguments should be set (or the function is documented otherwise), and the responsibility is left with the caller. It just bubbles out from there.

Yes, this is the way things have been done since 1965. It sounds simple enough, but as it turns out, in complex systems, this is a common cause of defects.

Programmers forget to check things all the time. Assumptions made in different areas of the code, by different programmers, at different times, do not always hold.

Fortunately, computers are good at remembering to check things. We just need to allow them to do so.

Re: Replacing Clever Code with Unremarkable Code in Go

#133

Post by papsosouid »

ominous_prime wrote: post #83
papsosouid wrote: post #37

Earlier quoted context omitted.

>I'm not sure what your point is, whether you think go is simple and powerful like lisp, or the new java Really? I find it hard to believe you can't tell what is intended. It certainly is applicable to the article, as the article can be summarized as "I've moved up a language on the blub line, and now my old perfect language is clearly inferior, but my new blub is perfection incarnate".

The main point of the article: > One of the things I like about Go is that it offers much better ways to write things that you’d usually write with callbacks. I fail to see how saying that one likes replacing callbacks with channels translates to saying Go is "perfection incarnate". Go isn't perfect, but they hit a really good subset of features that a lot of people find very productive. I, and many others that use g…

>I fail to see how saying that one likes replacing callbacks with channels translates to saying Go is "perfection incarnate".

It isn't. It is saying "I don't realize that this is actually worse than what lots of languages provided before go even existed, so I think it is awesome". Which is the point of the blub response. Go isn't interesting, it is blub.

Re: Replacing Clever Code with Unremarkable Code in Go

#134

Post by stcredzero »

gngeal wrote: post #58
mwcampbell wrote: post #49

Earlier quoted context omitted.

Reminds me of this old Zed Shaw essay: http://zedshaw.com/essays/master_and_expert.html I think at least two of Go's designers, Ken Thompson and Rob Pike, are true programming masters. Note: When I posted this comment before, I accidentally pasted the wrong URL.

I’d love someday to hear a young coder tell a story about someone they idolized like, “There was this guy I worked with who once optimized a complicated red- black tree getting 300% performance boost. I was baffled and ask, ‘How’d you do that? That’s impossible.’ To which he responded…” “‘That’s my linked list my son.’” I believe that this is exactly what Niklaus Wirth did in the Oberon compiler.

You sure it wasn't skip lists?

Re: Replacing Clever Code with Unremarkable Code in Go

#135

Post by jmilkbal »

mietek wrote: post #100
jmilkbal wrote: post #95

Earlier quoted context omitted.

I recall the launch documentation specifically saying generics are "... a work in progress". Ignoring academic progress is easy when programming is far more often a trade than the application of computer science. I once saw a video comparing Go to an unnamed which matched or surpassed Go in all the ways the video compared the two. The language was Algol 60. Naturally, can't find the video now.

I haven't seen the video, but here's the article: http://cowlark.com/2009-11-15-go/

Yeah and this comment on another thread is probably spot on.

http://news.ycombinator.com/item?id=5078276

I don't really find Go compelling, but I can understand the background some folks might be coming from that might make it compelling for them.

Re: Replacing Clever Code with Unremarkable Code in Go

#136

Post by gngeal »

stcredzero wrote: post #134
gngeal wrote: post #58

Earlier quoted context omitted.

I’d love someday to hear a young coder tell a story about someone they idolized like, “There was this guy I worked with who once optimized a complicated red- black tree getting 300% performance boost. I was baffled and ask, ‘How’d you do that? That’s impossible.’ To which he responded…” “‘That’s my linked list my son.’” I believe that this is exactly what Niklaus Wirth did in the Oberon compiler.

You sure it wasn't skip lists?

Not unless he had a TARDIS at his disposal. I mean, skip lists were discovered in 1989, and by that time, the Oberon compiler had already existed for a few years. I don't recall the source now (I'd have to dig for it) but I believe that the Wirth anectode referred to his intervention in a case of overzealous students some time before that.

Re: Replacing Clever Code with Unremarkable Code in Go

#137

Post by gohrt »

azth wrote: post #81
gohrt wrote: post #34

Earlier quoted context omitted.

That's only true in a language with type inference and type aliases. In Java, generics make your code completely unreadable, as content is buried in boilerplate. Map ,ReadyState ops; for (Entry ,ReadyState e: ops.entrySet()) { ... In Go, generics would be an unqualified win for the author/reader. No one disputes that. The only dispute is over the compiler and runtime costs.

That's a straw man I believe. Furthermore, other languages seem to have got this right without the fabled runtime/compiler costs that the Go authors seem to talk about (see D for instance). What's funny is that there are runtime costs today in Go that could have been resolved by using generics. All interface calls are virtual calls, and cannot be inlined. > No one disputes that. Citation needed. I read and heard from…

I can't cite my claim that "no one" does something. I'm happy to see any example you provide of the Go team/nuts saying that generics are a bad language idea.

Russ Cox, a core Go dev: http://research.swtch.com/generic

Re: Replacing Clever Code with Unremarkable Code in Go

#138

Post by mietek »

jmilkbal wrote: post #135
mietek wrote: post #100

Earlier quoted context omitted.

I haven't seen the video, but here's the article: http://cowlark.com/2009-11-15-go/

Yeah and this comment on another thread is probably spot on. http://news.ycombinator.com/item?id=5078276 I don't really find Go compelling, but I can understand the background some folks might be coming from that might make it compelling for them.

I completely agree with this comment.

Re: Replacing Clever Code with Unremarkable Code in Go

#139

Post by masklinn »

comex wrote: post #128
masklinn wrote: post #126

Earlier quoted context omitted.

> I want generics precisely because they can provide equal performance to the built-in collections That is most definitely not the core use case for generics. They can be lifted into type-specialized collections, but the core point of generics is type safety .

Fair enough. Although my priorities somewhat differ from the norm, the document you criticized elsewhere does cite runtime overhead as a significant obstacle.

> the document you criticized elsewhere does cite runtime overhead as a significant obstacle.

And as I noted in my criticism it is completely wrong in doing so: the runtime overhead it notes is boxing in Java, ascribing it to generics.

But boxing is not a property of java's generics, it's a property of java's collections, java collections have required boxing value types since the first release (~1996), generics were only introduced in 2004. The boxing in java collections is orthogonal to generics.

In fact, one of the properties of C#'s reified generics is that it allows the compiler and runtime to avoid object (boxed) collections when it can use unboxed collections for value types.

Re: Replacing Clever Code with Unremarkable Code in Go

#140

Post by comex »

masklinn wrote: post #139
comex wrote: post #128

Earlier quoted context omitted.

Fair enough. Although my priorities somewhat differ from the norm, the document you criticized elsewhere does cite runtime overhead as a significant obstacle.

> the document you criticized elsewhere does cite runtime overhead as a significant obstacle. And as I noted in my criticism it is completely wrong in doing so : the runtime overhead it notes is boxing in Java, ascribing it to generics. But boxing is not a property of java's generics, it's a property of java's collections , java collections have required boxing value types since the first release (~1996), generics we…

True. The author is smart, and I would like to believe that he knew that reified unboxed collections would solve the space problem, but possibly be even worse than Java in time, since there is no JIT to inline repeated virtual calls to the same target. I can't guarantee that he did. ;p
Post reply on HN