Why didn't Google go with Kotlin for Flutter? It sticks out like a sore thumb.
Better Java than Java: Kotlin 1.4 introduces new compilers for JVM and JavaScript
JetBrains has released Kotlin 1.4, a significant update to the Google-preferred language for Android development. Kotlin began as a language targeting the Java Virtual Machine (JVM) but although its core use is for Android development, it can target other platforms including native code. Kotlin/Native uses LLVM and compiles …
COMMENTS
-
-
Thursday 20th August 2020 06:45 GMT Dinanziame
Maybe it's just timing. Flutter was announced in 2015, Kotlin released for the first time one year later. It was probably too late to turn the ship around. Then again, designing a language to be multiplatform and designing it to improve on Java might well mean fundamentally different life choices that you cannot easily reconcile.
-
-
Wednesday 19th August 2020 17:16 GMT Baudwalk
Kotlin itself is quite nice...
...but getting the exact incantations right for including some of the popular dependencies is pure hell.
Kotlin and even Java itself these days are actually pretty nice languages (Clojure is better, IMHO), but Gradle is a big no. Just No!
Even the C++ ecosystem's way of tracking down, downloading and building by hand each library feels less onerous.
-
Thursday 20th August 2020 09:13 GMT Androgynous Cupboard
A thousand times yes to the module management issues.
I've built a very simple Json parser in Java. Hosted on github, no dependencies, single package, ant script to build it is about 15 lines. I thought I might integrate it with a Java Json benchmark suite, for which I needed to have it building under Maven and distributed from bintray.
I spent literally a day on this before I gave up. Getting it to compile under maven was manageable, although more verbose than it should be. But the precise incantation required to get it distribute from bintray and make it a "proper maven module" was beyond me. The sheer complexity of the layers wrapper around what is a very simple requirement made me weep for the industry. I can't sum it up better than in this image.
-
-
Thursday 20th August 2020 08:03 GMT Mike 137
Sprouting like mushrooms (or are they toadstools?)
Languages are apparently proliferating without bounds and each has its vociferous advocates, but is anyone assessing the quality the actual executables they deliver? That seems to have been overlooked in the scramble to make "development" more "user friendly".
-
-
-
Thursday 20th August 2020 09:42 GMT AMBxx
Re: Sprouting like mushrooms (or are they toadstools?)
I think he has a point. C/C++ has been around since the start of time. C#/Java for 20+ years. All of those are still in demand.
How many languages that appeared 10-15 years ago are still in demand? So much effort seems to be being put into new overlapping languages for no apparent benefit.
-
Thursday 20th August 2020 17:18 GMT Michael Wojcik
Re: Sprouting like mushrooms (or are they toadstools?)
How many languages that appeared 10-15 years ago are still in demand?
For the past 10 years: Rust (2010), Dart (2011), Kotlin (2011), TypeScript (2012), Julia (2012), Swift (2014).
I'm not claiming those are all good languages, but they're all "still in demand" by any reasonable metric. They're all being used for production applications, they're all still present in the trade media and in various surveys, they all still have their proponents and backers.
And I don't think that's a very useful metric anyway. There may not be much demand for AUTOCODER; that doesn't mean it wasn't important. You don't see a lot of new ALGOL projects - that doesn't mean ALGOL wasn't hugely influential. Pascal1 has largely fallen out of favor (pace Stob and other Delphi fans), but it left its mark, too. ML was never much for production apps, but its descendants OCaml, Haskell, and F# - even while they remain niche languages - have had a significant impact. Erlang has never been as popular as it deserves to be, but people keep reinventing it, so it must have done something right.
On the other hand, Fortran, COBOL, PL/I, etc., not to mention various assembly languages, may not be sexy, but they have a hell of an existing code base and there's still plenty of fresh development in those "legacy" languages.
And, finally, why not develop new languages? Kotlin and other JVM languages pushed Java to improve in its expressibility and syntactic sugar. If people are going to continue to insist on developing huge applications in ECMAScript-based languages, then yes, please, let's have some with a bit of type safety and other improvements on the base language.2 Whenever I'm writing something in Managed OO COBOL I'm glad to have generics and type inference and anonymous methods with proper closures - even if I don't need them for whatever I'm doing at the moment.
Language development gives us better languages.
1The programming language, not the mathematician/philosopher, or the Reg regular commentator.
2Yes, I know you can do purely functional programming in Javascript with proper algebraic structures and monads3 to defer side effects. And that's great, since you can then do all sorts of handy reasoning and manual or automated proofs of correctness about the vast majority of your code base. But clearly only a vanishingly small fraction of Javascript programmers are willing to learn how to do this.
3Look, we've explained this already. A monad is a monoid in the category of endofunctors, like a semicolon with side effects. It's so obvious.
-
-
Thursday 20th August 2020 10:12 GMT iGNgnorr
Re: Sprouting like mushrooms (or are they toadstools?)
There's change, and there's change for change's sake. There's far too much of the latter, which makes useful changes easy to overlook.
An important ability in programming is to get it right. Jumping from one language to another doesn't help this necessary ability. Do one thing and do it well, aka "Jack of all trades, master of none."
-
-
-
Thursday 20th August 2020 09:56 GMT Uplink
Kotlin 1.4 Intermediate Representation
First, XKCD: https://xkcd.com/927/
What I'm thinking in relation to the XKCD is that the 15th standard is not a competing one, but one that deploys to any one of the other 14 as needed. It may become _the_ standard later, after nobody cares about the other 14 anymore, just like barely anybody cares about Assembly language and CPU instructions when developing software these days.
Then the crazy happens: Somebody develops standard 16 (rather than patch 15), the maintainers of 15 make it deploy to 16 as well, and the ones of 16 deploy to 15... And the winner is declared in a tug of war, not dissimilar to Betamax vs VHS, DVD-R vs DVD+R and HD-DVD vs Blu-ray.