10 ms·

With it being so consistent and predictable, I wonder why it hasn’t displaced .NET and Java in the enterprise for back end development. Maybe because a framewo

With it being so consistent and predictable, I wonder why it hasn’t displaced .NET and Java in the enterprise for back end development. Maybe because a framework like ASP.NET or Spring that covers like 80+% of the enterprise needs hasn’t quite emerged? Or perhaps we just need to give it a decade or so. There are still very few Go jobs in my country, most are either .NET, Java or PHP.

cookiengineer 2y ago
> ASP.NET or Spring (Disclaimer: I don't agree with HTMX rendering HTML chunks on the backend side, and I think that APIs should be HTTP-cacheable and use REST/JSON) Currently I am trying to get better at using Go with WebAssembly for the frontend. I love to use the webview/webview bindings to build local GUIs, but the need for redundant code in JavaScript for client data transfers and input data validation are annoying me a bit much. I am trying to find out a paradigm that could benefit from the strength of JSON marshalling, with the idea that you can map routes to structs, for example, and where a unified "Validate() (bool, error)" method as an interface is enough to use the same structs on both the frontend and backend, for both serialization and validation/sanitization. Having said that, I think that what's missing the most in go right now is a good UI framework for the web, but it's hard to find a paradigm that fits nicely into the language while also being able to handle dynamic data/refreshes/render loops without getting too bloated too quickly.
- wordofx 2y ago
  > and I think that APIs should be HTTP-cacheable Rendering html on the server does not make it not cacheable. The vast majority of people do not need graphql or shift their compute to the client with a junk react app with adhoc json endpoints everywhere.
  - KronisLV 2y ago
    I think server side rendering can often be pretty comfortable to use! That said, I’ve also worked with JSF and PrimeFaces project and the ones I’ve seen have been more burdensome from a maintenance perspective and also more buggy than most SPAs that I’ve worked with. I’ve also seen large monoliths where the tight coupling slows updates down a whole bunch, as opposed to the presentation being in a SPA that’s separate from an API that can be more limited in its scope (nothing wrong with using ASP.NET and Spring for just an API). Heck, I’ve migrated a SPA from the now defunct AngularJS to Vue and it felt better than having a legacy project that’s stuck on an old version of Spring and PrimeFaces because there’s so many moving parts that when you try to update anything, everything breaks. Plus, turning a SPA into a PWA is a fairly pleasant experience. I don’t think most folks need GraphQL though, especially when we can barely do RESTful API correctly and not even all places use OpenAPI specs and tooling, making client code impossible to generate (even SOAP did a better job in that particular regard with how widespread WSDL was).
trustno2 2y ago
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.
Philip-J-Fry 2y ago
Go is displacing .NET where I work for backend development. We still use .NET for Windows GUIs but any sort of server code is mostly Go going forward.
Cthulhu_ 2y ago
It's not yet an enterprise language; along the languages/frameworks, there's a huge ecosystem of QA, monitoring, security, etc solutions in the Java/.NET space that just isn't there in Go. I mean there's a slow shift, I keep hearing of "rewriting a Java codebase to Go", but it'll be a slow process. And especially the bigger projects that represent 30 years of Java development will and should be reluctant to start rewriting things.
lifty 2y ago
In my enterprise neck of the woods Go is steadily taking over backend development.
pjmlp 2y ago
Thankfully, it is enough that it is a must in DevOps space.

cookiengineer 2y ago

> ASP.NET or Spring (Disclaimer: I don't agree with HTMX rendering HTML chunks on the backend side, and I think that APIs should be HTTP-cacheable and use REST/JSON) Currently I am trying to get better at using Go with WebAssembly for the frontend. I love to use the webview/webview bindings to build local GUIs, but the need for redundant code in JavaScript for client data transfers and input data validation are annoying me a bit much. I am trying to find out a paradigm that could benefit from the strength of JSON marshalling, with the idea that you can map routes to structs, for example, and where a unified "Validate() (bool, error)" method as an interface is enough to use the same structs on both the frontend and backend, for both serialization and validation/sanitization. Having said that, I think that what's missing the most in go right now is a good UI framework for the web, but it's hard to find a paradigm that fits nicely into the language while also being able to handle dynamic data/refreshes/render loops without getting too bloated too quickly.

wordofx 2y ago
> and I think that APIs should be HTTP-cacheable Rendering html on the server does not make it not cacheable. The vast majority of people do not need graphql or shift their compute to the client with a junk react app with adhoc json endpoints everywhere.
- KronisLV 2y ago
  I think server side rendering can often be pretty comfortable to use! That said, I’ve also worked with JSF and PrimeFaces project and the ones I’ve seen have been more burdensome from a maintenance perspective and also more buggy than most SPAs that I’ve worked with. I’ve also seen large monoliths where the tight coupling slows updates down a whole bunch, as opposed to the presentation being in a SPA that’s separate from an API that can be more limited in its scope (nothing wrong with using ASP.NET and Spring for just an API). Heck, I’ve migrated a SPA from the now defunct AngularJS to Vue and it felt better than having a legacy project that’s stuck on an old version of Spring and PrimeFaces because there’s so many moving parts that when you try to update anything, everything breaks. Plus, turning a SPA into a PWA is a fairly pleasant experience. I don’t think most folks need GraphQL though, especially when we can barely do RESTful API correctly and not even all places use OpenAPI specs and tooling, making client code impossible to generate (even SOAP did a better job in that particular regard with how widespread WSDL was).

trustno2 2y ago

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.

Philip-J-Fry 2y ago

Go is displacing .NET where I work for backend development. We still use .NET for Windows GUIs but any sort of server code is mostly Go going forward.

Cthulhu_ 2y ago

It's not yet an enterprise language; along the languages/frameworks, there's a huge ecosystem of QA, monitoring, security, etc solutions in the Java/.NET space that just isn't there in Go. I mean there's a slow shift, I keep hearing of "rewriting a Java codebase to Go", but it'll be a slow process. And especially the bigger projects that represent 30 years of Java development will and should be reluctant to start rewriting things.

lifty 2y ago

In my enterprise neck of the woods Go is steadily taking over backend development.

pjmlp 2y ago

Thankfully, it is enough that it is a must in DevOps space.