so the reason is just complexity ?
# random
s
so the reason is just complexity ?
b
What compiler should do with
MyInlineClass(1, 2)
? What kind of value unwrapping are u expecting from that? šŸ¤”
k
It's a serious question, how could this be compiled while still not boxing anything in an actual instance?
s
i don't know, it could unwrap each field, i know nothing about compilers
r
@sksk You can only return a single value, so you can't unwrap each field and "return them all".
k
And that an actual JVM limitation, so there's really no way around it. They could get this to work on Kotlin/Native maybe.
r
@karelpeeters Sure, but that would create fundamental differences in the language on each platform, so I highly doubt they will.
b
@sksk are you saying something like this?
Copy code
var (x, y) = MyInlineClass(1, 2)
k
Yeah I agree that that would be a bad idea, it was just an elaboration on the fact that it's a JVM problem.
s
@bloder i'd prefer more like
Copy code
inline class Something(val a: Int, val b: Int)
but i guess i'm just asking for value types šŸ˜›
yeah.. i hate slack
k
Single ` for short online code, triple ``` for multiline.
s
and @ people is weird, everyone got a different name..
@Ruckus they already do that for concurency, i guess the best solution is to do the right thing for the platform
g
Why do you need incline class for this?
the best solution is to do the right thing for the platform
Yes, and the right thing is wait for proper value types support on the most popular part of the platform: JVM
s
for vector math, mostly gamedev
and if i don't care about JVM how am i supposed to do it with kotlin native ? forced to wait forever ?
JB should do like concurency and implement something for native, similar to Swift, since that's what KN was designed for
g
I dont’ think that boxing to class is the biggest performance problem of K/N
forced to wait forever
Not forever, but until JVM will get value types at least
s
it is, and this is why you see game engines made in C# and not in Java/JVM
g
I said ā€œKotlin Nativeā€, not JVM
also there are game engines on JVM
s
but KN features map to JVM you said it
yeah, and they are horible, or just for 2d stuff, look at the nasty stuff libgdx has to do with their vector/matrix class
g
and if by saying ā€œgame enginesā€ meaning Unity, it’s not written on C#, runtime is C++
C# is only client
s
Xenko is a recent one
g
C# is not faster than Java, boxing may be a problem for surem, but it also solvable
s
exactly, and the solution to fix that atm is not nice or pleasant
g
yes, it’s true
bug again, it’s all about ā€œenough performanceā€ not ā€œas much as possibleā€
s
i disagree with this, you need as much performance as possible, it is more true when targeting low end devices like android phones, or even phones in general to save battery life, this is why games sucks on android compared to iOS, and this is why android needs twice as much memory than iOS PLUS it have direct impact on software design
g
you need as much performance as possible
Sure, but there are tradeoffs. If you would worry only about performance (especially for games, for example backend is different story) and don’t care about anything else you would probably use ASM/C/C++
this is why games sucks on android compared to iOS
Not sure what you mean. But most of games are native and written using C/C++ cores and should have mostly the same memory consumption. And only native games allows to compare game performance directly, but in this case you usually compare GPU, CPU, driver performance Sure, managed runtimes consume more memory than native in general (and it’s also true for C#), tradeoffs are everywhere, but if you really compare iOS and Android it’s not true. Modern iPhones has the same amount of memory as Android (for example Pixel 3 has 4Gb and iPhone XS has 4Gb) and I don’t think that memory consumption on Android is 2 times more, but if you have another data would be interesting to see Also it’s very strange to compare low end Android decvices with non-existing iOS low end devices I’m not really into game dev, but usual application on Android don’t have any problems with memory allocation or GC, of course better to avoid it in really hot parts of the code, but it’s true for any other technologies, you should just optimize bottlenecks if you try to save allocation of a few dozen of objects you definitely do something wrong #enumsmatter
and returning back to inline/value class/type only for K/N. You anyway cannot do this for JVM now, but even if it would be decided to implement for K/N now, it would require a lot of work (and quite different semantics compare to JVM/JS) and with current state of K/N there is a bunch of other things to optimise (now K/N is just by itself is significantly slower than JVM, except startup time)