Go Rocks - How Can We Avoid Something This Bad In The Future? • Hacker News Board

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#61

Post by Peaker » Mon, Jul 11, 2011, 12:43 AM UTC

a_strange_guy wrote: post #55

pyrhho wrote: post #28

I really wanted to learn something from this post, but it's mostly just hyperbole and whining. "It turns out that, in Go, you can't write a self-recursive anonymous function - there's no way to make it refer to itself. Well, you can do a dirty hack that's the "official work-around" (I'll let you google for the bug report)." To summarize this argument: 1. It is impossible to have a self-recursive anonymous function in…

This is what they want: func outer(a int) { func inner_helper(b int) { ... } } Pascal allowed nested functions 40 years ago...

When saying "nested functions" in 2011, people expect you to mean lexically scoped nested functions.

Pascal's nested functions really just scoped the name of the function differently, but they were equivalent to a function definition on the outer-most level.

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#62

Post by munificent » Mon, Jul 11, 2011, 1:48 AM UTC

zem wrote: post #46

pgroves wrote: post #23

Earlier quoted context omitted.

I'm a full time OCaml dev these days and I run into OCaml's 'lack of lightweight anonymous recursive functions' maybe three times a year. It costs 3 lines of code to declare the function (called loop() or whatever) and then call it. I've never realized I was supposed to want to switch languages because of it. Otherwise, this comment makes me more interested in Go than I have been before. OCaml has a bazillion feature…

what about pattern matching? that is imo one of the saddest omissions from go - it's not a "huge" feature like continuations, but i find it makes a language significantly more pleasant to work with.

I asked Rob Pike why they didn't add pattern-matching given that it already has multiple returns and some other baby steps in that direction. His response was, "We considered it, but it turned out to be too much work in the compiler."

That was a huge WTF to me. Isn't your job as a language designer to do that work so that I, the language user, don't have to?

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#63

Post by koenigdavidmj » Mon, Jul 11, 2011, 4:48 AM UTC

a_strange_guy wrote: post #52

pcwalton wrote: post #25

I work on Rust, which is in a similar space to Go. IMHO this article is oversimplifying. (1) Recursive anonymous functions: This is the first time I've heard this criticism. MLs usually don't have this functionality either. It's not too much trouble to give the function a name. (2) Tail call optimization: TCO isn't free. It requires all callees to pop their arguments, which slightly penalizes every call in the progra…

(1) MLs allow to nest named functions. Go only allows named global functions, and lacks a feature that Pascal had. (2) Someone has to do cleanup anyhow. Either the caller or callee. (I am no expert in calling conventions) Anyhow, isn't this practically free, because the stack is in the L1 cache? (3) To implement lightweight threads (ala. Erlang, Go, Stackless) you already can't allocate your activation records on the…

> Go only allows named global functions, and lacks a feature that Pascal had.

    func main() {
    	bar := func() {
    		fmt.Println("Hello, 世界")
    	}
    	bar()
    }

What do I lose by doing that versus having 'func bar()'?

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#64

Post by uriel » Mon, Jul 11, 2011, 7:17 AM UTC

munificent wrote: post #62

zem wrote: post #46

Earlier quoted context omitted.

what about pattern matching? that is imo one of the saddest omissions from go - it's not a "huge" feature like continuations, but i find it makes a language significantly more pleasant to work with.

I asked Rob Pike why they didn't add pattern-matching given that it already has multiple returns and some other baby steps in that direction. His response was, "We considered it, but it turned out to be too much work in the compiler." That was a huge WTF to me. Isn't your job as a language designer to do that work so that I, the language user , don't have to?

The cost of complexity in the compiler is not only to the persons implementing it.

Also I'm pretty sure the amount of work in the compiler was only one of the considerations, and while I don't doubt your account of your conversation with rob, I doubt it was the main consideration in this design decision.

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#65

Post by dchest » Mon, Jul 11, 2011, 2:54 PM UTC

fauigerzigerk wrote: post #58

gnuvince wrote: post #37

Earlier quoted context omitted.

I cannot recall him ever saying the word "OCaml".

It's possible that I am mistaking Pike for someone else on the Go team.

Or the language? http://en.wikipedia.org/wiki/Occam_(programming_language)

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#66

Post by davidmathers » Mon, Jul 11, 2011, 7:05 PM UTC

drivebyacct2 wrote: post #15

I know that this is the wrong mentality, but I want to become an expert in a language that is as good as it can be. Can Go evolve to address some of these issues? Would it even be go anymore? I tried Googling, but why are Scala and Haskell automatically classified as "academic"? Is there value in learning them purely for that reason? I walked through some Haskell tutorials after reading this, but I'm rather stare at…

I tried Googling, but why are Scala and Haskell automatically classified as "academic"?

Because they are inspired by 20th century mathematics rather than 18th century mathematics. This quote from wikipedia explains it:

These developments of the last quarter of the 19th century and the first quarter of 20th century were systematically exposed in Bartel van der Waerden's Moderne algebra, the two-volume monograph published in 1930–1931 that forever changed for the mathematical world the meaning of the word algebra from the theory of equations to the theory of algebraic structures. -- http://en.wikipedia.org/wiki/Abstract_algebra

The academic languages are the ones aware of that change in the meaning of the word algebra. Everyone learns Euler in high school. Nobody learns Mac Lane.

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#67

Post by breckinloggins » Mon, Jul 11, 2011, 8:48 PM UTC

extension wrote: post #27

enneff wrote: post #8

Earlier quoted context omitted.

I'm amazed by this particular criticism of Go. Compared to many modern languages (Erlang or Ruby, for example), Go's syntax is barely different to Java or C. But I think it's better than either of those (It's certainly more regular). Try it for two days and you'll change your mind. Also, see: http://blog.golang.org/2010/07/gos-declaration-syntax.html

It seems some programmers just will not accept new syntax at all. I think it's a waste of time trying to please these people and, contrary to popular belief, you don't need their blessing to make a successful new language. Coffeescript is an example that supports this.

It's a valid point, but it paints with too broad of a brush. For example, I have enthusiastically moved from JavaScript to CoffeeScript, in part because I love the syntax.

While I know there are programmers who act just like you described, my complaint is with Go's syntax specifically.

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#68

Post by a_strange_guy » Tue, Jul 12, 2011, 12:29 AM UTC

koenigdavidmj wrote: post #63

a_strange_guy wrote: post #52

Earlier quoted context omitted.

(1) MLs allow to nest named functions. Go only allows named global functions, and lacks a feature that Pascal had. (2) Someone has to do cleanup anyhow. Either the caller or callee. (I am no expert in calling conventions) Anyhow, isn't this practically free, because the stack is in the L1 cache? (3) To implement lightweight threads (ala. Erlang, Go, Stackless) you already can't allocate your activation records on the…

> Go only allows named global functions, and lacks a feature that Pascal had. func main() { bar := func() { fmt.Println("Hello, 世界") } bar() } What do I lose by doing that versus having 'func bar()'?

this:

    func global(some_arg_to_close_over Bar) {
    	func walk_tree(node Node) {
            ...
            walk_tree(left(node))
            walk_tree(right(node))
    	}
    	walk_tree(something)
    }