6 ms·

I'm with you. IMHO, Go's simplicity is its biggest virtue. It has fostered a community that values consistency and clarity over syntactic sugar. And, as a resul

by rpercy 10y ago

I'm with you. IMHO, Go's simplicity is its biggest virtue. It has fostered a community that values consistency and clarity over syntactic sugar. And, as a result, I find each new codebase extremely accessible.

IshKebab 10y ago
Definitely. Simplicity, and fantastic standard library. Go is like a much faster and more reliable version of Python. People comparing it to C++ and Rust miss the point.
- vvanders 10y ago
  Normally it's the other way around, Go gets compared to other "Systems Programming" languages because somehow services got lumped in with that name over the last few years. To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.
  - niftich 10y ago
    Go gets compared to "systems programming" languages because its designers specifically intended it to be used as such [1][2], albeit the definition of 'systems' they are using is deliberately evolved from the original shade of meaning as suggested by low-level languages that are sometimes deemed to be for 'systems programming' to illustrate that the nature of environments has changed, and a new approach is advantageous. [1] https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article [2] https://golang.org/doc/faq https://golang.org/doc/faq
    - vvanders 10y ago
      If its a "new environment" doesn't imply that it can't be systems programming? I totally agree that Go is fantastic for services and networked things.
      - suppressingfire 10y ago
        i.e., distributed systems.
    - deleted 10y ago
      [deleted]
  - sidlls 10y ago
    And further, in my view, if manual memory management is extraordinarily difficult a language is not necessarily a good candidate for systems programming.
    - zzzcpan 10y ago
      You can relatively easily get to manual memory management using Go's runtime, i.e. access those runtime·sysAlloc(), runtime·sysFree() functions directly, the way Go accesses syscalls in the external sys package [1]. It's like ten lines of code, nothing extraordinarily difficult. [1] https://github.com/golang/sys/blob/master/unix/asm_linux_amd64.s#L16 https://github.com/golang/sys/blob/master/unix/asm_linux_amd...
      - kibwen 10y ago
        The difficulty of manually managing memory isn't necessarily to do with how many lines of code it takes to allocate or deallocate. The difficulty is in managing the scope of the rest of the program that is now susceptible to memory errors, which extends far beyond those initial ten lines of code if encapsulation is done inexpertly.
  - pvg 10y ago
    I think you have this backwards. 'Systems programming' has never meant 'operating systems'. To believe that Go is misdescribed as a 'systems programming' language you have to believe Rob Pike doesn't know what 'systems programming' means.
    - danellis 10y ago
      Perhaps you could help clear up the misconception by fixing Wikipedia's 'System Programming' and 'System Programming Language' entries. It might also be worth commenting on these[0] Stack Exchange answers, too. [0] http://softwareengineering.stackexchange.com/q/151610/54726 http://softwareengineering.stackexchange.com/q/151610/54726
      - pvg 10y ago
        Why would I? They support what I said directly - 'system programming' is not limited to operating systems. Here's a bit from one of the Wikipedia entries you mention. "System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software includes software categories such as operating systems, utility software, device drivers, compilers, and linkers."
        coldtea 10y ago
        "System software includes software categories such as operating systems, utility software, device drivers, compilers, and linkers" Most of those things can be summed up as "operating systems" (operating system, device drivers, and utility software, e.g. basic backend services) plus some essential supporting stuff (compiler and linker). So, yeah, it's pretty much constrained to "operating systems" and the few essential items. It's not about network servers the kind Go is used for.
        pvg 10y ago
        So it's not constrained to operating systems but it's pretty much constrained to operating systems. You can see how I'm less than convinced. It's just not a precisely defined technical term and in a computer language really has more to do with the intent and purpose of the designers and implementors and the operational context than things like 'has manual memory management' or 'must be used for writing an actual operating system'. By your strange definition, writing an NFS server would not be 'systems programming' because for some reason networking is excluded. I don't find this seemingly arbitrary distinction convincing either.
  - pjmlp 10y ago
    > To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language. Having a GC doesn't forbid that, in very specific cases. Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, System C#, Swift, D are all examples of such languages.
    - Manishearth 10y ago
      Rust, too, had an optional GC (where the choice is per-data, not global) for a long time and still intended to be a systems language (And was pretty successful at being systemsy IMO). I think there was a time when &-pointers didn't exist and all sharing was done through the GC too. At one point there was a realization that the new borrowing system could be used to write GC-less programs pretty easily, and that was a turning point after which the GC started being phased out in community usage and eventually removed from the language.
    - vvanders 10y ago
      I never said anything about having a GC, just that if you can't poke directly at memory when you need to then you're going to have a heck of a time working on the Systems Programming space.
      - mseepgood 10y ago
        > if you can't poke directly at memory when you need to then you're going to have a heck of a time working on the Systems Programming space That's possible in go with unsafe.Pointer. Go's runtime, GC and memory allocator are written in Go and make use of this.
      - pjmlp 10y ago
        As mseepgood already replied, you can do that in Go.
      - nickpsecurity 10y ago
        Also remember Go was inspired a lot by Oberon-2. The Oberon languages were used for writing operating systems despite a GC. They just used assembly or UNSAFE constructs for stuff the type-safe or GC parts couldn't handle.
  - aryehof 10y ago
    It gets compared with them because that is what it is particularly good for. Arguably, it is much less suited to Type 1 representational systems (http://aryehoffman.com/entry/project-types http://aryehoffman.com/entry/project-types), for the same reasons as for the C language. Like C, it is particularly suited to Type 2a projects - those in computing and its infrastructure.

by rpercy 10y ago

IshKebab 10y ago

Definitely. Simplicity, and fantastic standard library. Go is like a much faster and more reliable version of Python. People comparing it to C++ and Rust miss the point.

vvanders 10y ago
Normally it's the other way around, Go gets compared to other "Systems Programming" languages because somehow services got lumped in with that name over the last few years. To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.
- niftich 10y ago
  Go gets compared to "systems programming" languages because its designers specifically intended it to be used as such [1][2], albeit the definition of 'systems' they are using is deliberately evolved from the original shade of meaning as suggested by low-level languages that are sometimes deemed to be for 'systems programming' to illustrate that the nature of environments has changed, and a new approach is advantageous. [1] https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article [2] https://golang.org/doc/faq https://golang.org/doc/faq
  - vvanders 10y ago
    If its a "new environment" doesn't imply that it can't be systems programming? I totally agree that Go is fantastic for services and networked things.
    - suppressingfire 10y ago
      i.e., distributed systems.
  - deleted 10y ago
    [deleted]
- sidlls 10y ago
  And further, in my view, if manual memory management is extraordinarily difficult a language is not necessarily a good candidate for systems programming.
  - zzzcpan 10y ago
    You can relatively easily get to manual memory management using Go's runtime, i.e. access those runtime·sysAlloc(), runtime·sysFree() functions directly, the way Go accesses syscalls in the external sys package [1]. It's like ten lines of code, nothing extraordinarily difficult. [1] https://github.com/golang/sys/blob/master/unix/asm_linux_amd64.s#L16 https://github.com/golang/sys/blob/master/unix/asm_linux_amd...
    - kibwen 10y ago
      The difficulty of manually managing memory isn't necessarily to do with how many lines of code it takes to allocate or deallocate. The difficulty is in managing the scope of the rest of the program that is now susceptible to memory errors, which extends far beyond those initial ten lines of code if encapsulation is done inexpertly.
- pvg 10y ago
  I think you have this backwards. 'Systems programming' has never meant 'operating systems'. To believe that Go is misdescribed as a 'systems programming' language you have to believe Rob Pike doesn't know what 'systems programming' means.
  - danellis 10y ago
    Perhaps you could help clear up the misconception by fixing Wikipedia's 'System Programming' and 'System Programming Language' entries. It might also be worth commenting on these[0] Stack Exchange answers, too. [0] http://softwareengineering.stackexchange.com/q/151610/54726 http://softwareengineering.stackexchange.com/q/151610/54726
    - pvg 10y ago
      Why would I? They support what I said directly - 'system programming' is not limited to operating systems. Here's a bit from one of the Wikipedia entries you mention. "System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software includes software categories such as operating systems, utility software, device drivers, compilers, and linkers."
      - coldtea 10y ago
        "System software includes software categories such as operating systems, utility software, device drivers, compilers, and linkers" Most of those things can be summed up as "operating systems" (operating system, device drivers, and utility software, e.g. basic backend services) plus some essential supporting stuff (compiler and linker). So, yeah, it's pretty much constrained to "operating systems" and the few essential items. It's not about network servers the kind Go is used for.
        pvg 10y ago
        So it's not constrained to operating systems but it's pretty much constrained to operating systems. You can see how I'm less than convinced. It's just not a precisely defined technical term and in a computer language really has more to do with the intent and purpose of the designers and implementors and the operational context than things like 'has manual memory management' or 'must be used for writing an actual operating system'. By your strange definition, writing an NFS server would not be 'systems programming' because for some reason networking is excluded. I don't find this seemingly arbitrary distinction convincing either.
- pjmlp 10y ago
  > To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language. Having a GC doesn't forbid that, in very specific cases. Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, System C#, Swift, D are all examples of such languages.
  - Manishearth 10y ago
    Rust, too, had an optional GC (where the choice is per-data, not global) for a long time and still intended to be a systems language (And was pretty successful at being systemsy IMO). I think there was a time when &-pointers didn't exist and all sharing was done through the GC too. At one point there was a realization that the new borrowing system could be used to write GC-less programs pretty easily, and that was a turning point after which the GC started being phased out in community usage and eventually removed from the language.
  - vvanders 10y ago
    I never said anything about having a GC, just that if you can't poke directly at memory when you need to then you're going to have a heck of a time working on the Systems Programming space.
    - mseepgood 10y ago
      > if you can't poke directly at memory when you need to then you're going to have a heck of a time working on the Systems Programming space That's possible in go with unsafe.Pointer. Go's runtime, GC and memory allocator are written in Go and make use of this.
    - pjmlp 10y ago
      As mseepgood already replied, you can do that in Go.
    - nickpsecurity 10y ago
      Also remember Go was inspired a lot by Oberon-2. The Oberon languages were used for writing operating systems despite a GC. They just used assembly or UNSAFE constructs for stuff the type-safe or GC parts couldn't handle.
- aryehof 10y ago
  It gets compared with them because that is what it is particularly good for. Arguably, it is much less suited to Type 1 representational systems (http://aryehoffman.com/entry/project-types http://aryehoffman.com/entry/project-types), for the same reasons as for the C language. Like C, it is particularly suited to Type 2a projects - those in computing and its infrastructure.