Kotlin/Native as Go alternative?

[scellow]

this is why jvm is dead, this community DOESN’T CARE about performance AT ALL, this is sad, really sad, on same level as javascript developpers

[darksnake]

I guess, then it should be quite easy to write your own compiler. There are a low of pretty fast parsers out there.

[ahmadalsharif.dev]

Dude, plz don’t start bashing around. I love Kotlin for it’s simplicity and when it comes to performance, it does a pretty impressive job. Go isn’t directly comparable to Kotlin, they’re two different things serving two different purposes.

Btw, I’m OP, just different account cuz I couln’t log out for some reason.

[SOF3]

@scellow

for some applications, you want to be able to deploy and run as QUICK as possible, so JVM is not a solution

Almost every language requires some framework dependencies. You either ship an enormous binary or requires some dependencies. If you really hate dependencies, have you tried docker?

@scellow

again, often you’d prefer your server to cost as low as possible

C++ is almost (one of) the only language(s) with no garbage collection built-in. You could always remove unset all (circular) references to objects to facilitate faster garbage collection; then the only difference in performance is heap allocation, but it is small (and at least not more impractical than C memory management). You should be writing Assembly if you are so concerned about small costs.
Meanwhile we are talking about Go, and Go isn’t that perfect either…

@scellow

on JVM kotlin compiles slower than java, it’s sensible, kotlin native on other hand compile time is a nightmare, TDD becomes really annoying, it hurts productivity

i believe in kotlin native, but as of today no it’s not an alternative to GO

Indeed, most parts of Kotlin/Native are still pretty experimental or new. But I don’t see a theoretical cause that makes Kotlin/Native inevitably slow to compile; more like JetBrains hasn’t optimized it well enough yet.

@scellow

this is why jvm is dead, this community DOESN’T CARE about performance AT ALL, this is sad, really sad, on same level as javascript developpers

This is overexaggeration. When we talk about a language, we are talking about what the language has potential to do (or if there is some theoretical constraint impossible to optimize, e.g. you can’t optimize a type-unstrict language too well), not about how the current compiler software performs. If nobody cared about performance, there wouldn’t have been Hotspot and JIT compilation. The point is that Java and/or Kotlin are not designed to be “you don’t pay for what you don’t use” languages with all sorts of tiny optimizations, but this does not render them impossible for most cases. You aren’t writing a Kotlin program to mine crypto currency; if you do, you should be writing in Verilog instead.

[cretz]

I just found this thread. I didn’t read the rest of it, but a few months back I started thinking “You know, Kotlin seems to have a superset of features w/ unsigned wrappers now and channels and what not, what if I made a Go-to-Kotlin transpiler? I’d sure like to use all those Go libs out there.”

And, so, I started on GitHub - cretz/go2k. It compiles Go to Kotlin, but it’s not done (I’ve moved on for a bit). It relies on some of my other projects such as go-dump to dump AST and types from Go to protobuf, pb-and-k to read the protobuf, kastree to build a Kotlin AST and write the result, etc.

It can compile and run all of the Go you see in the folder at go2k/compiler/src/test/go at master · cretz/go2k · GitHub. The compiler got a little ugly so I’m taking a step back and when I revisit I will have a lot to clean up. There are some novel solutions to some problems in there worth reading the code for. While I am using the JVM as the initial runtime, I knew I’d want it for Kotlin Native so I make sure to abstract that out (e.g. go2k/runtime/runtime-jvm/src/main/kotlin/go2k/runtime at master · cretz/go2k · GitHub is all that’s needed so far). There is a ton of work to do for this to even be viable, but figured I’d toss it out there.