https://kotlinlang.org logo
Join Slack
Powered by
BTW do you know how serious Google's push of Kotli...
# getting-started
m
BTW do you know how serious Google's push of Kotlin to Android is? To me it seemed like Java is being deprecated totally, but is it this way or dual APIs?
šŸ¤” 1
j
It is the principal language and everything that exists on Java will be usable on Kotlin, but not viceversa (Compose for example)
l
Google used to build their libraries in pure java, with a ktx module that had extensions, but with Compose being full Kotlin, and with the prototype of Jetpack Multiplatform, I donā€™t see that continuing forever.
Iā€™d imagine if Oracle continues their lawsuit against Google, theyā€™ll likely try to push more people to Kotlin. They have a much better relationship with JetBrains.
m
I actually thought at some point that Kotlin is not really about improving Java, but about discarding Java.
ā˜ļø 3
šŸ¤” 1
šŸ™ 1
ā˜šŸ» 1
But they sell it as an improvement to get people hop on the ship.
l
Iā€™d say Kotlin/JS and Kotlin/Native support that idea. In theory, if in the far future Google improved their NDK, if they wanted to get entirely off the JVM and free from Oracle, they could switch android from K/JVM to K/N pretty easily (after porting functionality to pure NDK).
āž– 1
j
pretty easily is pretty optimistic, not sure how many years we will have to wait until see all the common libraries in KMP, the whole framework...
āž• 1
l
When I say pretty easily, Iā€™m assuming they decide to port more functionality to the NDK over a decently long time period. That would be a difficult task, but if they did it, they could switch the AGP to use K/N. If they went through the work of publishing K/N compatible versions of their libraries, they could make it a switch to flip to K/N.
m
But maybe the end users need not to care much about this anyways
I'm probably overreacting by thinking that Kotlin seems bad because of the messy repo
But that should be Google's issue as well.
l
Can you elaborate on messy repo? The project structure should be the same as a Java app.
m
Well I've been just discussing this at #compiler, where one guy said it took him 3 years to get on a rudimentary compiler dev level.
l
I think thatā€™s one of the things K2 is supposed to address. Right now, the 3 main compilers are separate, but K2 is supposed to unify the frontends, so each compiler just needs to define the backend. I also noticed that when I last looked in 1.6.10, they were in the middle of making the stdlib a single multiplatform project within the Kotlin repo, which made it confusing what was old/new, not to even mention the new K/N GCs. Right now, thereā€™s a lot of changes going on internally that contribute to the messiness of the Kotlin repo. I hope it gets cleaner when the changes are over.
j
@Matti Viljamaa Kotlin was released more than 10 years ago, any product with that amount of years would have a messy repo
m
No I don't think so, because they taught at uni that things should be kept tidy
šŸ§Œ 2
šŸ¤£ 2
e
lol. lmao.
āž• 4
l
As someone still in college, the stuff they teach is often theoretical at best. Itā€™s good when you can keep your code tidy, but itā€™s not realistic to assume you can always keep the project as tidy as a uni project.
j
Good luck when you start to work. You will need it and tons of faith
šŸ’Æ 1
m
maybe what we're seeing is that the design was clear at the beginning, but later expansions led to it becoming messy
and now they cannot fix it since everything already depends on other bits
l
Exactly. Thatā€™s what happens in the real world.
e
also that's not very true of the Kotlin repo - the dependencies are pretty cleanly delimited
l
Things like the K2 are meant to fix some of this messiness, but you can only refactor so much without having to worry about breaking things. Imagine if they released Kotlin 1.9.0 with completely overhauled internals and it had major flaws that they missed.
k
It would be beneficial to adjust the ā€œcollege levelā€ expectations into the real world. These are software products that have hundreds, and sometimes thousands of developers, contributing to them. Donā€™t expect everything to be tidy, documented or ā€œeasyā€ to get into.
m
I don't know. I've viewed those as desirable things. I mean look at why Python is popular. Or lately low-code / no code.
I mean look at why Python is popular.
k
I donā€™t think youā€™d get much from getting into these high-level, highly subjective discussions. I would say one thing - compilers are in the category of some of the more complex pieces of software machinery. Maybe some projects have better documentation in that area. Maybe some donā€™t.
āž• 1
m
Well GCC is pretty documented.
k
And thatā€™s fine. But also that doesnā€™t mean anything for any other similar project. If you find it unreasonably hard to get into how the Kotlin compiler codebase is structured, you can work with them on, perhaps, starting to get it documented. They are working on a new compiler, and maybe the next one after that, so the documentation will always need to be kept up to date. Some projects may see that as a very high priority, and some (smaller? leaner?) teams may want to focus on shipping things and not the overhead of detailed documentation.
m
Yes I might, it's a great language.
There's also overhead of having to help newbies, because they cannot teach themselves.
And whether Kotlin is more advanced than Java has become a bit questionable: https://jenkov.com/tutorials/java-concurrency/java-virtual-threads.html
I thought the coroutines were one of the hot things in Kotlin
k
You throw in a lot of stuff, and itā€™s becoming less and less focused as the result. Specifically for the compiler, itā€™s one of the areas that does not see a lot of ā€œdeepā€, if you will, interest from people who are new to the language. Iā€™m not going to make up numbers, but really how many people see the compiler as anything but a black box that gets human readable code and spits out a bunch of zeroes and ones. So then, if the question is where can this small team spend their time to best serve the overall community, the answer is - work on the thing itself, and not its documentation. For this particular thing that is the compiler.
m
yes it's just a thing that draws people away and not just me

https://www.techrepublic.com/wp-content/uploads/2017/06/screen-shot-2017-06-08-at-8-25-19-am.pngā–¾

šŸ™„ 1
Kotlin has Google's support, so that makes it more robust, but e.g. in the case of nim-lang it's a total deal-breaker, because it makes the project seem like some script kiddie work
l
At the same time, documentation is usually low on the priority of open source projects (unfortunately). Iā€™m sure if someone wrote up some clear documentation and created a PR, the devs would appreciate it.
k
The flip side of it is that the dev team now owns the documentation updates going forward, so itā€™s not always clear that a drop-and-disappear blob of documentation is a positive thing in the long term
l
Thatā€™s fair. Iā€™ve seen plenty of examples of old docs that are now incorrect in projects before.
m
good code can be self-documenting, but I'm not sure if it's the case here
Commonly stated objectives for self-documenting systems include: ā€¢ Make source code easier to read and understand[2] ā€¢ Minimize the effort required to maintain or extend legacy systems[2] ā€¢ Reduce the need for users and developers of a system to consult secondary documentation sources such as code comments or software manuals[2] ā€¢ Facilitate automation through self-contained knowledge representation
k
Implied in this is that one needs to have a certain non-trivial amount of knowledge and experience to be able to navigate an unfamiliar, large codebase
m
Possibly, but I didn't think compiler codes should differ that much in design
This is the first time I see the word "common" in that context for example
or "Candidate"
k
Perhaps the expectations need to be adjusted then
l
Languages will tend to differ because they often have different goals. Some are very dynamic, some are statically typed. Some use GC, some require manual memory management, some (like Rust) have very elaborate branch tracking for memory management. A language meant for JVM isnā€™t going to be structured exactly like one meant for native (look at K/JVM vs K/N).
K/N needs a whole runtime that would typically be supplied by the JVM or JS interpreter, which has to live somewhere.
m
BTW I was envisioning that Kotlin would do a non-GC version
that's syntactically close, but compiles to C
like Nim does
e
if you have a way to do that and remain compatible to the existing body of Kotlin code, I'm sure they'd be happy to hear
ā˜ļø 1
m
Yes, I'll look at it some day. Just that I've been coining this idea for at least a year, and some people said such system cannot be designed.
e
while some disparity between platforms can't be helped, a separate "language" that looks like Kotlin but behaves differently is not in our best interests
m
I think it can be, but it needs some thought.
šŸš« 2
k
The only way to prove naysayers wrong is to show them that it can be done
Otherwise it's just talk
Ideas are dime a dozen in this industry
m
The other thing has been lack of good targets
because it's quite evident that "can be done" is not true for JVM
l
Keep in mind that you can create a ā€˜non-GCā€™ program in K/N using the posix malloc/free and defining structs in a def file, but aside from a few situations, not sure why thatā€™d be helpful.
m
But since Java did not mean to be a native language, the whole nativeness seems unexplored prior to K/N
e
I think you are missing a lot of prior art. Scala Native and Scala.js existed well before Kotlin
m
just but OTOH that's even a more niche language
as I said, I haven't found suitable targets
because most languages never become popular
I don't know. My main benchmarks were just Java, which only had JNI for non-GC, which is not with a translatable syntax. And C++, which does not implement a "full" GC.
But in the context of the thread, I've been really wanting to use Kotlin for desktop
e
?? the JVM has plenty of ways to make use of off-heap memory which does not get managed by GC; the puzzle comes in how to make that work with other existing code
šŸ’Æ 1
l
Kotlin can be used for Desktop either using JVM or Native targets.
m
I just thought the Epsilon was best they can do, and it has very limited use
I mean, it's their official take on no-GC, so it seems like no-GC Java is impossible
possibly due to legacy reasons
e
at this point, for building desktop applications, Kotlin/JVM is much more mature than Kotlin/Native, although perhaps we will see parity when Compose Multiplatform gets around to native
l
You can also use K/N to compile a native library, then load it in a JVM app.
e
you can write Java code that only interacts with statically-allocated NIO2 buffers. there will be no GC involved.
m
But I mean, I think there's a certain market segment in a "native Java"
(which is not C++)
e
the problem is that you don't get any benefits of any other part of the Java ecosystem
m
that's not necessarily the point, but the point is like React's
l
GraalVM has a way to compile ā€˜native Javaā€™ (no reflection support yet)
e
for desktop usage, jlink or graalvm native-image are definitely solutions that work now, as opposed to compose/native which is sometime off in the future
m
how is jilink no-GC?
e
neither is no-gc
if you want to run the existing body of code, you need GC
l
Iā€™m confused what youā€™re looking for. Are you looking for Java-like or no-GC? Unless youā€™re using Rust, you have to have either manual memory management like C and older C++ or a GC.
m
I wanted a language that can be compiled to a syntactically similar manually managed version
by having a transpiler that knows how to remove or add the GC
l
Sounds like you should look at Rust. Itā€™s the closest to what you want that exists today.
m
I mean, Haxe -> CPP does build a GC in the CPP
so just looking for the other direction
e
not that I recommend it, but D has optional GC. even if it's "optional" though, the majority of existing D code only works with GC enabled
m
and now you understand why it's a modern feature
l
Why are you trying to avoid GC?
m
Because people who use C++ will never use a GCed language
šŸ˜‚ 1
l
Iā€™d say that it would be better to get performance data and show whether a GC impacts your use case.
e
from my point of view, there is no point in optional GC as a language feature. it only fractures your libraries
āž• 1
there are places where C++ is used that Kotlin does not supplant, that is completely fine
Kotlin is meant to be a productive language for the types of applications that we build
m
I believe the translation from GCed to non-GCed language of same type is less complex than translating to a different language
e
you are free to believe what you want but there a lack of evidence for that viewpoint
m
If one can add GC to non-GCed language, then I think one's nearly done
e
of course you can add GC to a non-GCed language; C++/CLI and Objective-C/ARC did
āž• 1
but executing code that was written with the expectation of GC and running it withoutā€¦ you will need to prove that possible
l
Rust shows that itā€™s technically possible, but the compiler has to do a lot of inference to figure out where to place the frees. It even influences the syntax of the language.
e
Rust doesn't remove GC from code that expects GC, it forces code to be written in a way that is compatible with its memory management
l
Yeah. It makes it much easier to work with than C, but like you said, it requires you to change how you write your code. Placing the frees is a very difficult challenge, and you have to give the compiler some help.
e
working with linked structures in Rust is notoriously awkward, and even GCC uses garbage collection itself (despite being written in C) to make working with its internal tree structures easier https://gcc.gnu.org/onlinedocs/gccint/Invoking-the-garbage-collector.html
m
I basically just assume that if the human programmer knows how to place the objects (or even just constructors and possibly destructors), then an AI also does
And no I don't think ideas are dime a dozen, because if good ideas were prevalent, then whole programming ecosystems (like JS, Java) weren't as unideal as they are so that one needs to develop a new language that fixes the earlier ones, even when the computer architecture hasn't changed. Just because people jumped in without knowing right ways to do things. And then they come cry: https://en.wikipedia.org/wiki/Criticism_of_Java
e
JS and Java are the way they are because of engineering trade-offs, not for a lack of ideas. It is widely known that Brendan Eich designed JS in 10 days in order to make it into Netscape 2.0 Beta. Java has been both succeeding because of and suffering from maintaining compatibility with existing sources and binaries since 1.0.
g
And then they come cry
One can write this about absolutely any language, also many of those ā€œcriticismsā€ could be applied to many another languages (especially true about Parallelism section) Java is just one of the most popular ones I do not know, should I cry or envy to your extremely idealistic views, sorry have to say this šŸ˜…
BTW do you know how serious Googleā€™s push of Kotlin to Android is?
There are so many great topic to flame about, but too many to really do this just want to answer about:
BTW do you know how serious Googleā€™s push of Kotlin to Android is?
Google said that itā€™s the main language for Android, so itā€™s serious as Android is. Also I do not believe on migration of Android from Java APIs even as a second runtime, at least not for next 10 years, using completely new ecosystem is a huge shift, almost none of tools will work, for example it was one of the reason why Google dropped Jack&Jill compiler for Android, so on baseline itā€™s a huge disadvantage and advantage of new ecosystem should be truly huge
k
Ideas are dime a dozen in our field. Execution is king, even if there's an ugly codebase behind that execution. It just takes time to see this.
Good ideas don't magically "win", if there's even such a thing. They still need to be executed. And then they need to compete not just on some sort of greenfield "objective" merits, but also compete against existing, established, widely used ones. And a lot of times, those "good" ideas simply don't find their audience and wither in solitude.
If you have a big idea about bridging the popularity and developer mindshare of Java on one hand, and realtime, predictable execution speed of C on the other hand, the next thing to do is roll up your sleeves and make it a reality. There's no certainty that you'll succeed. There's no certainty that it will become popular even if you do. There's no certainty how much time it will take, and how our field will have changed by then.
m
"JS and Java are the way they are because of engineering trade-offs, not for a lack of ideas.". Then consider two statements: -all robust languages are statically typed languages, not dynamically typed. -an object-oriented model is just one out of many. -security vulnerabilities may be prevented my testing them out prior to throwing the thing into the wild, or by being able to prove the type system.
g
security vulnerabilities may be prevented my testing them out prior to throwing the thing into the wild
Just test for security vulnerabilities, why nobody thought about this before
m
maybe because it's inherently difficult to test in some languages https://www.cs.cornell.edu/fbs/publications/LangBasedCase.pdf
g
maybe because itā€™s difficult in all languages, also languages run on runtime, runtimes on OS, OS on hardware, and every abstraction layer has own boundaries and potential security risks. And yeah, very small thing on top of it: human error
robust languages are statically typed languages
What is your scientific definition of robust language? Maybe also have a couple links on white papers about robustness metric for languages
m
a robust language: -can be extended, so that after one wants to modify the language design, it's possible to do so without things becoming really messy (backwards compatibility often causes issues). -can be transpiled, i.e. the programs execute in a way that's inferable (C++'s multiple inheritance?). -can be read by other people using the same language (not like C++'s multiparadigm phenomenon).
g
those are extremely arbitrary characteristics of the language IMO
for example for my work, none of them relevant (readability in general of course important)
e
the original goal of JS was to create a simple language that any person learning HTML could pick up, without engineering background, while also being possible to extend in the future because something designed in 10 days was not going to be perfect. of course in hindsight we can say what actually became of it, but that was the origin.
g
though, none of them goes against usage of dynamically typed language per se, so according to your own difinition dynamically typed language can be ā€œrobustā€
m
a dynamic language is robust, when its used in the context it's useful in, which is not security-concerned enterprise software
which is not security-concerned enterprise software
e
Java was originally designed for small memory-limited set-top boxes (bytecode being more memory efficient than native code; same reason Android went with Dalvik, and they had some novel ideas about making it possible to perform static safety checks on bytecode). of course its base design is not going to be the same as something you'd design from scratch for the role it now fills. that's life.
m
"bytecode being more memory efficient than native code" wat?

https://miro.medium.com/max/1400/1*cXYRnD_mA9Px3aNdWcqqcA.pngā–¾

or "By default, the HotSpot JVM will use up to 240MB."
e
that's with JIT. without tracing, bytecode takes far less memory
m
"of course its base design is not going to be the same as something you'd design from scratch for the role it now fills. that's life.". Yes, but this is again a central issue. It doesn't fulfill using the right tool for the right task.
c
@Landry Norris the Oracle v. Google case has been settled in the Supreme Court last year, I encourage everyone to read the results. I won't try to explain the results (not a lawyer, lol) but it ended in a technicality, so it's not really important anymore
l
Good to know it finally made it all the way up. If I remember correctly, the results kept changing, making it hard to tell what the end result would be.
c
The Big Thingā„¢ about coroutines is structured concurrency, not cheap threads. Also, being multiplatform.
Not having a GC actually makes everything extremely complicated. How many non-GC languages are memory-safe? There's Rust, that's about it. Rust is very interesting because it follows a very similar design philosophy as Kotlin (the asynchronous system is essentially the same, the syntax has the same goals...), but they're also completely different because of that need to be memory-safe.
e
in terms of how it works under the hood, Rust's async is significantly different and has some notable limitations due to the necessity of tracking ownership. the ideas of structured concurrency are definitely the future though (pun intended šŸ˜ƒ)
šŸ˜„ 1
(also kotlinx.coroutines is the one standard in Kotlin while Rust's async ecosystem is fractured between the different runtimesā€¦ that should get better in the future though)
m
I'm having trouble with how Android's push of Kotlin should influence desktop dev though
I've perceived that one richness of Java was because of broad libraries. Is it then still the case or does Kotlin make Android a special ecosystem, at least for a while?
c
You can use any Java library from Kotlin/JVM. Kotlin also has first party JS and native support that Java could never get.
m
Yes, but in the context where we speculate that the idea is not to augment Java, but to replace it. But maybe it's just speculation.
Google might be totally okay with having a custom language just like Objective-C is for iOS
g
What doesn't it even mean "augment java"? The idea of Kotlin was to have a modern language fully interoperable with java in 2 directions, so allow it to work with all existing JVM ecosystem, it's not to alter Java, Kotlin not the first language which targets JVM, but the most Can Kotlin replace Java in many cases? Of course, will it replace Java completely, no, java is very big. Can Kotlin replace Java on Android? Yes, on application level it's happening and with Compose it's now a question of time, though it doesn't mean that java will disappear, AOSP mostly java, same as all public API are written in Java and Java compatibility, so Java and Kotlin continue to be languages of Android, though more and more Kotlin centeic Also ObjC is not the same as Kotlin, Kotlin is application level, which is compatible with Java, but Android is still Java, unlike ObjC which is the main language of iOS (and now start moving to Swift based Foundation framework)
e
Google has significant work in both Java and Kotlin, not just for Android. There is no way to replace the existing JVM ecosystem.

https://youtu.be/o14wGByBRAQā–¾

12 Views
Open in Slack
PreviousNext
Powered by