Building Web Apps in Go

Re:Building Web Apps in Go by pron on Monday March 28, 2016 @02:22AM (#11372994)

Rust and Go are so completely different that I don't see how they're similar. OTOH, I write most of my code in Java, and a little bit in Go, and can hardly tell the difference between the two (their goals, design philosophy and levels of abstraction are nearly identical). I use Go for small command-line apps, where it shines, and Java for more serious server-side software, where I can't do without its unparalleled monitoring and tooling and more, uhm, grownup approach towards dependencies and project management (unless you work like Google). I know some people don't like Java, but I'm puzzled when the same people like Go (I can understand how you can like neither, or, like me, both). I agree that the onboarding experience for Go is better and more familiar to people coming over from Python (perhaps to the point that to people coming from Python, Java and Go appear very different), but if you're used to Java, Go feels like Java-lite. You use it when you need something more quick-and-dirty (or for command-line apps; Go is a much better fit than Java for those), but you stick with the "full" version for the serious stuff.

[ Parent | on HN ]

Re:Building Web Apps in Go by geodel on Monday March 28, 2016 @10:39AM (#11374491)

The only reason I will stick with Java is because business applications are in Java and there is no reason to use any other language.

> their goals, design philosophy and levels of abstraction are nearly identical

I think it could not be more different. Java APIs (including libs by Sun/IBM/Oracle) is a manifestation of more is less which is exactly opposite of Go.

> Java for more serious server-side software

The seriousness part is only because serious folks (the one who fund projects) prefer Java. I too think this is very important if not the most important part.

> unparalleled monitoring and tooling and more,

I too would need lot of monitoring and tooling if Oracle/OpenJDK GC keeps crapping out for just 10-20GB heaps which is currently the case for us.

[ Parent | on HN ]

Re:Building Web Apps in Go by pron on Wednesday March 30, 2016 @06:12AM (#11388199)

> Java APIs (including libs by Sun/IBM/Oracle) is a manifestation of more is less which is exactly opposite of Go.

For example?

> The seriousness part is only because serious folks (the one who fund projects) prefer Java.

I disagree. There are plenty of design decisions in Go that make it less optimal for very large projects (e.g. dependencies, error handling, generics), but most of all lack of hackability. Go is one of the least hackable languages I've ever encountered, i.e. the only escape-hatch you have when you realize, 5 years into the project, that you need to circumvent some runtime semantics are either source-code instrumentation or hacking on the runtime itself.

> Oracle/OpenJDK GC keeps crapping out for just 10-20GB heaps which is currently the case for us.

There is no way Go's GC wouldn't crap out on you sooner (except maybe in the circumstances that are now addressed as part of Valhalla).

Having said that, I think Go is great, and is a natural fit for anyone who likes the Java philosophy (which is also the Go philosophy)[1]. Some design decisions and some implementation circumstances just make it less suitable for really big stuff.

[1]: Namely, reading comes before writing, no too-clever tricks, and no cutting-edge PL ideas; a "blue collar" language, as Gosling referred to it.

[ Parent | on HN ]

Re:Building Web Apps in Go by tome on Thursday March 31, 2016 @04:01AM (#11395658)

> I use Go for small command-line apps, where it shines

I'm curious. Is there empirical evidence proving that Go is better than Java for small command-line apps, or did you just use your personal judgement to reach this conclusion?

[ Parent | on HN ]

Re:Building Web Apps in Go by pron on Thursday March 31, 2016 @01:16PM (#11398798)

> Is there empirical evidence proving that Go is better than Java for small command-line apps

Sure. It doesn't require warmup, it's a little easier to deploy as a standalone executable, and performance is comparable to compiled Java code in programs of this size (you can easily confirm all three claims); those are pretty much the relevant requirements from many command line programs. It's not a property of the language but of its implementation choices (AOT compilation, statically linked runtime), which match the requirements of those kinds of applications better.

[ Parent | on HN ]