6 ms·

What's the appeal of Go when something like OCaml exists and seems to cover much of the same territory and delivers better performance? Not trolling here, I'm g

What's the appeal of Go when something like OCaml exists and seems to cover much of the same territory and delivers better performance? Not trolling here, I'm genuinely curious.

uriel 16y ago
First of all, it is quite obvious that Go and OCaml are completely different languages designed around very different philosophies and styles. 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&lang=go&lang2=ocaml http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
- swannodette 16y ago
  I'm asking about technical merits of one over the other, which you didn't respond to at all. And look at the overall scores on the 64bit one-core and quad-core benchmarks. OCaml is ahead.
  - chc 16y ago
    I'm looking at the overall scores on the 64-bit single-core and Go is six places ahead of OCaml. On the 64-bit quad, Go is five places ahead. The only one where OCaml appears to come close is single-core 32-bit, in which Go comes out one place ahead of OCaml. (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.)
    - swannodette 16y ago
      http://shootout.alioth.debian.org/u64q/which-language-is-best.php http://shootout.alioth.debian.org/u64q/which-language-is-bes... http://shootout.alioth.debian.org/u64/which-language-is-best.php http://shootout.alioth.debian.org/u64/which-language-is-best...
      - uriel 16y ago
        I thought you were talking about performance, in which case the relevant chart is: http://shootout.alioth.debian.org/u64/which-programming-languages-are-fastest.php 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.
        igouy 16y ago
        Both pages show "performance" - they show 2 different summary statistics of "performance". > 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-languages-are-fastest.php?go=on&ocaml=on&calc=chart 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&lang=go&lang2=ocaml#faster-programs-measurements http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
        igouy 16y ago
        Did you downvote my reply instead of trying to justify your own comments ?
        chc 16y ago
        You can't downvote replies to your own comments on Hacker News, so that seems unlikely unless he's sock-puppeting.
    - igouy 16y ago
      > six places ahead ... five places ahead ... 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.
  - burgerbrain 16y ago
    You seem to be under the misunderstanding that simply because you asked a question that has a technical response it is not a troll.
    - swannodette 16y ago
      Half the responses were of the reasonable variety - "Not really much to say as far as technical merits - but it feels better to program in Go for me". Some brought up interesting similar projects. And others corrected my errors. Since when is sparking reasoned debate/discussion trolling?
supersillyus 16y ago
OCaml delivers better performance? It was my impression that they're currently neck-and-neck, and the current Go compiler does pretty much no optimization. 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.
- sambeau 16y ago
  There are two Go compilers gc and gccgo. gc is based on the Plan 9 C compilers and has very little optimisation; gccgo is a front-end to gcc and as such has all of its optimisation. gcc's concurrency support is thread-based so slower than gc's which is coroutine based. tl;dr: gc: slower code, faster concurrency. gccgo: faster code, slower concurrency.
smosher 16y ago
You can learn to be useful in Go in about 5 minutes, and it has some extremely convenient support for concurrency. 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 https://github.com/graydon/rust/wiki - it was bootstrapped in OCaml.
- swannodette 16y ago
  I have looked at Rust. Rust looks like it has the potential to be a much bigger game changer than Go in the systems programming space, in my humble opinion. But only time will tell.
  - icey 16y ago
    Why do you think Rust has the potential to be a much bigger game changer than Go in the systems programming space? I assume you have technical reasons for this opinion?
    - swannodette 16y ago
      Typestate for checking a much larger class of invariants.
mr1900 16y ago
since we are comparing go and ocaml, why did they not add more functional programming support in go? It would at a lot of expressiveness to the language. Just wondering.
- Hemospectrum 16y ago
  Call me crazy but it seems like Go is really just a munging-together of C and Limbo with a bunch of ideas from Python, and literally every feature that "supports functional programming" is only there as a result of being in Python. And obviously Python is not really designed to be a functional language....
  - uriel 16y ago
    If you think Python was a significant influence in Go's design you probably have not worked with much with Go or its ancestors. 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.
    - Hemospectrum 15y ago
      > If you think Python was a significant influence in Go's design you probably have not worked with much with Go or its ancestors. 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.
txxxxd 16y ago
Most of the appeal for me is not the features that Go has, but rather the features that have been intentionally left out.
- uriel 16y ago
  And this is the fundamental point all the people saying there is nothing 'new' about Go miss.
lefessan 15y ago
You are comparing different things. OCaml strength is safety, it verifies at compile time that your program is safe, correct apart algorithmic errors. Once it compiles, you are almost sure it is going to work. Go does not give any such guarantee. 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.

What's the appeal of Go when something like OCaml exists and seems to cover much of the same territory and delivers better performance? Not trolling here, I'm genuinely curious.

uriel 16y ago

First of all, it is quite obvious that Go and OCaml are completely different languages designed around very different philosophies and styles. 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&lang=go&lang2=ocaml http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

swannodette 16y ago
I'm asking about technical merits of one over the other, which you didn't respond to at all. And look at the overall scores on the 64bit one-core and quad-core benchmarks. OCaml is ahead.
- chc 16y ago
  I'm looking at the overall scores on the 64-bit single-core and Go is six places ahead of OCaml. On the 64-bit quad, Go is five places ahead. The only one where OCaml appears to come close is single-core 32-bit, in which Go comes out one place ahead of OCaml. (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.)
  - swannodette 16y ago
    http://shootout.alioth.debian.org/u64q/which-language-is-best.php http://shootout.alioth.debian.org/u64q/which-language-is-bes... http://shootout.alioth.debian.org/u64/which-language-is-best.php http://shootout.alioth.debian.org/u64/which-language-is-best...
    - uriel 16y ago
      I thought you were talking about performance, in which case the relevant chart is: http://shootout.alioth.debian.org/u64/which-programming-languages-are-fastest.php 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.
      - igouy 16y ago
        Both pages show "performance" - they show 2 different summary statistics of "performance". > 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-languages-are-fastest.php?go=on&ocaml=on&calc=chart 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&lang=go&lang2=ocaml#faster-programs-measurements http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
      - igouy 16y ago
        Did you downvote my reply instead of trying to justify your own comments ?
        chc 16y ago
        You can't downvote replies to your own comments on Hacker News, so that seems unlikely unless he's sock-puppeting.
  - igouy 16y ago
    > six places ahead ... five places ahead ... 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.
- burgerbrain 16y ago
  You seem to be under the misunderstanding that simply because you asked a question that has a technical response it is not a troll.
  - swannodette 16y ago
    Half the responses were of the reasonable variety - "Not really much to say as far as technical merits - but it feels better to program in Go for me". Some brought up interesting similar projects. And others corrected my errors. Since when is sparking reasoned debate/discussion trolling?

supersillyus 16y ago

OCaml delivers better performance? It was my impression that they're currently neck-and-neck, and the current Go compiler does pretty much no optimization. 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.

sambeau 16y ago
There are two Go compilers gc and gccgo. gc is based on the Plan 9 C compilers and has very little optimisation; gccgo is a front-end to gcc and as such has all of its optimisation. gcc's concurrency support is thread-based so slower than gc's which is coroutine based. tl;dr: gc: slower code, faster concurrency. gccgo: faster code, slower concurrency.

smosher 16y ago

You can learn to be useful in Go in about 5 minutes, and it has some extremely convenient support for concurrency. 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 https://github.com/graydon/rust/wiki - it was bootstrapped in OCaml.

swannodette 16y ago
I have looked at Rust. Rust looks like it has the potential to be a much bigger game changer than Go in the systems programming space, in my humble opinion. But only time will tell.
- icey 16y ago
  Why do you think Rust has the potential to be a much bigger game changer than Go in the systems programming space? I assume you have technical reasons for this opinion?
  - swannodette 16y ago
    Typestate for checking a much larger class of invariants.

mr1900 16y ago

since we are comparing go and ocaml, why did they not add more functional programming support in go? It would at a lot of expressiveness to the language. Just wondering.

Hemospectrum 16y ago
Call me crazy but it seems like Go is really just a munging-together of C and Limbo with a bunch of ideas from Python, and literally every feature that "supports functional programming" is only there as a result of being in Python. And obviously Python is not really designed to be a functional language....
- uriel 16y ago
  If you think Python was a significant influence in Go's design you probably have not worked with much with Go or its ancestors. 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.
  - Hemospectrum 15y ago
    > If you think Python was a significant influence in Go's design you probably have not worked with much with Go or its ancestors. 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.

txxxxd 16y ago

Most of the appeal for me is not the features that Go has, but rather the features that have been intentionally left out.

uriel 16y ago
And this is the fundamental point all the people saying there is nothing 'new' about Go miss.

lefessan 15y ago

You are comparing different things. OCaml strength is safety, it verifies at compile time that your program is safe, correct apart algorithmic errors. Once it compiles, you are almost sure it is going to work. Go does not give any such guarantee. 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.