Anyone have opinion w.r.t. what the state of Kotli...

# getting-started

[Matti Viljamaa]

Anyone have opinion w.r.t. what the state of Kotlin is w.r.t. Golang in the same use cases?

I was confused in particular about the mention of Golang having more refined support for concurrency, but I was unsure as to whether this is some fixed feature of the language or whether it could be gained in Kotlin with time.

I wonder if Golang is to be thought more as a server language and Kotlin as an end-user language? My initial problem was about thinking why Kotlin cannot be used in the use cases where Golang is used.

[Jacob]

Much of the relative simplicity of Java is - like for most new languages - partly an illusion and partly a function of its incompleteness. As time passes, Java will grow significantly in size and complexity.

This was a comment made by Stroustrup a long time ago about Java. Now it reminds me of Golang

[Victor Collod]

the usecases aren't entirely comparable: golang has better support for backend stuff, but no support whatsoever for some of the things kotling does, like in the android works

[Stephan Schroeder]

@Victor Collod as a Kotlin backend dev i wonder, what do you consider better support for backend by Go? Its async runtime? (I have only done a toy project in Go many years back, so I don't know it very well, though I keep checking up on golangweekly.)
My feeling is that once Kotlin Native will be production ready, there isn't any scenario in which I would consider using Go over Kotlin (of course others still might 😅) .
• Well, I guess Go still has more native library support at that point, since most libs usable by Kotlin are for the jvm only (I assume).
• other aspect that just came to mind is Go's garbabe collector which has supershort pauses (and I haven't heard the same about Kotlin's GC), so Go got a better worst case latency AFAIK.

[Kirill Grouchnikov]

Without speculating about potential future for these two languages, I think you’d have a hard time getting useful pieces of information for such a vague question. People would roughly be divided into the following buckets:

1. More experienced in A than in B, so not really much to glean about A vs B
2. More experienced in B than in A, so not really much to glean either
3. Somehow magically equally - and deeply! - experienced in both A and B. 99% guarantee that people in this bucket are equally frustrated by both
There’s so much variety of languages and frameworks these days, that bucket 3 is going to be pretty small. And the other buckets are going to be heavily subjective and not really well informed to give you something useful or usable.

[Stephan Schroeder]

@Kirill Grouchnikov your cases 1. and 2. are equivalent 😂

[Vitaliy Zarubin]

I think if such a question arises, you need to take the one that you know best.

[Matti Viljamaa]

Yes, I've also been thinking that saying that the other is superior is a subjective bias. I cannot understand why they couldn't have pretty much the same features. Possibly even, Golang is a proprietary attempt to do what Kotlin does.

[Stephan Schroeder]

As far as I understand it, Go started of as a better C while Kotlin started out as a better Java (its native compilation target is still in beta).
Gos' approach is have a minimal (easy to keep in your head) language with superb tooling and a great async runtime. Kotlin is fixing Java's issues (wrong defaults, e.g. public visibility instead of package scoped, immutability instead of mutability, e.g. val instead final var, immutable Collection interfaces, classes are closed instead of open by default, ...) and adding useful features (nullability, sum types, extension functions, inline functions with reified type parameters, ...)

[Jacob]

Superb tooling? I think you're confusing it with rust. Does go have a decent package manager yet? Is it all still GitHub based?

[Jacob]

Ok looks like go tooling might have improved recently but this is clearly not a language that started with a focus on tooling

[Stephan Schroeder]

Go has a compiler that takes less than a second even on big projects (i hear). they have a formatter with a single format which ends all discussions what the correct format is. Go has a dependency manager (already a big plus compared to older language like C, C++ or Kotlin (of course you can use "external" package managers)), they have an inbuild fuzzer, a vulnaribility management tool (pretty new https://go.dev/blog/vuln) and probably other stuff that I don't know off because I don't actually use Go. Go wasn't build as a reaction to Rust, but a reaction to C/C++.
Look, I prefer Rust over Go every day in the week, but this discussion is about how Kotlin and Go differentiate.