7 ms·

You can also add numbers on an abacus. It _works_. Put in a less snarky way, C is often way more low-level and tedious than you need. The great thing about Go

You can also add numbers on an abacus. It _works_. Put in a less snarky way, C is often way more low-level and tedious than you need. The great thing about Go is that it lets you blend high-level and low-level programming in the same program, only getting low when you need to. It feels like a great mix of C and Pythonubyerlhphavascript. I've given many talks on this, e.g. http://talks.golang.org/2014/gocon-tokyo.slide#1 http://talks.golang.org/2014/gocon-tokyo.slide#1

coldtea 12y ago
>You can also add numbers on an abacus. It _works_. Well, I wouldn't go there (C is antiquated/under-equiped like an abacus) if I was advocating Go. After all, Go, just like an abacus doesn't have generics, or, besides channels and goroutines, most other facilities modern languages offer for that matter (GC and some basic data structures built-in is so 1980).
- lazyjones 12y ago
  > Go, just like an abacus doesn't have generics, or, besides channels and goroutines, most other facilities modern languages offer for that matter If you need mainly a large number of features in order to program, Go probably isn't for you. But from the perspective of a C/C++ programmer, this isn't likely to be an important point. Languages with more features than C have been available for 40 years (depends on what you'd count as a feature), so there were plenty of "better" choices in that regard available for said people. For me, the lack of some "features" is a great asset for Go, I probably wouldn't have bothered to learn a new language if it had boasted the complexity of Rust or Haskell.
jacques_chester 12y ago
> The great thing about Go is that it lets you blend high-level and low-level programming in the same program Where are map, reduce, select, filter, fold, zip ...? I don't consider hand-rolling them in for/range as equivalent. Can I wind up with the same result? Yes. But I could do it with gotos too. And I've seen "loops are the same as map/reduce etc" advanced as a serious argument by people who weren't, so far as I could tell, trying to tug on my leg.
- NateDad 12y ago
  Most of the questions about "how do I do X in Go?" are answered with "just write a loop". Yes, that means map/reduce, filter, fold, zip, etc. If writing simple loops gets your hackles up, Go is not the language for you. For me, I worry about the hard stuff, not easy loops.
  - jacques_chester 12y ago
    > If writing simple loops gets your hackles up, Go is not the language for you. What gets my hackles up is claiming that "it's just the same". The same argument works for any language that satisfies the structured programming theorem, including assembler. "If writing simple BNE $reg gets your hackles up, Assembler is not the language for you."
    - NateDad 12y ago
      For most people's uses, it's the same. Certainly, there can be performance benefits if your language's implementation uses lazy evaluation and you have a very large list and you only need to evaluate a small portion of the list... but in my experience, that is very rarely the case in real programs.
      - jacques_chester 12y ago
        > For most people's uses, it's the same. I look forward to seeing how I can chain multiple operations on a set into a single line of Go.
        NateDad 12y ago
        Cramming a lot of logic into a single line of code is an anti-pattern and not a goal of the go language. Also see the aforementioned "the answer is to write a loop".
        jacques_chester 12y ago

coldtea 12y ago

>You can also add numbers on an abacus. It _works_. Well, I wouldn't go there (C is antiquated/under-equiped like an abacus) if I was advocating Go. After all, Go, just like an abacus doesn't have generics, or, besides channels and goroutines, most other facilities modern languages offer for that matter (GC and some basic data structures built-in is so 1980).

lazyjones 12y ago
> Go, just like an abacus doesn't have generics, or, besides channels and goroutines, most other facilities modern languages offer for that matter If you need mainly a large number of features in order to program, Go probably isn't for you. But from the perspective of a C/C++ programmer, this isn't likely to be an important point. Languages with more features than C have been available for 40 years (depends on what you'd count as a feature), so there were plenty of "better" choices in that regard available for said people. For me, the lack of some "features" is a great asset for Go, I probably wouldn't have bothered to learn a new language if it had boasted the complexity of Rust or Haskell.

jacques_chester 12y ago

> The great thing about Go is that it lets you blend high-level and low-level programming in the same program Where are map, reduce, select, filter, fold, zip ...? I don't consider hand-rolling them in for/range as equivalent. Can I wind up with the same result? Yes. But I could do it with gotos too. And I've seen "loops are the same as map/reduce etc" advanced as a serious argument by people who weren't, so far as I could tell, trying to tug on my leg.

NateDad 12y ago
Most of the questions about "how do I do X in Go?" are answered with "just write a loop". Yes, that means map/reduce, filter, fold, zip, etc. If writing simple loops gets your hackles up, Go is not the language for you. For me, I worry about the hard stuff, not easy loops.
- jacques_chester 12y ago
  > If writing simple loops gets your hackles up, Go is not the language for you. What gets my hackles up is claiming that "it's just the same". The same argument works for any language that satisfies the structured programming theorem, including assembler. "If writing simple BNE $reg gets your hackles up, Assembler is not the language for you."
  - NateDad 12y ago
    For most people's uses, it's the same. Certainly, there can be performance benefits if your language's implementation uses lazy evaluation and you have a very large list and you only need to evaluate a small portion of the list... but in my experience, that is very rarely the case in real programs.
    - jacques_chester 12y ago
      > For most people's uses, it's the same. I look forward to seeing how I can chain multiple operations on a set into a single line of Go.
      - NateDad 12y ago
        Cramming a lot of logic into a single line of code is an anti-pattern and not a goal of the go language. Also see the aforementioned "the answer is to write a loop".
        jacques_chester 12y ago