Why I'm not very excited about Go • Hacker News Board

Re: Why I'm not very excited about Go

#21

Post by stcredzero » Fri, Nov 13, 2009, 1:06 PM UTC

Gupie wrote: post #14

po wrote: post #4

Earlier quoted context omitted.

"I'm not sure one really needs exceptions if you have goroutines, channels, and multiple return values. On the other hand, there are very compelling reasons for not having exceptions, given goroutines and channels." I continually find exception handling to be a huge source of frustration; especially Java's checked exceptions. If I explicitly test for something in my method before calling another method, should I stil…

"there are very compelling reasons for not having exceptions, given goroutines and channels" This confuses me I would have thought the opposite would be true. The goroutine/channel concept seems Erlang like to me. Erlang uses exceptions, if a process crashes an exception is thrown to its parent which can then act appropriately. How does Go handle this, i.e. if a goroutine crashes who gets informed and how?

I'm not sure there's always going to be a "parent."

Re: Why I'm not very excited about Go

#22

Post by silentbicycle » Fri, Nov 13, 2009, 1:09 PM UTC

sedachv wrote: post #12

stcredzero wrote: post #2

The first major mistake was using a C derived syntax Personally, I'm not that interested in the particulars of indentation/block delimiting. I'm much more interested in what one can do with blocks. This has much more bearing on the power of a programming language. If this is the 1st issue discussed, it's a poor portent for the rest of the article. The next mistake is having a separate declaration and assignment opera…

"It's my understanding that one can use "goroutines" to implement your own rather powerful control structures. I'm not sure one really needs exceptions if you have goroutines, channels, and multiple return values. On the other hand, there are very compelling reasons for not having exceptions, given goroutines and channels." The "goroutines" are just threads. They're not useful for building control structures. Unless…

You can build one-shot continuations on top of asymmetrical co-routines, though, and multi-shot continuations if you can copy them. I don't know about "goroutines", but I've done it with the co-routines in Lua.

(For a good analysis of the overlap of co-routines and continuations, see "Revisiting Coroutines" by de Moura et. al. - http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf)

Re: Why I'm not very excited about Go

#23

Post by thenduks » Fri, Nov 13, 2009, 1:21 PM UTC

Gupie wrote: post #14

po wrote: post #4

Earlier quoted context omitted.

"I'm not sure one really needs exceptions if you have goroutines, channels, and multiple return values. On the other hand, there are very compelling reasons for not having exceptions, given goroutines and channels." I continually find exception handling to be a huge source of frustration; especially Java's checked exceptions. If I explicitly test for something in my method before calling another method, should I stil…

"there are very compelling reasons for not having exceptions, given goroutines and channels" This confuses me I would have thought the opposite would be true. The goroutine/channel concept seems Erlang like to me. Erlang uses exceptions, if a process crashes an exception is thrown to its parent which can then act appropriately. How does Go handle this, i.e. if a goroutine crashes who gets informed and how?

goroutines are Erlang-like. Erlang doesn't have 'exceptions' though. In Erlang, if a process crashes (simulated or unexpectedly) it implicitly sends a specific message to it's parent. In Go you can emulate this by just checking for return values of stuff you do in the goroutine and send a similar message if it fails.

The fact that Go is in early development here and I'd say this both could and will be improved in the future.

Re: Why I'm not very excited about Go

#24

Post by thenduks » Fri, Nov 13, 2009, 1:23 PM UTC

dkersten wrote: post #17

shib71 wrote: post #3

He seems to be criticizing Go for not being Python. My understanding is that Go is designed with an obsessive need for speed and concurrency in mind. It's a little silly to compare it to Python without accounting for that.

designed with ... speed and concurrency in mind I won't argue with the speed part, but I feel the concurrency support is a bit weak. Go routines, locks and channels don't seem enough to me for a language that was designed with concurrency in mind . Hell, if thats all it takes, I would argue that Python 2.6, with its multiprocessing module, is designed for concurrency. Now, I do think that these features are an improv…

You should really try it. Erlang (or Scala with Actors) might be a better place to start to get a feel, but that's just me.

Re: Why I'm not very excited about Go

#25

Post by thenduks » Fri, Nov 13, 2009, 1:27 PM UTC

sedachv wrote: post #9

I honestly don't get what the point of Go is. Why not D? Why not Modula3? There is nothing at all compelling in the feature set. Just look at the crap they put in for the built-in concurrency primitives: http://golang.org/doc/go_mem.html So we're back to CSP. Welcome to the 1960s.

I'm not sure how 'crap' comes to mind just looking at the concurrency primitives. You seem to have something against `The 'point' of Go is to be a 'expressive, concurrent, garbage-collected' systems language. It's very early in it's lifecycle and of course immature at the moment... Let's just wait and see what happens in stead of writing it off, shall we?

Re: Why I'm not very excited about Go

#26

Post by wavesplash » Fri, Nov 13, 2009, 2:01 PM UTC

cabalamat wrote: post #19

scott_s wrote: post #5

Constructs like concurrency should not be granted their own syntax, especially when they can be cleanly implemented using the other constructs of a language, look at the C library libtask as an example. See the paper by Hans Boehm from PLDI 2005, "Threads Cannot Be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf The abstract explains the argument: In many environments, multi-threade…

I'm not a big fan of Java, but one of its good points is that threads are part of the language and their behaviour is predicatable across implementations.

That isn't really the case. Java's threading can either be green threads or OS threads and there's no way as a programmer to know what the JVM implements on any given platform.

Re: Why I'm not very excited about Go

#27

Post by dkersten » Fri, Nov 13, 2009, 2:40 PM UTC

thenduks wrote: post #24

dkersten wrote: post #17

Earlier quoted context omitted.

designed with ... speed and concurrency in mind I won't argue with the speed part, but I feel the concurrency support is a bit weak. Go routines, locks and channels don't seem enough to me for a language that was designed with concurrency in mind . Hell, if thats all it takes, I would argue that Python 2.6, with its multiprocessing module, is designed for concurrency. Now, I do think that these features are an improv…

You should really try it. Erlang (or Scala with Actors) might be a better place to start to get a feel, but that's just me.

I should try what? Go?

Regarding concurrency, I've been playing a lot with Clojure recently, whose agents are similar to actors.

Re: Why I'm not very excited about Go

#28

Post by gfodor » Fri, Nov 13, 2009, 3:04 PM UTC

kingkilr wrote: post #7

gfodor wrote: post #6

When I read arguments that include syntax complaints, I really have a hard time taking anything else the author says seriously. It's like a car buyer critiquing in detail crash safety ratings, gas mileage, steering control, and then for no particular reason going on a rant about the optimal arrangement of cup-holders.

If I spent 50%+ of my day reading cup-holders I'd agree with you. I may have over extended that metaphor.

Right, well, I'm referring to the majority of syntax complaints which fall into "I hate braces!" or "Why do the brackets come first and not second?!" Really folks, it doesn't matter. Now, if you had syntax that will result in a massive decrease in efficiency I'm willing to listen. For example, the "function" keyword in Javascript or the lack of implicit typing during assignment in Java are worth talking about, but really at the end of the day they are the least of your problems when considering the limitations of a language.

Re: Why I'm not very excited about Go

#29

Post by thenduks » Fri, Nov 13, 2009, 3:39 PM UTC

dkersten wrote: post #27

thenduks wrote: post #24

Earlier quoted context omitted.

You should really try it. Erlang (or Scala with Actors) might be a better place to start to get a feel, but that's just me.

I should try what? Go? Regarding concurrency, I've been playing a lot with Clojure recently, whose agents are similar to actors.

Yea sorry, I meant 'it' as in Go/Erlang/Scala-Actors style concurrency. If Clojure has something similar then that's cool too. I'm just saying it's pretty game-changing compared to stuff like libraries for Python (imo, of course).

Re: Why I'm not very excited about Go

#30

Post by Semiapies » Fri, Nov 13, 2009, 5:31 PM UTC

gfodor wrote: post #6

When I read arguments that include syntax complaints, I really have a hard time taking anything else the author says seriously. It's like a car buyer critiquing in detail crash safety ratings, gas mileage, steering control, and then for no particular reason going on a rant about the optimal arrangement of cup-holders.

It does matter to people. They have to read it and type it all day, and as decades of language wars make clear, people care what their code looks like.