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

Post by kragen » Sun, Jul 10, 2011, 8:15 PM UTC

hvs wrote: post #26

rdtsc wrote: post #22

Earlier quoted context omitted.

I guess it is something like the Valley of The Uncanny for languages. Yes, it looks deceivingly similar to C++, C & Java, but is not any of those. When your eyes see the syntax, your brain expects the functionality to be the same. However Go does introduce fairly radical new paradigms (goroutines, type inference...) that really upsets that initial feeling of familiarity. I (unlike the majority) like Erlang's complete…

I agree except for the whole ";" "," "." line endings issue. When I can't copy and paste to move lines around without "fiddling" with the line endings, I get angry.

Post by pcwalton » Sun, Jul 10, 2011, 8:19 PM UTC

kragen wrote: post #49

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…

Can you elaborate on how popping arguments penalizes every call? It seems like, for non-variadic calls at least, it should take the same amount of time to add a constant to %esp whether you're doing it in the RET instruction or in the caller; but factoring that code into the callee should improve code density and therefore icache hit rates. What am I missing?

Post by a_strange_guy » Sun, Jul 10, 2011, 8:33 PM UTC

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…

    func outer(a int) {
        func inner_helper(b int) {
            ...
        }
    }

Post by nvictor » Sun, Jul 10, 2011, 9:42 PM UTC

supersillyus wrote: post #20

No syntactically lightweight way of writing anonymous recursive functions? I can't make myself care about that; I just spent 30 seconds trying, and failed. That's just not a use case worth optimizing for in a practical systems language. Also, it's true that the Go spec doesn't guarantee tail calls are optimized. If Go were designed to be a functional language, that'd be problematic. However, guaranteeing TCO isn't fr…

Post by uriel » Sun, Jul 10, 2011, 10:19 PM 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.