What is wrong with this framework? WHY can I not c...
# multiplatform
j
What is wrong with this framework? WHY can I not create a FILE? ITS JUST A FILE
c
Are you trying to create a
java.io.File
? That class would only be available on JVM-based platforms.
☝️ 2
There’s a first-party kmp I/O library in the works: https://github.com/Kotlin/kotlinx-io
j
THIs should be in the base framework. THe fact that you cant expect types, or map types to a common type means that the framework should help with that, but this framework does NOTHING. In fact I am convinced its syntatic sugar for just building a common code library and writing seperate apps based on that. Why does this framework refuse to actually help out? it just always says "do it yourself" Like the whole point of frameworks and libraries is to not reinvent the wheel, I dont see why ever project has to have its own mkdir function
👎 10
👎🏾 1
j
Kotlin Multiplatform isn't a framework. It's a compiler that can target multiple platforms, enabling code sharing.
☝️ 3
☝🏾 1
The Kotlin standard library offers some common APIs, and kotlinx and third-party libraries add additional capabilities. There are several libraries currently that provide APIs for working with files. Besides kotlinx-io, there's Okio and KorIO.
j
WHY does the standard lib not have file support then? Either there is some gap in the chain, in which case KMP needs to step up, or there is a design problem in which case... KMP needs to ste up
m
The browser has no File concept and KMP needs to work there.
4
Use https://square.github.io/okio/file_system/ for filesystem access on jvm/native/nodejs
m
For the time being Okio is the way to go. It is the quasi standard lib at the moment and the upcoming kotlinx-io lib is modelled after Okio. So, Okio is your best bet at the moment.
j
Well how do these frameworks work on browser then? Also, you can open files in browsers, so they must have some level of access to the file system. In chrome for example <file//C|file//> is used
c
I don’t think Okio has any filesystem APIs that work in the browser – only if you’re running JS via Node can you use the NodeJsFileSystem
☝️ 1
Also, you can open files in browsers
Yes, but there are browser APIs to do this, usually that require some kind of user interaction. You can’t just make a reference to a file on the filesystem in JS and start reading/writing to it. Imagine if any website could just call
File("~/.ssh/id_rsa").readText()
to steal your private ssh key!
j
So I am seeing the "file system api" but also, these frameworks dont do a full implementation, and something like Compose is more than happy to have half working half broken things, so why is KMP not implementing things for everyone else just cuz one implementation would be not supported.
e
Because that's not in the scope of KMP. Like a bunch of people have pointed out, there's a kotlinx library in the works. Until it's ready there are community offerings. As an aside, please reconsider your tone. I understand that you're frustrated, but using CAPS and denigrating language won't get you anywhere.
❤️ 3
l
Another thing to note is that Compose Multiplatform is a UI library. It's not like Flutter or React Native, where you have one framework that expects you to use their tooling. In KMP, we have different libraries that each provide focused features. This fixes a major problem I often ran into when using Flutter, where there are so many packages the team maintains that each individual one tends to have lower quality. In the KMP world, you have Square working on okio/sqldelight, JB/Google working on Compose, JB working on ktor, community members creating state management libraries like #decompose, #touchlab-tools Stately, #ballast, etc. Each of these projects can be focused, and you can look for tradeoffs between them.
If you want a list of libraries you can pull in for common tasks, there's repos like https://github.com/terrakok/kmp-awesome
j
Oh no need to be oversensitive about a few caps. And you guys fail to see all the reinvention of the wheel that's going on though. The fact that you have to document which libraries you have to use for everything because it's so hard to keep track of them in itself is a problem. Here's one interesting idea. Why doesn't kotlin multiplatform have a method for bridging types together. You can do this in Java with proxy reflection so I'm sure it's possible. I could then just expect a value of some type but then substitute that type with another type at compile time. In common cold then I would just use the interface I'm expecting and save myself the hassle of implementing a wrapper class for every single Target
l
There's actually a library (#decouple) that does just that for Composable UIs. Having a wrapper library that can delegate to others can be useful in some cases. In others, such as logging, there's different libraries that provide different ways of using the library. I tend to prefer Kermit, but it's just as valid to use klogger or some other logging utility.
j
This is so frustrating, I do all this development but only after find out about theses libs. This seems to only happen when I do things in kotlin
a
I think technically File/IO API could be in the stdlib. It could throw on JS (like KClass#qualifiedName does), or just be unavailable if you are targeting JS (like runBlocking in coroutines). But still it makes sense to keep it in a separate (maybe first-party) library. You can't add everything into stdlib, and IO is definitely not a must-have in every application. E.g. there has been no need for IO in KMP in all my use cases (library development). There are also plenty of apps without any need in direct File IO, just network access (Ktor) and DB (SQLite/Realm/etc).
l
The size of the stdlib was one of the main blockers for K/N on embedded. There were few microcontrollers with enough flash for a simple 'Hello, World' due to the stdlib size. Coupled with challenges maintaining embedded targets, JB dropped support for embedded. It would be nice to see embedded K/N happen eventually, but it would need the stdlib to be more focused.
j
why not make opt in modules for stblib? like say stdlib-io, stdlib-serialization etc
l
That's what kotlinx is suppsed to be. It's a first-party set of libraries that many people will need, but not everyone. The kotlinx-io library isn't done yet, but these things take time and okio was already a good choice.
☝️ 2
j
Also who is using this for microcontrollers? If it compiles to native code, then the compiler is not optimizing out the unncessary concepts, if it does not do so, then its another circuitpython situation, which is bleh
Kotlinx io seems ok for my use, i dont need web or IOS
l
One thing that may be nice is a kotlinx() shortcut in the dependencies declaration that brings in kotlinx-{io,serialization,json,etc} if you don't care about size or choosing another library. It would simplify usage for projects that don't need the same level of customization.
j
Im still wondering how microcontrollers work with kotlin
l
They don't right now. TinyGo uses LLVM and has a GC, so it would be doable. Some projects require microcontrollers, but since Kotlin doesn't support them, I often go with C. It would be nice to use the same language on the full stack.
1
💯 1
j
I usually use C++ / C on microcontrollers but python is also an option. However someone had the audacity to tell me circuitpython was fast, I proved they were wrong so hard and now I hate that language. Kotlin native can compile down to native code right? Perhaps something like that would be feasible, i guess the circuit python type route is an option but its so slowwwwww
a
From my point of view, the main issue with Kotlin on microcontrollers is because they are often running without any OS (or with an RTOS) and with static memory allocation. But this is just my hunch.
j
Yes circuitpython fixed that by basically making a bootloader that supports python. If you compile to C code though then you can just get a flashable image and upload that to the microcontroller
a
But there are thousands of MCUs. Each with different set of CPU instructions, registers, etc.
j
Yeah and you gotta make an image for each one you want to support, or have a compilation library for each one. HAHAHAHAHA its fun
l
K/N has a custom allocator now, so memory allocation isn't an issue anymore. I think JB is just needing to focus on mobile/desktop/web right Now. LLVM supports many uC's right now, but there's a lot of infrastructure Kotlin would need. Right now, the runtime isn't flexible enough and the targets aren't as customizable as they'd need to be. C, Rust, and TinyGo can do it, so it's possible, but KMP is still a pretty new technology and there are more important priorities.
👍 1
j
I agree, it cant even do files right, microcontrollers are a future problem for sure