Also saying that you are not trolling doesn't make your comment any less trollish, specially given that your only claim is false, Go, despite still being much younger and greatly unoptimized is already considerably faster than OCaml: http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
(And just so we're clear: I actually like OCaml and have never used Go. So I'm not trying to wave some Go fanboy flag or anything. Those are just the numbers.)
Those tables do not show a rank # by each programming language implementation because that might encourage people to make a completely bogus comparison!
(For example, six places rather than five just because one table includes an extra programming language - Clean.)
You're both being silly! "The numbers" for Go 6g and OCaml overlap and are quite similar.
http://shootout.alioth.debian.org/u64/which-programming-lang...
Which shows Go is well ahead of OCaml.
The "which language is best" chart you linked has rather arbitrary weighting.
> The "which language is best" chart you linked has rather arbitrary weighting.
That chart has exactly the same "weighting" as the chart you say is "the relevant chart"!
> Which shows Go is well ahead of OCaml.
Which shows the time measurements for those programs with Go 6g and OCaml completely overlap
http://shootout.alioth.debian.org/u64/which-programming-lang...
The time measurements are similar for both Go 6g and OCaml -
http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
On the flipside, I think learning OCaml (if you've no experience with that family) will make you smarter in a way that Go won't. Of the two, given someone that knew neither: if you want to learn something learn OCaml, if you want to do something use Go.
Aside: speaking of OCaml and new languages, have you looked at Rust? https://github.com/graydon/rust/wiki - it was bootstrapped in OCaml.
That aside, personal preference is a one reason to choose Go over OCaml. I happen to like Go's syntax better, and I rather like the design of various bits of the language. Go also has better concurrency support. Also, for some tasks it can be quite useful to be able to control the memory layout of your data structures, and (to my knowledge) OCaml can't do that.
There are other points to make on both sides, but really, it's a tricky question. Which langauge is best is a per-task and per-person question, so unqualified comparisons aren't terribly useful.
tl;dr:
gc: slower code, faster concurrency.
gccgo: faster code, slower concurrency.
And among "safe" languages, OCaml is probably the most efficient, generating fast code running with a small memory footprint.
Moreover, although its development was a little slow in the last years, they have recently restarted working on it, on optimizations and soon multicore support, so I would wait a little before making more comparisons.
Yes, Go is not a 'purely functional' language, or 'purely' anything, Go is a pragmatic language following from a very long tradition mostly at Bell Labs.
You're correct. I haven't used Go particularly much and I've only heard third-party descriptions of Limbo et al. Regardless, a number of the semantic and syntactic differences between Limbo and Go strike me as Python-influenced (obviously not goroutines or the defer statement) but if you have evidence to the contrary I'd love to see it.
> Yes, Go is not a 'purely functional' language, or 'purely' anything
Whoa buddy. That's not what I meant at all. There's no technical value in being able to say your language "purely" implements some programming style or other. Now, it would be nice if higher-order functions became a little easier to work with in Go; it is also unlikely that this will happen, because that's not one of the design goals. I can't fault them for that, but is there really any harm in pointing out a true fact such as this one?
And anyway, a "purely functional" language is just one where there's no built-in support for mutable state. Obviously this does not describe either Go or OCaml.