6 ms·

If you make a program that is executed a million of times or more a day, it make sense to have a language that is "near the CPU", and allows to optimize and spe

If you make a program that is executed a million of times or more a day, it make sense to have a language that is "near the CPU", and allows to optimize and speed up the most. This is what Go is. It will be a mistake to use it elsewhere.

catnaroek 10y ago
C++, otherwise a deeply flawed language, gives you more abstraction than Go and allows you to optimize and micromanage things more.
- pjmlp 10y ago
  Not only C++, there are plenty of options. The only thing good about Go, is being an evolution path for C coders willing to embrace a GC and some type safety.
  - codygman 10y ago
    One thing I can credit Go for is leading me from the untyped world to the typed one. I soon found the holes in the Go type system, and went looking for a stronger type system. I now generally prefer Haskell.
    - snaky 10y ago
      If Go is from typed world, then Perl too. Some magical built-in types (scalar, array, hash, typeglob, regexp, io handle) you cannot confuse, interface{} is scalar holding a reference, and built-in datatypes (arrays and hashes) are magical and you cannot construct something similar. Well, at least there's 'tie' mechanics in Perl after all that makes types extensible.
      - codygman 10y ago
        Go is more from the typed world than Python where I came from. It will tell you at compile time you are using a string rather than an int (unless you use interface{}).
        snaky 10y ago
        The only difference is a selection of basic types. There's just no such types as string or int in Perl, Perl is a contextually polymorphic language whose scalars can be strings, numbers, or references (which includes objects). Although strings and numbers are considered pretty much the same thing for nearly all purposes, references are strongly-typed, uncastable pointers with builtin reference-counting and destructor invocation.
        codygman 10y ago
        For me the compile time and runtime distinctions are more important.
        snaky 10y ago
        Reflection you need to use, whether it be with interface{} in Go or with $scalar in Perl is runtime thing. reflect.TypeOf(tst), ref($tst) - there's no much difference. Type mismatch errors for basic types are handled in compile time, be it Go or Perl.
  - remus 10y ago
    >The only thing good about Go, is being an evolution path for C coders willing to embrace a GC and some type safety. You say that like it's a small thing, but what proportion of bugs in C code does that cover? Im guessing you'd hit over 50%.
    - pjmlp 10y ago
      It is a small thing because there are other languages that offer the same safety with more features and lets face it, if a C coder is willing to embrace a GC enabled language there are lots to chose from, with AOT compilation to native code. I just expected more from Google, specially if one compares to the other company sponsored languages.
      - snaky 10y ago
        Comparing apples to apples, the first compiler sponsored by 'other company' was PHP, so Go looks not that bad in comparison. Reason is second, and maybe Google's second language would be 1ML.
        pjmlp 10y ago
        Actually I was thinking in all languages that had commercial compilers, which goes way back than just PHP.
- TillE 10y ago
  I love how C++ has had simple features like default arguments / function overloading for decades, while modern languages like Go and Rust require awkward workarounds. Swift 3 looks good, though. They've learned the right lessons.
  - catnaroek 10y ago
    Default arguments, at least as done in C++, complicate the language's semantics (e.g., template specialization selection) far more than they raise the level abstraction. Definitely not a well-designed feature. And Rust's traits are a far more principled (and thus better!) approach to overloading than anything C++ has (Boost's concept checks?). Traits turn concepts into language entities that are directly expressible in Rust syntax, rather than in awkward English documentation.
  - dominotw 10y ago
    C++'s problem was never 'not enough features' it was precisely the opposite.
  - pcwalton 10y ago
    There are also features that Rust has that C++ doesn't. So what?
  - tomjakubowski 10y ago
    I certainly wouldn't say these are "simple features" in C++. Overload resolution in particular is one of the most complicated parts of the language. Default arguments can get weird since the right hand side of the default, more or less, just gets inlined at the call site; I do recall there were a couple bugs in the last year at work because of C++ default arguments, though I don't remember their details. It's also fun when you don't realize a particular function has a default argument until you make a function pointer to it and assign/pass it to something that you mistakenly think is compatible. Depending on how nasty your codebase's use of templates and overloaded functions is, this can be a nightmare to debug.
soulbadguy 10y ago
Golang is only 'near cpu' when compared to python or ruby. Golang is much closer to java/c# then c/c++
- xyproto 10y ago
  Go (the language) have at least two implementations: the official Go implementation and GCC (yes, Go is included in GCC, along with Fortran and Ada). The latest Go implementation (Go 1.7) has made Go a lot faster. I would argue that it closer the speed of executables generated with GCC (gcc/g++) than OpenJDK, the Oracle JVM, Mono or the .NET compiler for C#. Go (the language) can be made just as fast as C (the language), for many cases. Go has the advantage of making it much easier to use multiple processors, though.
  - vvanders 10y ago
    Until you have control over stack/heap and data locality you're never going to be able to approach C/C++/Rust speeds. Conversely if you're using C/C++ through a ton of heap/virtual pointers then you're losing a lot of the value the language brings and should be using something higher level.
    - dilap 10y ago
      Go allocates on the heap unless it can prove something doesn't escape, in which case it's on the stack. Not explicit programmer control, but I think you can reasonably make it do what you want. Because it exposes pointers as a first-class concept, you also have good control of how data is laid out in memory (=> locality). It's not like Python or Java where everything is a pointer and gets spread out all over memory.
      - vvanders 10y ago
        Can you do an arena allocator in Go with disparate types? If not then you're really missing out on data locality. In also not a huge fan of a compiler "automatically" performing escape analysis. Makes a single change causing cascading perf problems very easy and hard to catch.

catnaroek 10y ago

C++, otherwise a deeply flawed language, gives you more abstraction than Go and allows you to optimize and micromanage things more.

pjmlp 10y ago
Not only C++, there are plenty of options. The only thing good about Go, is being an evolution path for C coders willing to embrace a GC and some type safety.
- codygman 10y ago
  One thing I can credit Go for is leading me from the untyped world to the typed one. I soon found the holes in the Go type system, and went looking for a stronger type system. I now generally prefer Haskell.
  - snaky 10y ago
    If Go is from typed world, then Perl too. Some magical built-in types (scalar, array, hash, typeglob, regexp, io handle) you cannot confuse, interface{} is scalar holding a reference, and built-in datatypes (arrays and hashes) are magical and you cannot construct something similar. Well, at least there's 'tie' mechanics in Perl after all that makes types extensible.
    - codygman 10y ago
      Go is more from the typed world than Python where I came from. It will tell you at compile time you are using a string rather than an int (unless you use interface{}).
      - snaky 10y ago
        The only difference is a selection of basic types. There's just no such types as string or int in Perl, Perl is a contextually polymorphic language whose scalars can be strings, numbers, or references (which includes objects). Although strings and numbers are considered pretty much the same thing for nearly all purposes, references are strongly-typed, uncastable pointers with builtin reference-counting and destructor invocation.
        codygman 10y ago
        For me the compile time and runtime distinctions are more important.
        snaky 10y ago
        Reflection you need to use, whether it be with interface{} in Go or with $scalar in Perl is runtime thing. reflect.TypeOf(tst), ref($tst) - there's no much difference. Type mismatch errors for basic types are handled in compile time, be it Go or Perl.
- remus 10y ago
  >The only thing good about Go, is being an evolution path for C coders willing to embrace a GC and some type safety. You say that like it's a small thing, but what proportion of bugs in C code does that cover? Im guessing you'd hit over 50%.
  - pjmlp 10y ago
    It is a small thing because there are other languages that offer the same safety with more features and lets face it, if a C coder is willing to embrace a GC enabled language there are lots to chose from, with AOT compilation to native code. I just expected more from Google, specially if one compares to the other company sponsored languages.
    - snaky 10y ago
      Comparing apples to apples, the first compiler sponsored by 'other company' was PHP, so Go looks not that bad in comparison. Reason is second, and maybe Google's second language would be 1ML.
      - pjmlp 10y ago
        Actually I was thinking in all languages that had commercial compilers, which goes way back than just PHP.
TillE 10y ago
I love how C++ has had simple features like default arguments / function overloading for decades, while modern languages like Go and Rust require awkward workarounds. Swift 3 looks good, though. They've learned the right lessons.
- catnaroek 10y ago
  Default arguments, at least as done in C++, complicate the language's semantics (e.g., template specialization selection) far more than they raise the level abstraction. Definitely not a well-designed feature. And Rust's traits are a far more principled (and thus better!) approach to overloading than anything C++ has (Boost's concept checks?). Traits turn concepts into language entities that are directly expressible in Rust syntax, rather than in awkward English documentation.
- dominotw 10y ago
  C++'s problem was never 'not enough features' it was precisely the opposite.
- pcwalton 10y ago
  There are also features that Rust has that C++ doesn't. So what?
- tomjakubowski 10y ago
  I certainly wouldn't say these are "simple features" in C++. Overload resolution in particular is one of the most complicated parts of the language. Default arguments can get weird since the right hand side of the default, more or less, just gets inlined at the call site; I do recall there were a couple bugs in the last year at work because of C++ default arguments, though I don't remember their details. It's also fun when you don't realize a particular function has a default argument until you make a function pointer to it and assign/pass it to something that you mistakenly think is compatible. Depending on how nasty your codebase's use of templates and overloaded functions is, this can be a nightmare to debug.

soulbadguy 10y ago

Golang is only 'near cpu' when compared to python or ruby. Golang is much closer to java/c# then c/c++

xyproto 10y ago
Go (the language) have at least two implementations: the official Go implementation and GCC (yes, Go is included in GCC, along with Fortran and Ada). The latest Go implementation (Go 1.7) has made Go a lot faster. I would argue that it closer the speed of executables generated with GCC (gcc/g++) than OpenJDK, the Oracle JVM, Mono or the .NET compiler for C#. Go (the language) can be made just as fast as C (the language), for many cases. Go has the advantage of making it much easier to use multiple processors, though.
- vvanders 10y ago
  Until you have control over stack/heap and data locality you're never going to be able to approach C/C++/Rust speeds. Conversely if you're using C/C++ through a ton of heap/virtual pointers then you're losing a lot of the value the language brings and should be using something higher level.
  - dilap 10y ago
    Go allocates on the heap unless it can prove something doesn't escape, in which case it's on the stack. Not explicit programmer control, but I think you can reasonably make it do what you want. Because it exposes pointers as a first-class concept, you also have good control of how data is laid out in memory (=> locality). It's not like Python or Java where everything is a pointer and gets spread out all over memory.
    - vvanders 10y ago
      Can you do an arena allocator in Go with disparate types? If not then you're really missing out on data locality. In also not a huge fan of a compiler "automatically" performing escape analysis. Makes a single change causing cascading perf problems very easy and hard to catch.