3 ms·

> can someone weigh in on how it is building large "enterprise-grade" applications in Go 1.x given how (purposefully) constrained the type system in Go is? I'm

> can someone weigh in on how it is building large "enterprise-grade" applications in Go 1.x given how (purposefully) constrained the type system in Go is? I'm not a Go developer, but as a C# developer I can say that a more powerful type system, generics etc can be both a boon and a curse - especially so for large enterprise systems. I've seen these go both ways, and it ultimately comes down to two things: 1. being able to create a design with the right abstractions more or less from the start 2. not over-using generics and inheritance If you don't succeed with these, or/and you don't forsee some things you end up needing later, the code becomes an incomprehensible mess, as developers try to crowbar functionality into the constraints of the design, or make things even more complicated by refactoring and introducing even more use of generics and inheritance.

rob74 5y ago
Funny that you mention generics and inheritance in the same sentence - with all the hand-wringing going on about the lack of generics in Go, I would have thought more people would also complain about the lack of inheritance, but that doesn't seem to be a thing - except for the people who don't consider Go object-oriented because it doesn't have inheritance, but that's another topic... But yeah, the design decisions taken for Go tend to lead to software that is easier to refactor, because you don't end up building an elaborate type system that boxes you in and is difficult to change when requirements change (as they always do).
- emodendroket 5y ago
  I have heard some co-workers complain but I think it is one of their best decisions.
- nicoburns 5y ago
  > with all the hand-wringing going on about the lack of generics in Go, I would have thought more people would also complain about the lack of inheritance, but that doesn't seem to be a thing Given that use of inheritance is typically discouraged even in languages that support it, that's hardly surprising. OTOH, generics are typically pervasive in languages that support them (and don't cause problems in the same way).
- radicalbyte 5y ago
  Inheritance is hardly used anymore - honestly I think that we've thrown the baby out with the bath water a little here - at the cost of avoiding abuse by bad / inexperienced developers. Go is pretty simple, nice enough language. Is it just a "better C" but without the benefits (and compile times) of Rust?

rob74 5y ago

Funny that you mention generics and inheritance in the same sentence - with all the hand-wringing going on about the lack of generics in Go, I would have thought more people would also complain about the lack of inheritance, but that doesn't seem to be a thing - except for the people who don't consider Go object-oriented because it doesn't have inheritance, but that's another topic... But yeah, the design decisions taken for Go tend to lead to software that is easier to refactor, because you don't end up building an elaborate type system that boxes you in and is difficult to change when requirements change (as they always do).

emodendroket 5y ago
I have heard some co-workers complain but I think it is one of their best decisions.
nicoburns 5y ago
> with all the hand-wringing going on about the lack of generics in Go, I would have thought more people would also complain about the lack of inheritance, but that doesn't seem to be a thing Given that use of inheritance is typically discouraged even in languages that support it, that's hardly surprising. OTOH, generics are typically pervasive in languages that support them (and don't cause problems in the same way).
radicalbyte 5y ago
Inheritance is hardly used anymore - honestly I think that we've thrown the baby out with the bath water a little here - at the cost of avoiding abuse by bad / inexperienced developers. Go is pretty simple, nice enough language. Is it just a "better C" but without the benefits (and compile times) of Rust?