https://kotlinlang.org
Join Slack
Hello, what would be the reasons for you to pick Go over Kotlin for a backend project, and vice-vers...
# server
l
Hello, what would be the reasons for you to pick Go over Kotlin for a backend project, and vice-versa? Asking for friends 🙂
o
All other things being equal (in particular team proficiency with a specific language), I’d exclude Go from the list for its lack of expressiveness (no classes) and robust exception handling (no try/catch), which according to my experience would impair maintainability and stability.
💯 4
➕ 2
k
Go is fast and small is the main consideration for that language. And it's used for a lot of Kubernetes stuff if they're doing that too. Build and test runtimes are crazy fast... It has no classes but you can get decently far with their confirmable interface objects...
r
I've never used Go. What would make me consider it ahead of Kotlin & Rust is operability - when operating our Kotlin JVM backend & CLI I often get Go envy and wish I was kicking out a single statically linked binary that Just Worked (TM). That and (I'd expect) easier integration with standard *nix stuff like signals, because you wouldn't have the JVM's desire to hide it away from you to be compatible with Windows. That all applies to Rust as well, but it looks to me like there's a bigger learning leap to make to use Rust well with the borrowing and no G/C. I am aware of Kotlin native, never used it, but the cynic in me is very wary of going off-piste from a technologies heartland - in Kotlin's case, Android & being a Better Java on the JVM. Go has always compiled to a single statically linked binary, so I am confident in the behaviour of the G/C & stdlib & threading being the default that everyone expects, and is mentioned in StackOverflow answers and blogs, rather than getting an "actually there's a subtle difference from..." type reply from experts, or finding a stdlib method doesn't exist for that platform.
k
Go's package manager and default home handling is horrid...or at least was a few years ago ..
If you've never used Go, not sure you'd appreciate the good and bad parts as much ...
r
I always come back to Kotlin though because the language is so nice. Just a pleasure to think in. The compiler helps me express my thoughts, and avoid so many errors, whilst rarely presenting me with type errors I do not understand and cannot fix (unlike Scala & TypeScript). When I briefly played with Go it seemed to lack a lot of the enforced discipline that Kotlin gives me. I suspect I'd be happier with Rust if I could master the borrow checking.
I suspect we will one day revisit our use of Kotlin-JVM for our CLI - it's just so big to download and slow to start. GraalVM may save us. But I can't see us moving off Kotlin JVM for the backend service where those are much less of an issue.
Anyway, all the "I've never actually used..." renders my comments largely useless, perhaps I should delete them... it's partly just that it's a question that's on my mind as well!
d
@Rob Elliot We've had good luck with GraalVM binaries for CLI apps. They are definitely much bigger than Go binaries, but I'll take that trade to keep kotlin. Of course, it does rely on you using tasteful technologies that easily work with GraalVM (ie no reflection etc) 😉 I won't give an opinion on backend choice because my opinion is hopelessly biased! 😂
👍 4
s
It's been a while but from what I remember I found it very strange that in Go unused imports are a compile-time error but potentiall nil references are not even a warning.
➕ 3
e
IMO Go is for infrastructure and systems programming—building interpreters, compilers, developer tools, command-line applications, small things with super fast start up. Go shines for relatively super fast project build and fast unit tests execution. In a small project I saw the whole test suite run for 0.01 or 0.1 of the second! The whole ecosystem is "compiled to native friendly" in contrast with JVM. But the syntax is so damn awful ... Gophers do not use declarative things like partition, map, reduce, etc. much even though libs for this exist. Also limited generic usage made me shocked. Like the syntax is from 1990 or so. Absence of culture of using implicit dependency injection
➕ 4
k
I think they added generics finally but agree..syntax took a while to understand 😔
e
They added generics, but in some constructs it is simply impossible to use because the compiler does not support it
And this limitation prevents one from implementing Kotlin-like functions from stdlib. Maybe it is actually done by design and has strategic benefits I am not aware of
o
So I was curious and wanted to step out of my bubble and expand my horizon. I tried to find out more about Go's design philosophy and the main use cases it would excel at. I already knew about its useful async runtime because that was considered in the design of Kotlin's coroutines. Beyond that, unfortunately, what I found was even worse than what I expected, best summarized in this article. It seems that Go is not just lacking the type of expressiveness which our human brains are wired for (they love generalization/specialization relationships and can understand structures making proper use of that much faster). Its structuring capabilities are pretty limited, making them easy to learn but leading to lots of boilerplate with a bad signal/noise ratio in user code. Worse than that, Go is unsafe to use at scale unless everyone using it is very proficient and extremely disciplined. Seems like its creators engineered not just one but multiple variants of the billion dollar mistake into one language. (Details explained in the article.) The article's final conclusion is well substantiated: > Because there is a lot to like in Go at first, because it’s so easy to pick up, but so hard to move away from, and because the cost of choosing it in the first place reveals itself slowly over time, and compounds, only becoming unbearable when it’s much too late, this is not a discussion we can afford to ignore as an industry.
👍 1
d
I'm old enough and grumpy enough to judge languages, tools and frameworks by the amount of effort that they put into testing. I know that Go has Quii's excellent book, but I'm not sure how far this attitude percolates into the Go community at large. I've always found the JVMs excellent plethora of tools and libraries quite reassuring (more so than most actual production libraries in fact... )
m
Hello there all I am still getting used to Kotlin and many other things especially with my iPad, GitHub, slack, many integrations and more using Ubuntu, Debian, cloudflare tunnels etc
39 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by