Live data from Hacker News

Replacing Clever Code with Unremarkable Code in Go

vividcortex.com

81–90 of 140 posts

Re: Replacing Clever Code with Unremarkable Code in Go

#81
post #34

Earlier quoted context omitted.

If anything, generics reduce the mental expense of reading code, because if a container has a generic value type I know that it isn't going to be doing something interesting to those values behind the scenes.

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 many people that do.

Re: Replacing Clever Code with Unremarkable Code in Go

#83

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, but simply quoting "The Blub Paradox" makes you sound pretentious (on a site where the largest percentage of readers are probably already familiar with said essay nonetheless). I don't think this is really applicable to the article anyway, since it's an article commenting on two very different languages and progra…

>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 go, find that pragmatism worth the tradeoff.

Go makes what my co-workers and I do easier than other languages we've tried. Period. That's why we're using it. That's the reason other's I've communicated with have given as well. It's not a magical unicorn, it's not going to impress PL theorists; it's going to get work done.

The lack of generics, or parametric polymorphism, or immutable data structures, or LINQ syntax, pattern matching, etc., isn't keeping us from shipping code.

Re: Replacing Clever Code with Unremarkable Code in Go

#84
post #18

Earlier quoted context omitted.

A little off-topic, but could you give some (Perl) code examples of this: > You feel initiated into an inner circle. You feel like you’ve discovered LISP in an alternate dimension (but you haven’t).

I'm not the author, and I don't know much Perl either, but I imagine something like this: $_=@_%*!8%#9(

What does that do? $_ = @_ I can understand.. mod *!8 ..??? Ugh, Perl.

Re: Replacing Clever Code with Unremarkable Code in Go

#85

Earlier quoted context omitted.

I'm not the author, and I don't know much Perl either, but I imagine something like this: $_=@_%*!8%#9(

What does that do? $_ = @_ I can understand.. mod *!8 ..??? Ugh, Perl.

Nothing, it's just gibberish I made up. The worst thing is that it actually looks like plausible Perl :P

Re: Replacing Clever Code with Unremarkable Code in Go

#86
So, Go has message passing. Just like Erlang, since 1986.

Only without per-process heaps, which make crashing processes safe. And without process linking and supervision, which helps systems built using Erlang/OTP achieve nine nines of uptime. Instead, it includes null references, also known as Hoare's Billion Dollar Mistake.

But it's not enough to scorn the industry; Go's designers also look down their noses at academia.

A modern, ML-derived static type system? Generics, which would enable the unwashed mashes to write their own `append`? Ain't nobody got time for that — wait, what? Oh, Rust does?

Go's tooling is fantastic, and its pragmatism is commendable, but ignoring the last 30 years of programming language research is not.

Re: Replacing Clever Code with Unremarkable Code in Go

#87

> A straightforward solution of the problem is superior to one that makes you feel like a high priest for having discovered it. It is also much better for the team and the company. Beginning musicians are just trying to play. Intermediate musicians are try to play as fancy as they can. Master musicians play what's needed by the tune. It takes somebody who's past all the ego issues to devote their intelligence to maki…

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.

Great essay, but Shaw is mistaken about one thing: our art is old enough indeed. Unix and C in particular were created precisely as he describes.

Re: Replacing Clever Code with Unremarkable Code in Go

#88
post #86

So, Go has message passing. Just like Erlang, since 1986. Only without per-process heaps, which make crashing processes safe. And without process linking and supervision, which helps systems built using Erlang/OTP achieve nine nines of uptime. Instead, it includes null references, also known as Hoare's Billion Dollar Mistake. But it's not enough to scorn the industry; Go's designers also look down their noses at acad…

The only reason Go doesn't have generics yet is that Rob Pike hasn't found a system he likes. He's not against it being added in the future.

Re: Replacing Clever Code with Unremarkable Code in Go

#89
post #88
post #86

So, Go has message passing. Just like Erlang, since 1986. Only without per-process heaps, which make crashing processes safe. And without process linking and supervision, which helps systems built using Erlang/OTP achieve nine nines of uptime. Instead, it includes null references, also known as Hoare's Billion Dollar Mistake. But it's not enough to scorn the industry; Go's designers also look down their noses at acad…

The only reason Go doesn't have generics yet is that Rob Pike hasn't found a system he likes. He's not against it being added in the future.

I haven't seen him comment on generics in languages other than C, C++ and Java.

See also below:

https://news.ycombinator.com/item?id=5821027

Re: Replacing Clever Code with Unremarkable Code in Go

#90
post #89
post #88

Earlier quoted context omitted.

The only reason Go doesn't have generics yet is that Rob Pike hasn't found a system he likes. He's not against it being added in the future.

I haven't seen him comment on generics in languages other than C, C++ and Java. See also below: https://news.ycombinator.com/item?id=5821027

My info came from this thread https://news.ycombinator.com/item?id=5792842 which, now that I think about it, appears to be a bunch of second-hand info about the golang mailing lists. rsc posts here about golang sometimes but I don't think he's mentioned generics specifically.
Post reply on HN