4 ms·

I see the appeal of it for big enterprise teams composed of disposable programmers Can you explain? Why are go programmers "disposable?" Is it because th

I see the appeal of it for big enterprise teams composed of disposable programmers Can you explain? Why are go programmers "disposable?" Is it because the code is understandable (especially following our style guide / enforcing gofmt, godoc, etc)? I do find our go code to be that way, but I don't think that's a bad thing. Productivity in Go is an illusion I feel productive in Go. Can you explain this statement? I like dealing with a simpler toolchain as the op mentioned.

glennsl 11y ago
I'm not the parent, but my impression is that Go is productive more in the sense of quantity than quality. It is easy to pick up, understand and use. But it is also very error prone, because its type system is poorly suited for proper error handling, nulls and generic code. It's certainly better than C and most dynamic languages, but that's not setting the bar very high. I really see no reason to pick up Go these days unless you're a fan of 80s retro hits. If you want most of the goodness of Rust combined with the easiness of Go, look to Kotlin and Swift.
- catnaroek 11y ago
  > It is easy to pick up, understand and use. But it is also very error prone These two sentences are badly in conflict. How can you say you “understand” something if you find yourself repeatedly making mistakes when you use it?
  - glennsl 11y ago
    Compare a hammer and nails to a nailgun with various safety mechanisms. Which one do you think is easier to understand, and which is more prone to sore fingers?
    - catnaroek 11y ago
      > Which one do you think is easier to understand? For a toolmaker, the hammer. For a user, the nailgun. Also, there's a qualitative difference between physical tools and programming languages. The design of a physical tool can only lessen the likelihood of an accident and/or the seriousness of its consequences, but never entirely rule them out - that's why they're called “accidents”. On the other hand, programming languages can be designed to treat logical errors as invalid code. A program that doesn't compile is completely guaranteed not to corrupt your data, reveal your passwords to hackers, etc.
      - glennsl 11y ago
        What if you can't understand the logic of the compiler, and therefore aren't able to write any code in the language at all? Sure it's not very error-prone, but it's also not very useful. I'm a big fan of Rust precisely because of its safety features. Even if you don't need manual memory management there are huge benefits to resource management safety that no other language can provide. But I still recognize that there's a trade-off here.
- kajecounterhack 11y ago
  It's certainly better than C and most dynamic languages, but that's not setting the bar very high. I'm not sure I agree with that sentiment; C and dynamic languages are used in important applications and being better than them for the same tasks does seem to be a design goal of go. I personally feel that it accomplishes this in a number of areas. It is easy to pick up, understand, and use. This is true and I think it's a huge benefit. But it is also very error prone, because its type system is poorly suited for proper error handling, nulls and generic code That's your opinion. It's less safe than rust, more safe than python. I think it has a rather large niche. I personally like interfaces and that idiomatic golang testing uses language primitives. It's weird to me that people compare Go and Rust, they're languages with very different motivations.
  - glennsl 11y ago
    > C and dynamic languages are used in important applications and being better than them for the same tasks does seem to be a design goal of go C is essentially popular because it's popular. And it therefore has a huge ecosystem, can run on pretty much anything and has tons of code already written. That's a huge benefit, and one that Go does not have because it hasn't existed as the dominant language for 45 years yet. Popular dynamic languages have the benefit of being toys with the bare minimum of features needed to scale beyond toy programs. You can build a house with legos too. It won't be a good house, and it won't be very cost-effective, but it's certainly possible. > That's your opinion. No, it's not just my opinion. A well-designed type system eliminates the possibility of you making certain types of very common errors. It will refuse to allow you, and it will sometimes even help you understand why, and what you should have done instead. The complexity of Rust comes mostly from how the type system has been designed to handle manual memory management. If you take that part out and replace it with garbage collection, you'll get a language that is both safe and easy to learn and understand. Not quite as safe as Rust, and not quite as simple as Go, but very close in both regards. Languages like this do exist. See Kotlin and Swift, for example. > It's weird to me that people compare Go and Rust, they're languages with very different motivations. In this we agree. And I'm not arguing for Rust as a substitute for Go. But I am arguing for ignoring a language that ignores much of what the rest of us have learnt about type systems and programming languages during the past half a century (in real years, not tech years).
cwyers 11y ago
Not who you're responding to, but go's ethos and tooling all seem oriented towards There's One Way To Do It, no cleverness, nothing like C++ where one shop's parts of the language used differs greatly from another's. That makes programmers much easier to swap in and out in a large project. I have no idea how productive go is and can't speak to it, but everything I have heard about go makes it sound like making programmers fungible is a design goal.

glennsl 11y ago

I'm not the parent, but my impression is that Go is productive more in the sense of quantity than quality. It is easy to pick up, understand and use. But it is also very error prone, because its type system is poorly suited for proper error handling, nulls and generic code. It's certainly better than C and most dynamic languages, but that's not setting the bar very high. I really see no reason to pick up Go these days unless you're a fan of 80s retro hits. If you want most of the goodness of Rust combined with the easiness of Go, look to Kotlin and Swift.

catnaroek 11y ago
> It is easy to pick up, understand and use. But it is also very error prone These two sentences are badly in conflict. How can you say you “understand” something if you find yourself repeatedly making mistakes when you use it?
- glennsl 11y ago
  Compare a hammer and nails to a nailgun with various safety mechanisms. Which one do you think is easier to understand, and which is more prone to sore fingers?
  - catnaroek 11y ago
    > Which one do you think is easier to understand? For a toolmaker, the hammer. For a user, the nailgun. Also, there's a qualitative difference between physical tools and programming languages. The design of a physical tool can only lessen the likelihood of an accident and/or the seriousness of its consequences, but never entirely rule them out - that's why they're called “accidents”. On the other hand, programming languages can be designed to treat logical errors as invalid code. A program that doesn't compile is completely guaranteed not to corrupt your data, reveal your passwords to hackers, etc.
    - glennsl 11y ago
      What if you can't understand the logic of the compiler, and therefore aren't able to write any code in the language at all? Sure it's not very error-prone, but it's also not very useful. I'm a big fan of Rust precisely because of its safety features. Even if you don't need manual memory management there are huge benefits to resource management safety that no other language can provide. But I still recognize that there's a trade-off here.
kajecounterhack 11y ago
It's certainly better than C and most dynamic languages, but that's not setting the bar very high. I'm not sure I agree with that sentiment; C and dynamic languages are used in important applications and being better than them for the same tasks does seem to be a design goal of go. I personally feel that it accomplishes this in a number of areas. It is easy to pick up, understand, and use. This is true and I think it's a huge benefit. But it is also very error prone, because its type system is poorly suited for proper error handling, nulls and generic code That's your opinion. It's less safe than rust, more safe than python. I think it has a rather large niche. I personally like interfaces and that idiomatic golang testing uses language primitives. It's weird to me that people compare Go and Rust, they're languages with very different motivations.
- glennsl 11y ago
  > C and dynamic languages are used in important applications and being better than them for the same tasks does seem to be a design goal of go C is essentially popular because it's popular. And it therefore has a huge ecosystem, can run on pretty much anything and has tons of code already written. That's a huge benefit, and one that Go does not have because it hasn't existed as the dominant language for 45 years yet. Popular dynamic languages have the benefit of being toys with the bare minimum of features needed to scale beyond toy programs. You can build a house with legos too. It won't be a good house, and it won't be very cost-effective, but it's certainly possible. > That's your opinion. No, it's not just my opinion. A well-designed type system eliminates the possibility of you making certain types of very common errors. It will refuse to allow you, and it will sometimes even help you understand why, and what you should have done instead. The complexity of Rust comes mostly from how the type system has been designed to handle manual memory management. If you take that part out and replace it with garbage collection, you'll get a language that is both safe and easy to learn and understand. Not quite as safe as Rust, and not quite as simple as Go, but very close in both regards. Languages like this do exist. See Kotlin and Swift, for example. > It's weird to me that people compare Go and Rust, they're languages with very different motivations. In this we agree. And I'm not arguing for Rust as a substitute for Go. But I am arguing for ignoring a language that ignores much of what the rest of us have learnt about type systems and programming languages during the past half a century (in real years, not tech years).

cwyers 11y ago

Not who you're responding to, but go's ethos and tooling all seem oriented towards There's One Way To Do It, no cleverness, nothing like C++ where one shop's parts of the language used differs greatly from another's. That makes programmers much easier to swap in and out in a large project. I have no idea how productive go is and can't speak to it, but everything I have heard about go makes it sound like making programmers fungible is a design goal.