7 ms·

This is definitely surprising given they announced a KMP standalone IDE only a few months ago. For now, Flutter still seems to make more sense than KMP while th

This is definitely surprising given they announced a KMP standalone IDE only a few months ago. For now, Flutter still seems to make more sense than KMP while the KMP world is still maturing.

robertlagrant 2y ago
I always thought a really good use of KMP would be in writing shared non-visual code, e.g. a library that interacts with your API(s) and any non-visual like that. Then paint a dumbish, platform-specific frontend over the top and link together.
- seanalltogether 2y ago
  As someone who has to manage native ios and android apps I thought this would be the perfect solution as well. I wanted to write all my data models, api calls, sql cache and business logic as a separate library written with kmp, but what i didn't like was that the ios framework that was generated was a black box with just objc headers. If it generated full swift code that i could inspect for correctness and tweak if needed, I would have jumped on using it right away.
  - robertlagrant 2y ago
    That's interesting - I can sort of see it both ways. Would applying unit tests to the exposed functions not have sufficed?
    - andrekandre 2y ago
      not the op, but had similar experience kmp exposes everything as obj-c meaning c headers and not very good type annotations (enums are int only so you cant have full checking on each switch, everything is obj-c reference semantics meaning multi-threading gets tricky, kotlin exceptions are not catchable from swift) so there are a lot of edge cases to write unit tests for (on the client side) which negates a lot point of using kmp, and thats in addition to all of the kotlin-isms that leak out...
      - robertlagrant 2y ago
        Ah, right. Yeah, that is surprisingly bad! Why wouldn't they at least generate enums!
        andrekandre 2y ago
        > Why wouldn't they at least generate enums! they do but its going through objective-c which inherits c enums (which are basically integers) so when you use it from swift its like switching over an unbounded set so you always have to handle "default" cases leading to bugs compared to usage from android
vips7L 2y ago
Dart is an amazing and underrated language too. It compiles to native assembly, has pattern matching, async/await, and null safety. The only thing it's missing in my opinion is some form of checked errors, currently they only have unchecked exceptions.
- geodel 2y ago
  > The only thing it's missing I think biggest thing it is missing is any kind of Google commitment on its long term usage.
- tadfisher 2y ago
  The modern language landscape is backing away from checked exceptions. Funnily enough Kotlin eschewed them as well, converting checked to unchecked exceptions on the JVM.
  - vips7L 2y ago
    The modern language landscape has not backed away from checked errors. Rust is praised for its checked errors, countless posts on this forum praise Result<T> in multiple languages. Swift has checked errors and Kotlin is implementing them via union types in the near future. Checked errors, via results or exceptions have never been the problem. It has always been Java the language that hasn't provided the syntax sugar for handling checked errors effectively. There is no difference between: A doIt() throws B fun doIt(): Result<A, B> It all comes down to what the language lets you do once you encounter that error.
    - billllll 2y ago
      Is Rust praised for its checked errors? I've personally found it extremely verbose since there essentially is no possibility for unchecked errors. Also, external crates like "anyhow" are required if you don't want to account for literally every single possible error case. Really seems like a pedantic's dream but a burden to everyone else. Effective Java recommends checked exceptions only in the case where the caller may recover, but in practice you're usually just propagating the error to the caller in some form, so almost everything just becomes unchecked runtime exceptions.

This is definitely surprising given they announced a KMP standalone IDE only a few months ago. For now, Flutter still seems to make more sense than KMP while the KMP world is still maturing.

robertlagrant 2y ago

I always thought a really good use of KMP would be in writing shared non-visual code, e.g. a library that interacts with your API(s) and any non-visual like that. Then paint a dumbish, platform-specific frontend over the top and link together.

seanalltogether 2y ago
As someone who has to manage native ios and android apps I thought this would be the perfect solution as well. I wanted to write all my data models, api calls, sql cache and business logic as a separate library written with kmp, but what i didn't like was that the ios framework that was generated was a black box with just objc headers. If it generated full swift code that i could inspect for correctness and tweak if needed, I would have jumped on using it right away.
- robertlagrant 2y ago
  That's interesting - I can sort of see it both ways. Would applying unit tests to the exposed functions not have sufficed?
  - andrekandre 2y ago
    not the op, but had similar experience kmp exposes everything as obj-c meaning c headers and not very good type annotations (enums are int only so you cant have full checking on each switch, everything is obj-c reference semantics meaning multi-threading gets tricky, kotlin exceptions are not catchable from swift) so there are a lot of edge cases to write unit tests for (on the client side) which negates a lot point of using kmp, and thats in addition to all of the kotlin-isms that leak out...
    - robertlagrant 2y ago
      Ah, right. Yeah, that is surprisingly bad! Why wouldn't they at least generate enums!
      - andrekandre 2y ago
        > Why wouldn't they at least generate enums! they do but its going through objective-c which inherits c enums (which are basically integers) so when you use it from swift its like switching over an unbounded set so you always have to handle "default" cases leading to bugs compared to usage from android

vips7L 2y ago

Dart is an amazing and underrated language too. It compiles to native assembly, has pattern matching, async/await, and null safety. The only thing it's missing in my opinion is some form of checked errors, currently they only have unchecked exceptions.

geodel 2y ago
> The only thing it's missing I think biggest thing it is missing is any kind of Google commitment on its long term usage.
tadfisher 2y ago
The modern language landscape is backing away from checked exceptions. Funnily enough Kotlin eschewed them as well, converting checked to unchecked exceptions on the JVM.
- vips7L 2y ago
  The modern language landscape has not backed away from checked errors. Rust is praised for its checked errors, countless posts on this forum praise Result<T> in multiple languages. Swift has checked errors and Kotlin is implementing them via union types in the near future. Checked errors, via results or exceptions have never been the problem. It has always been Java the language that hasn't provided the syntax sugar for handling checked errors effectively. There is no difference between: A doIt() throws B fun doIt(): Result<A, B> It all comes down to what the language lets you do once you encounter that error.
  - billllll 2y ago
    Is Rust praised for its checked errors? I've personally found it extremely verbose since there essentially is no possibility for unchecked errors. Also, external crates like "anyhow" are required if you don't want to account for literally every single possible error case. Really seems like a pedantic's dream but a burden to everyone else. Effective Java recommends checked exceptions only in the case where the caller may recover, but in practice you're usually just propagating the error to the caller in some form, so almost everything just becomes unchecked runtime exceptions.