Slashdot Mirror

Go seems to suffer from the problem of not being done. Case in point: exceptions.

The authors at least partly agree with you. They describe the absence of exceptions here. They consider it to be an open issue.

On the other hand, they already provide an alternative to the "finally" block of an exception handler: the defer keyword. I like the looks of this, as it means you can handle all of your closing and locking kinds of issues in a direct pairing with the corresponding open or lock, regardless of whether the function terminates early due to error conditions.

Go seems to suffer from the problem of not being done. Case in point: exceptions.

The authors at least partly agree with you. They describe the absence of exceptions here. They consider it to be an open issue.

On the other hand, they already provide an alternative to the "finally" block of an exception handler: the defer keyword. I like the looks of this, as it means you can handle all of your closing and locking kinds of issues in a direct pairing with the corresponding open or lock, regardless of whether the function terminates early due to error conditions.

Indeed.

From http://golang.org/src/pkg/container/list/list.go we can see that they're using Go's "interface{}" (C "void*" / Java "Object").

They're just going to run straight into the Collections issues Java had when it introduced generics and had to retrofit them to the non-generic existing Collections without breaking backward compatibility.

I think that they should note that the language will be in flux whilst they decide whether to do generics now, or leave it to screw up compatibility later.

I mean, they tried with the built-in map: map[string]int even though the syntax sucks.

... the low-level, external syscall package, which provides a primitive interface to the underlying operating system's calls.

Finally, some sanity in language design. syscall will no doubt be used only occasionally, but it's there if you need it and you know what you're doing.

C++'s templates offer a lot more than just generics (which is what you're talking about when you say "type safe containers and reusable algorithms"), however Go does, in fact, provide for this with its "interfaces." The Go interface affords for both data abstraction (akin to C++'s inheritance hierarchy), and generic programming. Go provides an "Any" container, which "may be used to implement generic programming similar to templates in C++".

It's worth noting though that this is a dynamically bound language feature, which means it is checked and enforced at runtime rather than compile time -- both a positive and a negative depending on how you look at it. It provides for some more interesting programs to be written that do fun things at runtime, but on the down side it means you lose a lot of the compile time type-checking that C++ provides and can save a lot of debugging time later on. It also means that you can't do any template metaprogramming with Go -- again which can be viewed as a positive or a negative.

I also challenge you to come up with a solution that equates to Go's built in Channel's in less than 100 lines of C++. What you're actually saying is you "can implement Go's Goroutine's AND Channels in less than 100 lines of code in portable, cross platform, C++". But, let's give you the benefit of the doubt and say that you've already go some mechanism for emulating a Goroutine (which by the way allows one to "mutiplex independently executing functions onto a set of threads"). I think _just_ the thread safe code that would implement all the necessary locks and barriers for a _single_ platform would probably be more than 100 lines, and would not be portable (ie, it would be pthreads, or win32 specific).

I am open to being wrong about that, but I really do believe that you haven't spent much time investigating Go, and are therefore spreading FUD. For example your assertion that "in Go, a List class would have to use void* types, throwing type safety out of the window" is just plain wrong.

I should also point out that I am in no way a Google Go fanboy. I see it as a pseudo-interesting low-ish level language that I haven't quite been able to envision the proper use for yet. I don't really buy Google's claim that it's a system level language (I can't see myself wanting to write an OS or device driver in it). To me it seems more like a great way to rapidly build efficient client / server type applications.

Go seems to be basically the start of an improved version of C, rather than an improved version of C++

It sounds more like it has more in common with C# than C++.

http://golang.org/doc/go_for_cpp_programmers.html

From Go's FAQ

There is a “foreign function interface” to allow safe calling of C-written libraries from Go code. We expect to use SWIG to extend this capability to C++ libraries. There is no safe way to call Go code from C or C++ yet.

Well, since Go has some native support for concurrency, it shouldn't be that difficult to have it running on a Beowulf cluster...

why wonder when you can look it up? http://golang.org/doc/go_spec.html

I prefer this reference ;-)

http://en.wikipedia.org/wiki/Considered_harmful

From Golanf.org : "With Go we take an unusual approach and let the machine take care of most formatting issues. A program, gofmt, reads a Go program and emits the source in a standard style of indentation and vertical alignment, retaining and if necessary reformatting comments. [...] We use tabs for indentation and gofmt emits them by default. Use spaces only if you must."

Of course you realize ... this means war.

Does Go have goto statement ?

why wonder when you can look it up? http://golang.org/doc/go_spec.html

tl;dr yes, it has goto

It doesn't have comefrom though. Words alone cannot express my disappointment.

They also have a "spacewar" directory, currently empty...

the documentation directory is empty, but the original pdp1 code is there as well as a pdp1 emulator to run it on: http://golang.org/src/pkg/exp/spacewar/

Does Go have goto statement ?

why wonder when you can look it up? http://golang.org/doc/go_spec.html

tl;dr yes, it has goto

It's a small complaint, I'm sure.. but couldn't they have given it a name that you could, you know, Google?

Yeah, why couldn't they use unambiguous names like all other programming languages, like C, Java, Python and Ruby?

Sarcasm aside, I agree that the naming is unfortunate (although I love the Go Ogle debugger pun). The parent was probably referring to the common verb, but this will also make it much harder for Go players like myself to find books and stuff for the board game. This guy isn't happy either.