161–170 of 184 posts
Interesting comparisons. However (not slating Go, which I think is excellent), I genuinely think Go is going to go the same way as plan9 eventually. Unfortunately, its predecessor (C) is good enough, much as UNIX was good enough compared to plan9.
The big win for go over c is the goroutines - cheap and easy multithreading built right into the language.
Earlier quoted context omitted.
Somebody should write a Google Go to C transpiler. Mostly Google Go features are limitations or different styles in order to 'improve' C, so it should produce fairly readable C code. Then you could use any compiler, linking type, combine with any language, etc. You could probably even use LD_PRELOAD to replace coroutines with pthreads. For instance Russ Cox did coroutines and channels in his C libtask in a few thousa…
You write "worse than gcc", but Go has been included in GCC since version 4.6: http://gcc.gnu.org/gcc-4.6/changes.html
Yes, gcc now also compiles the language, but they still pimp their own compilers... iirc the "go" tool uses them by default (or maybe exclusively). Why create a new compiler? Why a project management tool that does everything except work with other build systems? Why isolate the language by making it difficult to use with others? I feel those are good questions to ask.
Earlier quoted context omitted.
I agree. I don't see anything wrong what he did, but somebody should offer to submit counterpoints that better emphasize what Go is able to do.
I think many counterpoints should be fairly obvious. Anything from "return a return value and an error code from a function" (trivial in both, way nicer in Go though) to "write a webserver from scratch. Which did you just schedule more time for?"
Earlier quoted context omitted.
[Go] doesn't show much awareness of advances that have already been made. Go's response would be to question that the things you're talking about are, in fact, unqualified advances. Especially in the context of large (ie. LOC) systems applications, maintained by large (ie. dozens to hundreds) of developers.
Java, C#, Python, Lisp, and Erlang would all criticize Go for an unqualified new exception system which has not proven that it can handle itself in the context of large systems applications, unlike all the previous languages.
Java, C#, Python, Lisp, and Erlang would all criticize
Go for an unqualified new exception system
func canFail() (int, error) { ... }
value, err := canFail()
if err != nil {
// handle
}Earlier quoted context omitted.
The big win for go over c is the goroutines - cheap and easy multithreading built right into the language.
zeromq or coroutine libraries like libtask (by a go author!) have greatly reduced this advantage.
I suppose that begs the question: if you can built it in the language, should it really be a part of the implementation?
Earlier quoted context omitted.
zeromq or coroutine libraries like libtask (by a go author!) have greatly reduced this advantage.
libtask looks really cool. Thanks for posting. I suppose that begs the question: if you can built it in the language, should it really be a part of the implementation?
There are also other language features that make it much more usable and that are missing from C, like garbage collection.
I know Rob Pike and Russ Cox have discussed this several times, it might be worth watching this talk by rob about the history of Go's concurrency model you can find here: http://go-lang.cat-v.org/talks/
And Russ Cox's article also about this: http://swtch.com/~rsc/thread/
I'm not sure either covers exactly the reasons why it is a great advantage to make it part of the language, but they are still interesting background.
Go is the best worst language I've used. Most of what I do fits pretty much right in the sweet spot for go, network services and web development. Stuff I would have previously used C and (insert scripting language here) for respectively. Go fits into both of those areas really nicely, and I prefer it over C and scripting language X for these tasks. But the problem is, I've already tried haskell, which also fits that…
Might I suggest Scala[1]? It is a modern languages with mature build tools and development environment. It also has a lot of nice tools surrounding network services and web development[2]. [1] http://www.scala-lang.org/ [2] http://typesafe.com/stack
Scala ends up more like the worst aspects of haskell and go combined, rather than the best aspects of both.
Earlier quoted context omitted.
Might I suggest Scala[1]? It is a modern languages with mature build tools and development environment. It also has a lot of nice tools surrounding network services and web development[2]. [1] http://www.scala-lang.org/ [2] http://typesafe.com/stack
You certainly can suggest it, I already tried it though. ;) Scala ends up more like the worst aspects of haskell and go combined, rather than the best aspects of both.