11–20 of 79 posts
Same issue with Scala Native[1]. Both projects are a long way from being production ready wrt to targeting ios, android and desktop.
Probably at least a couple of years before either project delivers the one-language-to-rule-them-all.
This is great! I've adopted Kotlin as my go-to JVM language but being able to write code that outputs native binaries for things like CLI tools would be huge and may serve as a strong competitor to Go as a pragmatic, but well designed language.
Kotlin to LLVM is amazing idea and risky if it will break in Android. Only time will tell.
Using kotlin in web pages, client side and server side could be a big win. You could be able to use exactly the same language in all you stack. Although programming for the frontend will be different than programming for the backend, the fact that any of them can review the code of the others is great. You could also move resources in peak times to help a little.
> use exactly the same language in all you stack isn't this what people are doing with JavaScript?
Kotlin could run on all supported platforms and reuse Java libraries.
Earlier quoted context omitted.
> use exactly the same language in all you stack isn't this what people are doing with JavaScript?
It is, but the problem with that is that they're doing it in JavaScript. Kotlin could offer better performance and certainly offers strong type safety throughout the stack, which I at least certainly believe gives a better programming experience.
> This Technology Preview features automatic reference counting with a cycle collector on top, but what the final memory management solution(s) will look like is unknown at this point. Same issue with Scala Native[1]. Both projects are a long way from being production ready wrt to targeting ios, android and desktop. Probably at least a couple of years before either project delivers the one-language-to-rule-them-all.…
They talk about modules and I am curious about their syntax (if any). If we are to support a new multi-platform ecosystem, we should make sure it is built on a stable foundation.
For example, I really like scala, but I can't convince myself to try scala-js due to the unsoundness of the platform. Some scala libraries work, some libraries compile but won't work as expected and some libraries need porting. And you don't really know which is which.
> This Technology Preview features automatic reference counting with a cycle collector on top, but what the final memory management solution(s) will look like is unknown at this point. Same issue with Scala Native[1]. Both projects are a long way from being production ready wrt to targeting ios, android and desktop. Probably at least a couple of years before either project delivers the one-language-to-rule-them-all.…
May they all do great. But I am sceptical that Scala/Kotlin and many others started in last decade stand chance against Java/Rust/Swift/Go. IMO these 4 are backed by powerful corporations and have large community momentum. They are going to keep >90% of all software work along with C/C++.
I wanted to read 'The Swift Programming Language (Swift 3.1 Edition)'. It is just an epub, just distributed via Apple iBooks, right?
When trying to open in on an Android tablet, I found out that it is DRM-ed. Why on earth would you put DRM on a publication you want to circulate as widely as possible? Why would anyone have to read reference docs for multi platform language on a single platform?
That certainly dampened my enthusiasm for Swift.
Earlier quoted context omitted.
> use exactly the same language in all you stack isn't this what people are doing with JavaScript?
The problem with Javascript can't handle complex computation where Swift could run on both Android, iOS, embedded, cloud, Linux and web server and majority of C/C++ libraries. Soon they might found way to implement Rust memory model, concurrency and Coroutine like Go. It will be nearly perfect or as good without writing 4 different languages. Kotlin could run on all supported platforms and reuse Java libraries.
Earlier quoted context omitted.
TypeSript is more mature and better option for frontEnd now, but I hope kotlin will catch up. I wouldn't use kotlin for cross-platform mobile dev. There are few things Android and iOS share, you end up having to codebases in the same language (which it is good in its way). If you want to do truly native apps, just avoid sharing code because you will use different patterns and different libraries and apis. You could s…
In my experience, there is a lot of opportunity for sharing code between mobile platforms that doesn't have any real downsides. Things like: - data structures for your domain objects - network code (just plug in an appropriate platform-specific driver) - like you said, business logic - especially if the app has to work offline - if you're using something like https://realm.io/ , you could avoid a lot of duplication A…
not sure there are a problem since you have data classes in kotlin. I bet swift provides something similar.
> - network code
In Android you must use okhttp, and I guess there are similar powerful libraries in swift for this.
> - if you're using something like https://realm.io/
Last time I checked it I decided to keep using SQLite as it allows me to do everything I want. Realm doesn't support "complex" SQL queries.
Again, just business logic. But there is no too much apart from field validation or simplex operations to show the data (or it should be much more). Complex things must be in the server, that is the best way to share business logic among all your apps in all the platforms.