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

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

acooke.org

Post reply on HN
Print view View original

21–30 of 68 posts

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

#21

Post by rdtsc »

dlsspy wrote: post #4

I wrote a bunch of go code this morning. It's definitely got a few really neat ideas in it. I tend to write erlang or c++ mostly for my day job. I do really wish the designers had a bit more erlang experience. Just a touch. Just enough so that I had a way to propagate the death of a goroutine through a bunch of other goroutines without building all of that manually. For example, code I wrote today: http://pastebin.co…

> I do really wish the designers had a bit more erlang experience.

I feel the same way. I had this hope that this would be what I would learn instead of Erlang. You know it has goroutines and channels -- kind of like processes and casts. Well except that it is not the same. Erlang's processes that have explicit pids and messages are cast to those processes by referring to their pid, make a lot more sense to me than a bunch of channels. Maybe it is just me, but I really just prefer the Erlang way. (Is the the "actor" vs "CSP" paradigms?).

Then it is what you mentioned, exit signals. Anyone who wants to promote concurrency as first order feature in the language and expects it to be useful in the real world, would have to have something like supervision trees & OTP. In other words when you have lots of little goroutines doing stuff concurrently, it is expected some will just crash and then you'd want to do something reasonable, which is not always to just crash the whole application (OS process).

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

#22

Post by rdtsc »

enneff wrote: post #8
breckinloggins wrote: post #5

I still think the major stumbling block for Go is the syntax. I can't put my finger on it, but from the first time I saw it I thought it looked wrong. Can anyone who shares my opinion chime in on what things they think cause the syntax to suffer aesthetically?

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

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 completely strange and radical syntax. When I see, it tells me that "there is something completely new happening here, don't expect this to be C++ plus processes" or something like that.

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

#23

Post by pgroves »

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…

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 features that I never use, and since every OCaml program can look completely different by using those features, the libraries outside the standard lib are all but incompatible with my code.

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

#24

Post by flogic »

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 wouldn't call either Haskell or Scala academic. However, here a quick shoot from the hip stereotyping of each.

Scala gives me the impression it wants to be Java's C++. C++ is largely an extension of C. Sure you can use it entirely differently than C, but that C-ish core is still there. And Scala gives me that same feeling in relation to Java.

On the other hand, Haskell suffers from being a "pure" language. I mean "pure" in a wider sense than "functional". I mean "pure" as in being built entirely around a concept. For Haskell that concept is "functional programming". For Lisp, it's the "cons cell". And for Forth, it's the "stack machine". The benefit to being a "pure" language is there are all sorts of synergies you can take advantage of. The down side is when something doesn't quite line up, it gets ugly fast.

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

#25

Post by pcwalton »

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 program. Rust is planned to support full TCO, but the current compiler only does sibling call optimization (a subset of TCO).

(3) Continuations (I assume call/cc is meant here): Again, these are expensive, because they interfere with the stack discipline. You end up having to garbage collect stack frames in the worst case. For this reason both Go and Rust have implemented exceptional control flow using stack unwinding and destructors. (For Go panic/defer/recover play the role of destructors, while for Rust we use a more traditional RAII system.)

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

#26

Post by hvs »

rdtsc wrote: post #22
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

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.

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

#27

Post by extension »

enneff wrote: post #8
breckinloggins wrote: post #5

I still think the major stumbling block for Go is the syntax. I can't put my finger on it, but from the first time I saw it I thought it looked wrong. Can anyone who shares my opinion chime in on what things they think cause the syntax to suffer aesthetically?

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.

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

#28

Post by pyrhho »

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 Go. 2. Oh wait.. It is completely possible, but far too ugly to soil this blog post.

I looked up the temporary solution (http://code.google.com/p/go/issues/detail?id=226). It is this:

    var recurse func()
    recurse = func() {
      recurse()
    }
The proposed permanent solution is allowing recursive function definitions, because that is the proper solution instead of adding a magic self keyword like other languages do.

(tl;dr The author just doesn't like the fairly-simple work-around proposed while the language is still developing)

Edit: There definitely are far more important things in Go I dislike, and would change, however this blog post is essentially fluff.

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

#29

Post by Peaker »

flogic wrote: post #24
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 wouldn't call either Haskell or Scala academic. However, here a quick shoot from the hip stereotyping of each. Scala gives me the impression it wants to be Java's C++. C++ is largely an extension of C. Sure you can use it entirely differently than C, but that C-ish core is still there. And Scala gives me that same feeling in relation to Java. On the other hand, Haskell suffers from being a "pure" language. I mean "…

I think Haskell accommodates imperative programming so well that it surpasses many imperative languages and beats them in their own game.

I also think the name "purity" is misleading. In the context of Haskell it means:

* Referential Transparency: references to things are indistinguishable from those things. This helps a lot with equational reasoning about code, optimizations and all sorts of mechanical refactorings. I don't think there are significant disadvantages here.

* Typed effects: Haskell types its effects and requires explicit composition of effects and not just of values. This, in turn, turns "side effects" simply into "effects" because they are so explicit. This has some disadvantages, mainly regarding learning curve. If you get a pure function type, you are guaranteed many of useful things about its behavior. The flip side of this, is that if you want to change a pure function to have effects and break these guarantees, you will have to change its type and somewhat restructure it.

Haskell doesn't "get ugly fast" in any circumstance I've seen. It accomodates an extremely wide array of paradigms as pretty encodings on top of its own functional paradigm.

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

#30

Post by xorglorb »

billmcneale wrote: post #14

I think Go is a pretty mediocre language overall, one that would have been a killer early 2000, but this article basically boils down to: "Go sucks because it doesn't support tail call optimization and continuations". Way to miss the boat.

I don't mind those as much, but what really kills it for me is the lack of separation between the language and the standard library.
Post reply on HN