Hacker News Reader

Comment by perseusprime11 | Hacker News Reader

Kotlin is becoming more and more popular. Are we better off learning Kotlin instead of Go?

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.)

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

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 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.

Kotlin is not a replacement for Go - it's a fair bit higher on the "abstraction" scale, not the least of which is that it requires a VM.

That said, I'm not convinced that Go's place on that scale is useful in general. It feels like, if raw performance is desirable, then something like Rust - with stronger static typing (and so no overhead on boxing values as interfaces, for example) and no GC is going to be better. And if higher-level, more powerful abstractions are required, then something like Kotlin is going to be better. Go is in that awkward spot where it makes you give up enough of the latter to be painful, but doesn't really make up for it with more of the former.

Of course, this is a subjective opinion. YMMV.

Kotlin and vertx is a brilliant alternative to golang in general.

And if course, if you have even remote plans of doing anything on Android...It now makes much more sense than ever

That's an impossible to answer question because we don't know your situation or use-case.

I want to learn the most efficient language for creating high-performance APIs ( Micro-services).

> Kotlin is becoming more and more popular. Are we better off learning Kotlin instead of Go?

How does Kotlin handles concurrency? Now I've heard that Kotlin has a "Kotlin native" version. I didn't try it yet, but if that's the case and it has good concurrency support then Yes, in theory it could compete with Go, more than Scala native would, Scala is too complicated for the kind of audience attracted by Go.

On JVM and Native kotlin does support coroutines and supports all kinds of concurrency models (including go style goroutines). Check this more details - https://github.com/Kotlin/kotlinx.coroutines/blob/master/cor...

I don't think that has to routines. Goroutines are multiplexed across threads automatically by the scheduler, so all I have to care about is describing concurrent operations. Further, all I/o is async under the hood, so you never have to worry if a call will block the thread. Also, Go's concurrency is muuccchhh simpler.

of course it depends on your case , but my guess is that if you ask the question then you should probably invest time on kotlin ( because it aims for a larger scope of use cases)

People coding in go for real world projects usualy know that go fits the tradeoffs they're looking for.

either that or they started a company when the hypetrain was around

Reply on news.ycombinator.com