6 ms·

I get where your coming from (I think... let me know if I've missed your point), but I think the purpose of Go's type system is to offer some safety while emula

I get where your coming from (I think... let me know if I've missed your point), but I think the purpose of Go's type system is to offer some safety while emulating a dynamic language. In some cases, rigid type-safety is necessary, but I have trouble taking this criticism seriously while languages like Python enjoy extreme success. If Python can be insanely useful (and acceptably safe), then why not Go? tl;dr: Go is not -- from a practical point of view -- a static language. (Note to pedants: I'm talking about Go's use, not it's formal nature). Better tl;dr: Think "Python's type annotations" rather than "Rust".

cmrdporcupine 11y ago
Then it needs to stop calling itself a 'systems programming language.' Or maybe it doesn't, but others need to stop calling it that. To me, it's a replacement for Java, not C++. I think that's a reasonable target. Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.
- omginternets 11y ago
  >Then it needs to stop calling itself a 'systems programming language.' Why must a systems programming language be static and strongly typed? I don't mean to be flippant, but to me, 'systems programming language' means 'a language that facilitates productivity for systems programmers'. By that description, Go certainly qualifies. >Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work. Point taken, but not all system's programming requires such extreme safety.
  - tomp 11y ago
    ASM isn't strongly or statically typed, so that's obviously not a requirement for a "systems programming language". The requirement most people mean, when they say "Go isn't a systems programming language", is the ability to acurately control execution. With Go, you can't, because of GC.
  - AnimalMuppet 11y ago
    Define "systems programming" (or "systems programmer"). Google's definition seems to be "building large systems". For the types of large systems Google wants to build, Go works very well. But others define it as "building operating systems". Go is horrible for that because of garbage collection and inability to directly access the hardware.
    - omginternets 11y ago
      Ah, maybe that's the misunderstanding here. I can't comment on "building operating systems", but it seems improbable that a GC should never be used in such endeavors.
- nteon 11y ago
  C doesn't have generics, and is certainly a systems language. I don't think you have a strong point here. Systems != embedded.
  - masklinn 11y ago
    > C doesn't have generics, and is certainly a systems language. C doesn't have a mandatory runtime, ubiquitous dynamic dispatch or a GC, and it lets developers decide whether to stack or heap allocate. cmrdporcupine also isn't talking about generics, they're replying to the assertion that > Go is not -- from a practical point of view -- a static language
  - bryanlarsen 11y ago
    C programmers use void pointers for generics. :)
    - cmrdporcupine 11y ago
      And so, basically, does Go.
      - kyrra 11y ago
        Except there is a fairly large difference with interface{}, in that it is typed. interface{} is more like Object in java than void* from C. If you incorrectly cast an interface{} to a type it's not, it will be a runtime error. Details: http://research.swtch.com/interfaces http://research.swtch.com/interfaces
        fizzbatter 11y ago
        > If you incorrectly cast an interface{} to a type it's not, it will be a runtime error. Sidenote, you may or may not have meant a panic - so i just want to clarify. Casting an interface to a type incorrectly will not cause a panic/crash, assuming you use the proper syntax. // Will panic foo := myInterface.(BadType) // Will not panic foo, ok := myInterface.(BadType) In the latter, you simply check if `ok` is true or not. If not, the interface value does not implement the given type/interface.
- cletus 11y ago
  Go was never a systems programming language as soon as it made the decision to be garbage collected. Don't get me wrong: in many cases I like GC but you'll never dethrone C/C++ for many use cases with a GC language. I find it interesting that many Go pundits I speak to just don't seem to get this. I wouldn't even say Go's target market is Java. I'd say it's actually Python. Rob Pike has spoken about this [1]. I like Python. It's fun but for anything nontrivial I've become disillusioned with it because the supposed productivity gains are offset by having to write unit tests for spelling mistakes and typos. So I like Go for this purpose. It's not quite as expressive as Python but it's in a sweet spot IMHO. [1]: http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
  - nickpsecurity 11y ago
    The Oberon and LISP machine people would disagree given they wrote whole OS's and platforms in GC languages. The trick is to support manual control & unsafe where necessary. I know it can work for Go with small changes because it worked for Wirth languages that Go was based on.
  - osullivj 11y ago
    I find PyCharm addresses that Python weakness nicely. I'm sticking with C++ & Python pro tem. When Rust is a little more mature I think I'll invest.
  - ensignavenger 11y ago
    Why do you need to write unit tests for spelling mistakes and typos in Python?
    - cobaltblue 11y ago
      It's one class of errors that doesn't typically happen with a static compiled language, people like to feel 'safe' about the dullest things but typos can be found pretty easily by running the code you just wrote in a REPL or at least structuring your application so that you can quickly get it to the same state to test live... But honestly you can just repeat the typos in your tests, or make new ones, in any case for me at least it's a class of error that comes up very rarely regardless of whether I'm using mitigations like auto-complete. And lastly I'd think if you were unit testing "properly", aiming for good coverage, which unit testing advocates will say you must do regardless of a static or dynamic language, your unit tests should catch various typos as a side-benefit. Testing things like int in -> int out or "reading this function it calls these methods on foo, here's a mock foo and we're just going to make sure all of them get called as expected and I didn't misread/mistype either the code or the test code" seems insane.
- gohrt 11y ago
  Then good that it stopped years ago: https://golang.org/doc/ https://golang.org/doc/ >>> The Go programming language is an open source project to make programmers more productive. Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. <<<
  - iofj 11y ago
    "expressive" "concise" "novel type system" "flexible type system" Just a few things that need correcting. Really ... "novel type system" ...
    - adrusi 11y ago
      Ok, well that's funny. You pick "novel type system" apparently because you find it especially absurd, but I find that that's the only accurate on on the list. Go isn't expressive, nor concise, nor does it have a flexible type system. But if any of its claims are true, it's that its type system is at least a little novel. Sure it's not the most exotic type system out there, but its interfaces are very useful and they aren't found in many other languages (not implicitly satisfied interfaces, that is).
      - iofj 11y ago
        Go's brand of duck typing isn't exactly a novel type system. If I had to describe Go, I'd say "I like Hoare's paper" combined with "I read the first 10 pages of the book 'my first compiler'".
      - incepted 11y ago
        > But if any of its claims are true, it's that its type system is at least a little novel. Are you saying it's novel because it picked the worst features of past type systems? ;-) Technically, it is indeed novel, but it's novel because making these choices was pretty dumb in the first place so nobody made them...
- blub 11y ago
  No chance to replace Java, when Java is all about ecosystem, tooling, maturity and talent pool. And it has generics. I mean I am no Java expert, but e.g Android Studio is miles ahead anything the go team will be able to ship in the next few years. And I don't think they're even focusing on building such tools since they seem to be stuck on building a debugger right now.
  - vardump 11y ago
    Java doesn't actually have runtime generics. Just type erasure syntactic sugar. ArrayList<Integer> is the same type at runtime as ArrayList<Foo>.
    - omginternets 11y ago
      This strikes me as a distinction without a difference, in the present case. How is this meaningfully different from the programmer's perspective?
      - vardump 11y ago
        You can't distinguish them at runtime from each other. Your memory consumption is higher, because type erasure requires elementary types to be boxed. Since the boxed value is itself allocated somewhere else, there's indirection. Indirection means CPU stalls. Another consequence is data cache pollution. There are just 512 of 64 byte L1D cache lines. Other than that, I guess nothing.
        AnimalMuppet 11y ago
        But if you're worried about that amount of memory consumption, why are you using Java? If you need that much control over memory, Java may not be the language for you. Ditto if you're worried about the performance hit from cache misses.
    - blub 11y ago
      Sure, but I'll take it if that means I can at least use some type of generics. :) In my experience it's decent, even if not as powerful as C++ templates. Being able to specialize containers is a basic comfort for me.
lmm 11y ago
I don't think every language needs to be rigid - something like TypeScript's gradual, unsound typing can be very valuable, and I certainly think there's a place for a language where casting is easy and idiomatic. But you can do that and still enable generics, covariance and the like - as TypeScript in fact does. What's incredibly infuriating to see a language that clearly has everything it needs to offer generics - indeed it clearly has a generics implementation already written, since the builtin types are generic - but it won't let me use them.

cmrdporcupine 11y ago

Then it needs to stop calling itself a 'systems programming language.' Or maybe it doesn't, but others need to stop calling it that. To me, it's a replacement for Java, not C++. I think that's a reasonable target. Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.

omginternets 11y ago
>Then it needs to stop calling itself a 'systems programming language.' Why must a systems programming language be static and strongly typed? I don't mean to be flippant, but to me, 'systems programming language' means 'a language that facilitates productivity for systems programmers'. By that description, Go certainly qualifies. >Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work. Point taken, but not all system's programming requires such extreme safety.
- tomp 11y ago
  ASM isn't strongly or statically typed, so that's obviously not a requirement for a "systems programming language". The requirement most people mean, when they say "Go isn't a systems programming language", is the ability to acurately control execution. With Go, you can't, because of GC.
- AnimalMuppet 11y ago
  Define "systems programming" (or "systems programmer"). Google's definition seems to be "building large systems". For the types of large systems Google wants to build, Go works very well. But others define it as "building operating systems". Go is horrible for that because of garbage collection and inability to directly access the hardware.
  - omginternets 11y ago
    Ah, maybe that's the misunderstanding here. I can't comment on "building operating systems", but it seems improbable that a GC should never be used in such endeavors.
nteon 11y ago
C doesn't have generics, and is certainly a systems language. I don't think you have a strong point here. Systems != embedded.
- masklinn 11y ago
  > C doesn't have generics, and is certainly a systems language. C doesn't have a mandatory runtime, ubiquitous dynamic dispatch or a GC, and it lets developers decide whether to stack or heap allocate. cmrdporcupine also isn't talking about generics, they're replying to the assertion that > Go is not -- from a practical point of view -- a static language
- bryanlarsen 11y ago
  C programmers use void pointers for generics. :)
  - cmrdporcupine 11y ago
    And so, basically, does Go.
    - kyrra 11y ago
      Except there is a fairly large difference with interface{}, in that it is typed. interface{} is more like Object in java than void* from C. If you incorrectly cast an interface{} to a type it's not, it will be a runtime error. Details: http://research.swtch.com/interfaces http://research.swtch.com/interfaces
      - fizzbatter 11y ago
        > If you incorrectly cast an interface{} to a type it's not, it will be a runtime error. Sidenote, you may or may not have meant a panic - so i just want to clarify. Casting an interface to a type incorrectly will not cause a panic/crash, assuming you use the proper syntax. // Will panic foo := myInterface.(BadType) // Will not panic foo, ok := myInterface.(BadType) In the latter, you simply check if `ok` is true or not. If not, the interface value does not implement the given type/interface.
cletus 11y ago
Go was never a systems programming language as soon as it made the decision to be garbage collected. Don't get me wrong: in many cases I like GC but you'll never dethrone C/C++ for many use cases with a GC language. I find it interesting that many Go pundits I speak to just don't seem to get this. I wouldn't even say Go's target market is Java. I'd say it's actually Python. Rob Pike has spoken about this [1]. I like Python. It's fun but for anything nontrivial I've become disillusioned with it because the supposed productivity gains are offset by having to write unit tests for spelling mistakes and typos. So I like Go for this purpose. It's not quite as expressive as Python but it's in a sweet spot IMHO. [1]: http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
- nickpsecurity 11y ago
  The Oberon and LISP machine people would disagree given they wrote whole OS's and platforms in GC languages. The trick is to support manual control & unsafe where necessary. I know it can work for Go with small changes because it worked for Wirth languages that Go was based on.
- osullivj 11y ago
  I find PyCharm addresses that Python weakness nicely. I'm sticking with C++ & Python pro tem. When Rust is a little more mature I think I'll invest.
- ensignavenger 11y ago
  Why do you need to write unit tests for spelling mistakes and typos in Python?
  - cobaltblue 11y ago
    It's one class of errors that doesn't typically happen with a static compiled language, people like to feel 'safe' about the dullest things but typos can be found pretty easily by running the code you just wrote in a REPL or at least structuring your application so that you can quickly get it to the same state to test live... But honestly you can just repeat the typos in your tests, or make new ones, in any case for me at least it's a class of error that comes up very rarely regardless of whether I'm using mitigations like auto-complete. And lastly I'd think if you were unit testing "properly", aiming for good coverage, which unit testing advocates will say you must do regardless of a static or dynamic language, your unit tests should catch various typos as a side-benefit. Testing things like int in -> int out or "reading this function it calls these methods on foo, here's a mock foo and we're just going to make sure all of them get called as expected and I didn't misread/mistype either the code or the test code" seems insane.
gohrt 11y ago
Then good that it stopped years ago: https://golang.org/doc/ https://golang.org/doc/ >>> The Go programming language is an open source project to make programmers more productive. Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. <<<
- iofj 11y ago
  "expressive" "concise" "novel type system" "flexible type system" Just a few things that need correcting. Really ... "novel type system" ...
  - adrusi 11y ago
    Ok, well that's funny. You pick "novel type system" apparently because you find it especially absurd, but I find that that's the only accurate on on the list. Go isn't expressive, nor concise, nor does it have a flexible type system. But if any of its claims are true, it's that its type system is at least a little novel. Sure it's not the most exotic type system out there, but its interfaces are very useful and they aren't found in many other languages (not implicitly satisfied interfaces, that is).
    - iofj 11y ago
      Go's brand of duck typing isn't exactly a novel type system. If I had to describe Go, I'd say "I like Hoare's paper" combined with "I read the first 10 pages of the book 'my first compiler'".
    - incepted 11y ago
      > But if any of its claims are true, it's that its type system is at least a little novel. Are you saying it's novel because it picked the worst features of past type systems? ;-) Technically, it is indeed novel, but it's novel because making these choices was pretty dumb in the first place so nobody made them...
blub 11y ago
No chance to replace Java, when Java is all about ecosystem, tooling, maturity and talent pool. And it has generics. I mean I am no Java expert, but e.g Android Studio is miles ahead anything the go team will be able to ship in the next few years. And I don't think they're even focusing on building such tools since they seem to be stuck on building a debugger right now.
- vardump 11y ago
  Java doesn't actually have runtime generics. Just type erasure syntactic sugar. ArrayList<Integer> is the same type at runtime as ArrayList<Foo>.
  - omginternets 11y ago
    This strikes me as a distinction without a difference, in the present case. How is this meaningfully different from the programmer's perspective?
    - vardump 11y ago
      You can't distinguish them at runtime from each other. Your memory consumption is higher, because type erasure requires elementary types to be boxed. Since the boxed value is itself allocated somewhere else, there's indirection. Indirection means CPU stalls. Another consequence is data cache pollution. There are just 512 of 64 byte L1D cache lines. Other than that, I guess nothing.
      - AnimalMuppet 11y ago
        But if you're worried about that amount of memory consumption, why are you using Java? If you need that much control over memory, Java may not be the language for you. Ditto if you're worried about the performance hit from cache misses.
  - blub 11y ago
    Sure, but I'll take it if that means I can at least use some type of generics. :) In my experience it's decent, even if not as powerful as C++ templates. Being able to specialize containers is a basic comfort for me.

lmm 11y ago

I don't think every language needs to be rigid - something like TypeScript's gradual, unsound typing can be very valuable, and I certainly think there's a place for a language where casting is easy and idiomatic. But you can do that and still enable generics, covariance and the like - as TypeScript in fact does. What's incredibly infuriating to see a language that clearly has everything it needs to offer generics - indeed it clearly has a generics implementation already written, since the builtin types are generic - but it won't let me use them.