9 ms·

Go did rise to prominence by being the programming language behind such high profile software as Kubernetes, Docker, and Prometheus. None of those are business

Go did rise to prominence by being the programming language behind such high profile software as Kubernetes, Docker, and Prometheus. None of those are business applications and Rob Pike (ex Bell Labs guru and co-inventor of Go) gave a presentation about Go in 2015 where he explicitly identified that Go was invented for infrastructure and not business applications. I have encountered many engineers who are excited about Go and want to adopt it for enterprise systems. In 2019. I evaluated Go for that purpose. You can read my evaluation at http://glennengstrand.info/software/architecture/microservice/golang http://glennengstrand.info/software/architecture/microservic... What I discovered is that Go is not any faster than Java on a light weight framework. Here is the part that may seem controversial for the folks here. The simplicity of Go did not result in simpler systems. I found that the lack of inheritance hampered me in expressing solutions to complex business rules and data models. Many of you may disagree with that and counter argue that inheritance is a bad thing. That is most probably one reason why there is so much interest in Go. It intentionally lacks support for inheritance. I agree that inheritance can and has been misused a lot. It is an advanced programming language feature that should be used sparingly. Removing inheritance entirely reduces the expressiveness of the programming language, especially when it comes to enterprise computing.

dimitrios1 5y ago
(a pedantic correction: Pike originally describes it as a systems language, which can include infrastructure) Thing is none of the above is going to apply when generics land. You mentioned kubernetes which use complex, maintainable abstractions and structures with only the facilities Go provides. There isn't that much difference between writing a maintainable system, whether the primary user is the business, or other software.
- gengstrand 5y ago
  https://www.youtube.com/watch?v=rFejpH_tAHM https://www.youtube.com/watch?v=rFejpH_tAHM “Go is software for the parts that we work on which is mostly infrastructure.” Generics is a good thing and I look forward to seeing the details in how Go will support it.
  - gher-shyu3i 5y ago
    You can say the same about Java and C#. These claims about golang are all baseless as far as I'm concerned, especially since they're contradicted by reality.
hannofcart 5y ago
Would you be able to share an example of an abstraction you wanted to create in enterprise computing where lack of inheritance stymied you?
- segmondy 5y ago
  I was going along with the comment till they mentioned inheritance too. I hope they can share such an example.
  - gengstrand 5y ago
    Like I already said, inheritance is an advanced programming language feature that is easily misused. To give a specific example out of context would just leave you open to inventing context that would yield inheritance as an improper choice. There is plenty of advice online already about how to use inheritance properly. In general, inheritance should be used to signal taxonomy. It should not be used to DRY unless there are good extenuating reasons behind that. There are lots of frameworks that require the use of inheritance which is somewhat unfortunate. You are most probably okay until you find yourself starting to form deep inheritance hierarchies. If you do have deep taxonomies, then consider modeling that in data (e.g. widgetType or widgetParent) instead of using inheritance. The decorator pattern is also used a lot when inheritance gets out of hand.
    - sagichmal 5y ago
      > inheritance is an advanced programming language feature It really isn't. > that is easily misused. If a tool is misused frequently enough, it really isn't the fault of the users.
bndw 5y ago
In my experience, I've found the lack of polymorphism to be the larger challenge in building complex business systems in Go. Managing a bunch of polymorphic entities in Go often requires implementing a bunch of interfaces in various types. You then have to write a bunch of mapping logic for every type, driven by type assertions. Apply this in a large codebase that encapsulates transport, data access, and so on and you end up with a ton of complexity.
gher-shyu3i 5y ago
> The simplicity of Go did not result in simpler systems. I echo this 100%. I worked at an employer who heavily used golang. The resulting projects were honestly a mess, yet they pushed through. What's ironic, is that they ended up reinventing the wheel on so many different things, including DI and an entire application framework. Millions of dollars spent writing and maintaining these libraries, where Java already had them ages ago. As you point out, the modeling capability of golang is extremely subpar. It results in verbose code that is very sparse, lots of code to implement something that would have taken a few lines in a language like Java and C#, let alone something more dense like Scala. The way interfaces are handled in golang makes it very annoying to try to find out which types implement said interface. It puts a lot of pressure on the IDE to search the entire code base, and you end up with types you don't even care about. It clearly shows that the golang authors did not have IDEs in mind when writing the language, which is just absurd as it's supposedly a language designed for "programming in the large". Anyone who used "goland" knows what I'm talking about. Try refactoring a type, and have the IDE scan the entire code base to look for comment strings, which it has to because golang has no notion of doc strings like Java or C#. Add features like records, pattern matching, enums (the amount of code that had to be written to implement something to emulate enums was just absurd and frustrating to deal with, not to mention error prone). The concurrency aspect of golang is decent (though it will be even better in Java). Other than that, the language doesn't really have anything going for it other than having a large brand name backing it.
- konart 5y ago
  >It puts a lot of pressure on the IDE to search the entire code base, and you end up with types you don't even care about. It clearly shows that the golang authors did not have IDEs in mind when writing the language, which is just absurd as it's supposedly a language designed for "programming in the large". Anyone who used "goland" knows what I'm talking about. Try refactoring a type, and have the IDE scan the entire code base to look for comment strings, which it has to because golang has no notion of doc strings like Java or C#. Even if this was the case years ago - it is not now with an LSP.
  - gher-shyu3i 5y ago
kodah 5y ago
I've used Go on both infrastructure and web projects. "The simplicity of Go" entirely depends on architecture and code quality. Go will force you into some design patterns that are not too favorable if you're not familiar with them. When I was helping people with Go I would see it a lot when people first start using interfaces. I would never claim, as you have, that Go cannot be used on the web or that it won't be just as effective as Java + Spring. Generally I've found most tasks between Java and Go to be similar in complexity (and requiring different approaches), as it seems you found. Where there is a massive difference is tooling and dependency management. That absolutely contributes to developer ergonomics and is a fairly weighty point that is not mentioned in your analysis. Personally speaking, choosing between languages is a non-starter conversation for me. At this point, since my childhood, I have rotated through 10+ languages. Languages are certainly tools and picking the right tool for the job is important. That said, I don't want to work at another company that mandates one language (as is commonly the case with Java) across the entire enterprise. We need solutions that bridge tooling language gaps for enterprises more than we need archaic mandates about what I'm allowed to write in for a given purpose.
- deleted 5y ago
  [deleted]
Thaxll 5y ago
The thing with Java is that it's harder to make code fast, in Go it's easier.
- winrid 5y ago
  Could you provide an example or citation?
- deleted 5y ago
  [deleted]
- erik_seaberg 5y ago
  Sun made huge investments into HotSpot to optimize reusable object-oriented code. As I understand it, GC and interface method dispatch on heap objects are relatively slower in Go so they’re mildly discouraged.
- NovaX 5y ago
  My only experience with Go was to help advise a team when porting a Java cache. They struggled with performance because Go kept fighting them. This was partially due to it having a poor concurrency library, resulting in excessive use of read/write locks whereas Java's advanced capabilities made more things lock-free. The database founder noted that Golang is slow single-threaded but makes up for it via concurrency and low latency. To my unexperienced eyes, it seemed like a real PITA mostly because the Go authors insisted on artificial limitations externally, but bypassed them internally. I certainly have not found it hard to make Java fast and the core developers have always been open minded when I've talked to them.
hughrr 5y ago
I’ve done a huge amount of “enterprise architecture” going back 20 years or so. I’ve designed and built horrible things that scare most people to death. Imagine monoliths with over 1000 DD and ORM mapped business domain classes, 2000 http endpoints and hundreds of database tables glued into tens of megs of Hibernate mappings. Inheritance is the number one cause of these turning into a massive shit show. It’s not a pattern that can ever be refactored into something else down the line once the decision is made. You end up with things that can’t be fixed and escalating costs like you have never seen just to keep the plates spinning. I always favour composition for that and very light weight service oriented architecture. Roughly the only thing that scales is things that have fairly strict command-query type segregation. Carefully designed REST interfaces are a good example of that. Regarding complex business rules they are mostly best evaluated through simple stacked middleware, messaging, matching, routing and workflow style applications. All of those are feasible with the simplest of languages. Hell half the world is still hanging off rancid bits of COBOL. If you are short circuiting your evaluation on this basis I think you are making a lot of noise without a lot of experience.

dimitrios1 5y ago

(a pedantic correction: Pike originally describes it as a systems language, which can include infrastructure) Thing is none of the above is going to apply when generics land. You mentioned kubernetes which use complex, maintainable abstractions and structures with only the facilities Go provides. There isn't that much difference between writing a maintainable system, whether the primary user is the business, or other software.

gengstrand 5y ago
https://www.youtube.com/watch?v=rFejpH_tAHM https://www.youtube.com/watch?v=rFejpH_tAHM “Go is software for the parts that we work on which is mostly infrastructure.” Generics is a good thing and I look forward to seeing the details in how Go will support it.
- gher-shyu3i 5y ago
  You can say the same about Java and C#. These claims about golang are all baseless as far as I'm concerned, especially since they're contradicted by reality.

hannofcart 5y ago

Would you be able to share an example of an abstraction you wanted to create in enterprise computing where lack of inheritance stymied you?

segmondy 5y ago
I was going along with the comment till they mentioned inheritance too. I hope they can share such an example.
- gengstrand 5y ago
  Like I already said, inheritance is an advanced programming language feature that is easily misused. To give a specific example out of context would just leave you open to inventing context that would yield inheritance as an improper choice. There is plenty of advice online already about how to use inheritance properly. In general, inheritance should be used to signal taxonomy. It should not be used to DRY unless there are good extenuating reasons behind that. There are lots of frameworks that require the use of inheritance which is somewhat unfortunate. You are most probably okay until you find yourself starting to form deep inheritance hierarchies. If you do have deep taxonomies, then consider modeling that in data (e.g. widgetType or widgetParent) instead of using inheritance. The decorator pattern is also used a lot when inheritance gets out of hand.
  - sagichmal 5y ago
    > inheritance is an advanced programming language feature It really isn't. > that is easily misused. If a tool is misused frequently enough, it really isn't the fault of the users.

bndw 5y ago

In my experience, I've found the lack of polymorphism to be the larger challenge in building complex business systems in Go. Managing a bunch of polymorphic entities in Go often requires implementing a bunch of interfaces in various types. You then have to write a bunch of mapping logic for every type, driven by type assertions. Apply this in a large codebase that encapsulates transport, data access, and so on and you end up with a ton of complexity.

gher-shyu3i 5y ago

> The simplicity of Go did not result in simpler systems. I echo this 100%. I worked at an employer who heavily used golang. The resulting projects were honestly a mess, yet they pushed through. What's ironic, is that they ended up reinventing the wheel on so many different things, including DI and an entire application framework. Millions of dollars spent writing and maintaining these libraries, where Java already had them ages ago. As you point out, the modeling capability of golang is extremely subpar. It results in verbose code that is very sparse, lots of code to implement something that would have taken a few lines in a language like Java and C#, let alone something more dense like Scala. The way interfaces are handled in golang makes it very annoying to try to find out which types implement said interface. It puts a lot of pressure on the IDE to search the entire code base, and you end up with types you don't even care about. It clearly shows that the golang authors did not have IDEs in mind when writing the language, which is just absurd as it's supposedly a language designed for "programming in the large". Anyone who used "goland" knows what I'm talking about. Try refactoring a type, and have the IDE scan the entire code base to look for comment strings, which it has to because golang has no notion of doc strings like Java or C#. Add features like records, pattern matching, enums (the amount of code that had to be written to implement something to emulate enums was just absurd and frustrating to deal with, not to mention error prone). The concurrency aspect of golang is decent (though it will be even better in Java). Other than that, the language doesn't really have anything going for it other than having a large brand name backing it.

konart 5y ago
>It puts a lot of pressure on the IDE to search the entire code base, and you end up with types you don't even care about. It clearly shows that the golang authors did not have IDEs in mind when writing the language, which is just absurd as it's supposedly a language designed for "programming in the large". Anyone who used "goland" knows what I'm talking about. Try refactoring a type, and have the IDE scan the entire code base to look for comment strings, which it has to because golang has no notion of doc strings like Java or C#. Even if this was the case years ago - it is not now with an LSP.
- gher-shyu3i 5y ago

kodah 5y ago

I've used Go on both infrastructure and web projects. "The simplicity of Go" entirely depends on architecture and code quality. Go will force you into some design patterns that are not too favorable if you're not familiar with them. When I was helping people with Go I would see it a lot when people first start using interfaces. I would never claim, as you have, that Go cannot be used on the web or that it won't be just as effective as Java + Spring. Generally I've found most tasks between Java and Go to be similar in complexity (and requiring different approaches), as it seems you found. Where there is a massive difference is tooling and dependency management. That absolutely contributes to developer ergonomics and is a fairly weighty point that is not mentioned in your analysis. Personally speaking, choosing between languages is a non-starter conversation for me. At this point, since my childhood, I have rotated through 10+ languages. Languages are certainly tools and picking the right tool for the job is important. That said, I don't want to work at another company that mandates one language (as is commonly the case with Java) across the entire enterprise. We need solutions that bridge tooling language gaps for enterprises more than we need archaic mandates about what I'm allowed to write in for a given purpose.

deleted 5y ago
[deleted]

Thaxll 5y ago

The thing with Java is that it's harder to make code fast, in Go it's easier.

winrid 5y ago
Could you provide an example or citation?
deleted 5y ago
[deleted]
erik_seaberg 5y ago
Sun made huge investments into HotSpot to optimize reusable object-oriented code. As I understand it, GC and interface method dispatch on heap objects are relatively slower in Go so they’re mildly discouraged.
NovaX 5y ago
My only experience with Go was to help advise a team when porting a Java cache. They struggled with performance because Go kept fighting them. This was partially due to it having a poor concurrency library, resulting in excessive use of read/write locks whereas Java's advanced capabilities made more things lock-free. The database founder noted that Golang is slow single-threaded but makes up for it via concurrency and low latency. To my unexperienced eyes, it seemed like a real PITA mostly because the Go authors insisted on artificial limitations externally, but bypassed them internally. I certainly have not found it hard to make Java fast and the core developers have always been open minded when I've talked to them.

hughrr 5y ago

I’ve done a huge amount of “enterprise architecture” going back 20 years or so. I’ve designed and built horrible things that scare most people to death. Imagine monoliths with over 1000 DD and ORM mapped business domain classes, 2000 http endpoints and hundreds of database tables glued into tens of megs of Hibernate mappings. Inheritance is the number one cause of these turning into a massive shit show. It’s not a pattern that can ever be refactored into something else down the line once the decision is made. You end up with things that can’t be fixed and escalating costs like you have never seen just to keep the plates spinning. I always favour composition for that and very light weight service oriented architecture. Roughly the only thing that scales is things that have fairly strict command-query type segregation. Carefully designed REST interfaces are a good example of that. Regarding complex business rules they are mostly best evaluated through simple stacked middleware, messaging, matching, routing and workflow style applications. All of those are feasible with the simplest of languages. Hell half the world is still hanging off rancid bits of COBOL. If you are short circuiting your evaluation on this basis I think you are making a lot of noise without a lot of experience.