Hacker News Reader

Comment by threeseed | Hacker News Reader

Couldn't agree more.

Anyone who thinks Go will ever be a replacement for Java is frankly clueless about enterprise software development. Go has almost non-existant integration with enterprise systems e.g. SAP, Hadoop. It lacks operational management capabilities e.g. JMX. And seriously the range of libraries on the JVM covers pretty much everything e.g. banking/finance use cases.

And concerningly there is not a single reasonably sized Go project to get an understanding of how it works with 20, 50, 100 or 500+ developers working on the same codebase.

View on HN

Docker is fairly large, cloc output:

   ----------------------------------------------------------
   Language             files     blank    comment       code
   ----------------------------------------------------------
   Go                     750     14601       9901     115877
   CSS                      8       107        194      10010
   HTML                    11       362         21       3594
   Bourne Shell            28       391        323       2044
   Bourne Again Shell      25       249        185       1475
   Javascript              12       111         48        756
   Python                   1        23         24        192
   C                        1        20         19        179
   YAML                     4        25         13        162
   XML                      1         6          2         60
   make                     2        27          5         60
   Perl                     1        11         37         29
   vim script               2         8          3         13
   ----------------------------------------------------------
   SUM:                   846     15941      10775     134451
   ----------------------------------------------------------

And I believe there are a number of projects internally within Google but they tend not to talk about internal product technologies (at least at how large they are).

No Docker is not fairly large. It's tiny. 1M - 10M LOC is the size of most of the codebases I've worked on.

Most people simply don't have an understanding of enterprise applications. The majority of the apps are single codebase, Servlet/Spring type monstrosities. They are 10+ years old and have had hundreds of contract developers who come in, add a few new features and then go onto the next contract.

And my point is that I am yet to see what Go would be like in these situations.

It seems a little unfair to ding Golang for not providing evidence of something Golang was designed to avoid. "Where's all the boilerplate? Where are all the 10 layers of XML mapping? What would an AbstractStrategyFactory even look like?"

Rest assured, if Go manages to become a success in the enterprise you will get them.

It happened to every language without exception.

But will it happen to one without exceptions, as well?? :)

Panic/Recover will be used as expections.

If "enterprise applications" mean over-architectured monstrosities filled with boilerplate code, a hundred levels of indirection and horrible XML configuration files then thank god Go doesn't encourage that.

I think when people claim that Go is a replacement for Java, what they really mean is "Go has similar performance characteristics as the JVM and also doesn't require manual memory management".

Anyone who has ever worked in enterprise software can tell you, Go is (currently) exceptionally poorly suited for that style of development. I don't think that is an accident though. I think there is at least the implication that enterprise software development models and architectures are flawed at the core. Go seems to be designed from the start to prevent you from developing that way.

I may be reading more into the Go culture than I should, and I certainly don't think that there is proof that enterprise software can't be successful, but Go clearly steers you into building small, self contained servers that do one thing well and can go without change for a long time.

> there is not a single reasonably sized Go project

I'm not sure if I misunderstood your statement, but Go has Docker, CoreOS and numerous other projects which have more than 20 developers working on the same codebase.

Docker and CoreOS are tiny compared to many enterprise Java apps. And they don't have 20 full time, active developers all contributing at the same time (at least not from the commit log).

Take for example eBay or Amazon and the huge array of different use cases they support. Those are the typical sized Java applications we are talking about. Insurance, Banking, Finance etc. Legacy integration, payments, reporting, various web front ends. One codebase.

You are mistaken if you think Amazon is backed by "enterprise" Java apps from a single codebase.

I was under the impression that Amazon was primarily a collection of services written mostly in Perl. Socket, do you know?

What I've heard from a friend who's a SDE there is that because they have a Service-Oriented Architecture the individual teams can use just about whatever language they feel is best for the particular job. The other teams don't care because they're just making service calls. I'm sure that was mostly Perl in the 90s, but today it is mostly Java, because their HR strategy is basically to hoover up all the fresh CS grads, whose strongest language is almost always Java. And also because when Amazon started building their SOA, Java/XML/SOAP was all the rage.

For what it's worth, a pristine checkout of Eucalyptus[1], that has parts written in Java, appears to be around 430k loc of java (comments and white space included).

Also, OT, didn't realize Eucalyptus had worked so much towards friendly development, and was moving towards including RiakCS as a S3 work-a-like backend[2].

[1] https://github.com/eucalyptus/eucalyptus [2] https://github.com/eucalyptus/eucalyptus/wiki/Scalable-Walru...

[edit: yes, I realize you were probably talking about Amazon the shopping cart, not Amazon the IT infrastructure provider]

Reply on news.ycombinator.com