Hacker News Reader

Comment by msluyter | Hacker News Reader

Like someone mentioned, it's hard to answer this in the general case. Factors to consider would be: a) are you dependent on the JVM and Java ecosystem? b) Are you already familiar/comfortable with Java/Scala? "Yes" answers to both of these might lean you towards Kotlin.

c) is speed essential? d) are you doing systems programming as opposed to CRUD webapps?[1] These might lead you to Go.

[1] I know you can do the latter in Go, but it's unclear that it's as easy/productive as in other langs currently (nor have I directly compared, say, Revel to other frameworks, so someone else is probably better qualified to answer this question.)

View on HN

If speed is essential you'd use C++. But you could use Java too. There are useful benchmarks of server frameworks here:

https://www.techempower.com/benchmarks/

As you can see the top frameworks are all C++ or Java. A Java servlet based framework clocks in 3rd with 178k/sec. Go's first entry is at 10th place with 141k/sec.

The next time go appears it's the "kami" framework with just 58k/sec - slower than nodejs!

Go is being used quite a bit for crud. I've spent the last year at a big co where that's what it's used for. I think the old problem of the ambiguous word "systems" comes in here - op-systems vs ent-systems. Go is for ent-systems not op-systems. A lot of ent-systems are crud, including microservice hell where 95% of the program is boilerplate config, http, metrics, logging, crud, wrapping a couple of tiny functions that were mildly interesting to program.

You might want to uppercase your acronyms. "Crud" means "something dirty and disgusting" or "nonsense". CRUD has a very different meaning.

I've found low-level web servers (i.e. basic i/o) are really easy to implement in Go. CRUD webapps with an auth layer, database management layer, JSON serialization/deserialization layer etc. are certainly harder to write as you pointed out, but it's possible.

> JSON serialization/deserialization layer

Why do you need a whole "layer" for this? I recently wrote a microservice in Go with a JSON-emitting RESTy API, and my JSON serialization layer is two functions for a total of 20 limes: https://github.com/sapcc/limes/blob/0735bd6de4e49f900ab8d97a... (ignore the unrelated function inbetween; I cannot select non-contiguous areas in GitHub source code listings)

I think what OP means is a layer in a sense of mapping JSON to your own data types. You just invoke json.Marshal/Unmarshal here, which deserializes into maps and arrays of interface{} - i.e. effectively an untyped data structure.

No, it doesn't. json.Un/Marshal understand all data types; you just need to annotate fields in structs with their JSON field names.

If you want speed, use golang ?

Java (and kotlin) are faster than Go in almost all cases (except for startup time) (and even there difference is shrinking, plus you get a lot back for that startup time). C, if you must, is faster still, and C++ can be faster as well.

As a quick (and inaccurate) rule, any program that runs longer than 10-20 seconds will be faster in Java than in Go.

What about memory? I wouldn't run any kind of production Java web server with 256M RAM server. I've had impression that Golang is much less memory-dependant.

Not sure about the most recent versions, but Go can run on MIPS platforms with 32MB RAM.

But if you care more about latency and predictable performance, Go's very low-latency GC is attractive.

Not really. Golang provides "mostly" low latency, at the cost of everything else, most significantly throughput, and load.

https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

TLDR: Go's GC will only be realtime as long as you use it only minimally. With tiny programs, that's fine of course. With larger programs, it will block for a looooong time. That's masked by the language making it very hard to write larger programs in the first place. For instance, by not having decent data structures (not even a tree, seriously ?)

I guarantee if you actually use the GC, there comes a point where java runs circles around Go. Hell, there comes a point where the lua GC runs circles around the Go one. That point is a lot closer than you might think, and as a bad rule of thumb you should probably think of it like this: if any of cpu, mem, i/o goes >80% of the machine's capacity, Go will disappoint very badly compared to Java (GC using more memory, using more cpu, longer pauses, ...). But if all those values are at 2% of capacity, Go's runtime will perform better.

Tradeoffs. Everything is tradeoffs. Go is not better than Java/JVM, it's worse. But a different set of tradeoffs means that there are circumstances where it'll beat the other set of tradeoffs. But "close to 0", Go will beat the JVM.

There's no reason you can't write a tree in Go. Take a look at go/ast.

Hmm, I guess I was going of benchmarks such as these, which suggest Go is, well, faster some of the time?

https://benchmarksgame.alioth.debian.org/u64q/go.html

However, perhaps as you indicate these are including JVM startup time and thus tainting the results. For some reason I had gotten it into my head that Go was faster than Java, but it's been a couple of years since I've used either one, so I definitely may be off on that point.

Last time I checked, the maintainers of that game said the startup time is negligible.

Go is a language with at least two compilers. One of them is gcc (yes, gcc, since version 4.6). I doubt Go code compiled with gcc is much slower than C, and can't think of a reason why Java would be faster.

"faster than Go" could mean any compiler

Reply on news.ycombinator.com