4 ms·

Go doesn't really lend itself that much into code with a lot of abstraction layers. If you try to do that, you will start to run against the language. The more

Go doesn't really lend itself that much into code with a lot of abstraction layers. If you try to do that, you will start to run against the language. The more enterprisey software usually have lots of layers for organizational reasons, and go doesn't really fit there. So I don't think it will really be a hit in the enterprise. yes there are orm solutions and DI frameworks and all that, but they always feel like they don't belong in the language. (Also, java and .net and php are much older and have much bigger enterprisey ecosystem.) I have seen go replacing the php stack though, and in some way the "original" python stack - but python now has ML.

jen20 2y ago
> usually have lots of layers for organizational reasons The ridiculous number of layers in Java or C# are more of a skill and guidance issue than anything else. Older languages don’t always mean over-attempted-abstraction (think C, for example).
- trustno2 2y ago
  I have worked in enterprises and the layers are usually an organizational issue that just acts as code issue. Structure of code often reflects structure of your company. The code is often maze of layers because the company is a maze of sub-committees. Java/C# fits more neatly in there. Although with Go, what can happen is that there is a maze of microservices. Maybe that's not that much better.
- pjmlp 2y ago
  Never seen CORBA and COM written in C, I guess. Enterprise Architects will do their beloved architectures with whatever languages are the tool of the day.
  - jen20 2y ago
    Ohhhh boy have I seen that. Like I say, it’s a skill issue, but those people tend to be in Java and C#, not Go and Rust.
    - pjmlp 2y ago
      Go has Kubernetes ecosystem for that, and Rust is yet to take off as application programming language embraced by Enterprise Architects at big corp.
      - jen20 2y ago
        The Kubernetes code base isn’t great, but the notion that the ecosystem is even nearly as complex as the average EA monstrosity implementing basic forms over data as multi-player Microsoft Access is fanciful at best.

jen20 2y ago

> usually have lots of layers for organizational reasons The ridiculous number of layers in Java or C# are more of a skill and guidance issue than anything else. Older languages don’t always mean over-attempted-abstraction (think C, for example).

trustno2 2y ago
I have worked in enterprises and the layers are usually an organizational issue that just acts as code issue. Structure of code often reflects structure of your company. The code is often maze of layers because the company is a maze of sub-committees. Java/C# fits more neatly in there. Although with Go, what can happen is that there is a maze of microservices. Maybe that's not that much better.
pjmlp 2y ago
Never seen CORBA and COM written in C, I guess. Enterprise Architects will do their beloved architectures with whatever languages are the tool of the day.
- jen20 2y ago
  Ohhhh boy have I seen that. Like I say, it’s a skill issue, but those people tend to be in Java and C#, not Go and Rust.
  - pjmlp 2y ago
    Go has Kubernetes ecosystem for that, and Rust is yet to take off as application programming language embraced by Enterprise Architects at big corp.
    - jen20 2y ago
      The Kubernetes code base isn’t great, but the notion that the ecosystem is even nearly as complex as the average EA monstrosity implementing basic forms over data as multi-player Microsoft Access is fanciful at best.