The Kotlin Foundation
kotlinlang.org
kotlinlang.org
They're also co-founders of the Rust Foundation[1], the major member of the select group of companies at the table at WHATWG[2] (which amongst other things decide on the future of web technologies, including JavaScript) due to their browser's market share, and a "visionary sponsor" of the Python Foundation[3].
They also develop a few programming languages themselves, like Go and Dart (not to mention their polemic Java implementation), besides their own OS (Android, Fuchsia).
A company as large as Google is kind of expected to be using every technology in existence, but I still find it interesting how they're also making sure they also play a major role in the evoluation of such technologies by being part of any Foundation that might have any relevance whatsoever (if not via their own languages, at least by exerting influence on everything).
[1] https://foundation.rust-lang.org/posts/2021-02-08-hello-worl...
But who knows, we are not allowed to ask these questions, just like why DRM was allowed into the web standard and W3C kept the votes secret.
I don't like the route we are heading.
In 10 years of developing Go, I know of only 2 things that the community has disagreed on with the Go team - package management and generics. One is already fixed and the other will be in a year. Nothing I can think of wrt their contributions to Rust, Kotlin, C++, Python etc.
No one has ever articulated why it's a bad thing that Google sponsors open source development. If someone could articulate specific reasons, that'd be great. But this kind of FUD comment ("hmm, they sponsor an awful lot don't they") doesn't add much.
You can't just claim "everything they touch sucks" without a single example or evidence to back it up. You look like a hater.
Go is moot point because they control that language anyway, people have no say on it except people who work at Google.
No surprise that you cannot donate any money there.
Point out where this arrangement hasn't worked well. Otherwise you're just spreading FUD.
Examples of foundations and centers that do this are R, OCaml, Zig and Ruby. All successful.
> Point out where this arrangement hasn't worked well. Otherwise you're just spreading FUD.
W3C and DRM, do you know who voted for this and who is on the board of directors of the W3C?
If you need some time I'll wait.
[0] https://www.ft.com/content/24efc152-a65d-4c48-9032-ee349a2c8...
Is there a good way to get non-paywalled access to this? It says I can read it if I register but today that's just one step too many for me ("_Another_ account? Really? sigh" :) )
I'm kinda curious to know why anyone is trying to start a new search engine(s), given both Google and Bing.
(But apparently not curious enough to give my email address to Yet Another Website :) )
I feel like a goofball for not trying that myself, but appreciate the advice/tip. Thanks!
Moreover, as a public cloud provider, they are ultimately expected to be supporting virtually every technology in existence. Amazon (explicitly as AWS, usually) and Microsoft have pretty similar degree of foundation involvement
Kotlin is a much better Java, and these days if I need to use the JVM, I will use Kotlin.
However, I do feel that there is a huge missed opportunity in making something that is not just a better Java, but a better language. Kotlin has a lot of annoying limitations, almost all of which are there because the JVM doesn't allow better implementations using first-class JVM functionality.
One of my favourite examples is multimethods which would be an amazing improvement. However, the JVM can't do dynamic dispatch on multiple arguments, so Kotlin will never get it. Sure, if they implement it, calling Kotlin from Java would be more complicated, but that really shouldn't restrict how the language evolves.
Another thing I'd like to see changed is better support for DSL's. Some nice stuff has been done with the limited facilities that are available, but it always seems like I'm fighting the language when making DSL's. As someone who writes a lot of Lisp, I'd really like to see a macro system.
I keep waiting for a good solution for SQL in Java (or another language) that isn't a builder or a string with templating. I don't like what React does architecturally, but JSX shows how mixing languages in an elegant-ish way can be huge.
Also among various other tech stacks I've never seen something that hits the sweet spot between "plain sql" and "advantages of ORM-stuff" as well as jooq
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1] https://github.com/appliedblockchain/tsql
Groovy DSLs are much better than Kotlin's.
It can since Java 7, the instruction invokedynamic was added for this kind of stuff.
The implementation for Pattern Matching (the project Amber) [1] will use the very same instruction.
[1] https://cr.openjdk.java.net/~briangoetz/amber/pattern-match-...
The language that was supposed to replace Java in JEE and Spring.
Had it not been for Gradle, and there would be hardly a reason to learn it in 2021, other than historical interest.
I see a pretty active community around it and lots of new releases (from the libraries and the language itself) coming up all the time. Your picture of Groovy being dead couldn't be more wrong in my experience.
As mentioned, Gradle is still around.
Kotlin is just a joy to read and write.
Usually when working on a new non-trivial task, I first think of the solution, then write it down in pseudo code.
Reading a Java implementation of my original pseudo code - I sometimes feel the actual solution hides below layers of code. The solution is still there, but it is hard to see it.
When comparing the resulting Kotlin code with the original solution written in pseudo - Ir can still be seen clearly.
Kotlin does not get in the way, but still allows me to use strong typing and compile time checks to make sure my code is solid and stable without loosing readability.
It is just great joy, fun, using it.
I have no idea whether that's a good idea, but it looks a little funny.
Also, is UT Austin officially involved, or is it just William R. Cook personally? This is ambiguous from the text.
Anyway I hope this gets them whatever they want out of it, I quite like Kotlin and might learn it "for real" some day.
The balance might still work out in the short-term, as the Language Committe's scope is narrower [0]. This makes sense as the LC seems to be more applicable for when external developers propose potentially breaking changes.
[0] https://kotlinlang.org/docs/language-committee-guidelines.ht...
I’ve only ever looked at Kotlin code in blogposts, haven’t ever actually used it. I’m probably at least a few years behind on its feature set, but I am aware of all the great features Java has added in that timeframe, many no doubt inspired by Kotlin!
Would you advise me to use Kotlin over Java building a new API from scratch in 2021, given where both languages and ecosystems are today? Why or why not?
You can also easily handle nulls in Kotlin, since values have to be explicitly nullable in order to be able to have one. This is great for your application model layers. The val/var paradigm is nice so you can stop having to remember to write 'final'.
If you ever get stuck and don't know how to write something in Kotlin, you can just write it in Java and either use it, or just paste the code in IntelliJ and it will convert it to Kotlin.
Lastly, Kotest + Mockk is awesome--super readable testing.
I'm a huge proponent of Kotlin on the server side, less on frontend (JS) side.
If you go with Kotlin and Spring Boot, Micronaut or even just Ktor,you'll likely not regret the choice. (I have no experience with DropWizard).
Now if you choose Java it will not be a horrible choice either, and it is not too hard to convert to Kotlin later if you need/want to. I've heard cases of people going back to Java a few years back, mostly for compiler performance reasons, but there has been a lot of effort on that recently. And while compiling Kotlin is still slower than compiling Java, the fact that you can divide things more easily in multiple files and incremental compilation compensates in most cases (except of course in the case f a clean build).
Kotlin is a chance to get away from the cruft and annotation magic of traditional Java.
I use Ktor and it's everything you need for a modern API (and can be deployed as a WAR if that's why you want Spring Boot)
Ktor's API that will be familiar to anyone who's used similar "neo-web frameworks" in other languages like Gin or Express, and it allows you to architecture your app in a way that makes sense to you (so if you need DI, you can bring in something like Koin, but you're never compelled to by the framework)
https://www.jetbrains.com/help/youtrack/standalone/Third-Par...
That's not necessarily a bad thing, but usually people who are giving the JVM a "second chance" via Kotlin were initially turned off by that ceremony
-
So when someone asks me "What should framework should I try for Kotlin web services?" my answer is usually Ktor.
Because if they had to ask me, they probably aren't going to be that in love with Spring Boot (people coming from Java from example, are usually just going to default to Spring Boot)
There's everything, from the simplest possible https://sparkjava.com/, to the a little bit nicer https://javalin.io/ (which has a Kotlin wrapper), to the high performance and full framework https://vertx.io/ (which always had great multi-lingual support within the JVM), to the newer and GraalVM-friendly https://micronaut.io/ and https://quarkus.io/ ... for the Enterprise-only crowd, you still have the JEE successor, https://jakarta.ee/ and Oracle's own https://helidon.io/#/ (which likes to position itself as microservice focused, like Micronaut and Quarkus). Not to mention lower level libraries you can use, like https://www.eclipse.org/jetty/ and https://netty.io/.
Ktor has a tough fight to become dominant even in the Kotlin world.
Spring Boot is, still, definitely the most popular option, but it's still just one of very very many!
It also changes the development workflow from a maven-based project to a NPM-based project which should be more familiar to JavaScript developers.
How does using Ktor preclude one from using anything you just described?
Lol just using Koin alone would bring every thing you just described, with the added benefit of not delving into XML files.
Really some people are just married to the mentality of "If it's not on the feature list, I guess you can't do it". I believe in using focused tools that excel at specific things. Ktor lets you do that.
You can set them up other ways, but it just ends up making a lot of sense to define them there.
To be fair, Ktor is pretty similar with the "application.conf" if you use the built-in Profiles equivalent: https://ktor.io/docs/configurations.html#hocon-overview
I just prefer that if I'm using DI, the concept of environments be handled by DI. Scoping is what DI does best after all...
I've not had the pleasure but I hear Scala is great too.
As for the Android Runtime, Android team is gatekeeping Android Java on Java 8 subset on purpose, as means to serve their political games to push Kotlin no matter what.
Kotlin without godfather Google will just fade away.
Google lets Android Java stagnate on purpose on Java 8 subset, with cherry picked APIs from newer OpenJDK versions, uses this language subset to sell Kotlin features over Java features on code samples comparisasions.
Nowadays, all Android developer channels, regardless on which form, are all inundated with Kotlin material and how great it is over "Java" (actually Android Java).
As for JVM being flexible enough to support Kotlin, doesn't seem to be appreciated by the Kotlin community that spits on the hand that has made the language possible to exist in first place.
Language wars don't have a place when languages share the same platform, as such I have zero tolerance for communities that cargo cult otherwise.
When Kotlin is so great and doesn't need Java for anything, they should port everything into Kotlin/Native and succeed on its own merits.
I also find language politics to be incredibly boring. Maybe you have a point, but I just want to write code in a language that isn’t 10 years out of date.
For better or worse, Kotlin designers have decided to make a deal with Android for turning it into Kotlin's plaform, and they definitely do not care what happens with the JVM.
Kotlin designers will eventually, like everyone else, find out that one cannot stand on both sides when things start heating up.
Then there is the whole matter of ChromeOS vs Android vs Fuchsia of Google's internal politics, and Kotlin is only relevant in one of them.
First of all Java and the JVM are two different things. One is a language and one is a runtime.
Yes Kotlin requires the JVM. So does Scala and a lot of other languages. Leveraging the JVM runtime means that Kotlin can inter-op with Java libraries and the ecosystem at large without having to build all those things anew. Its all upside. You get the niceties of the language plus the rich ecosystem. I can for instance leverage Apache POI in Kotlin to generate some excel workbooks despite the fact that that library is old af and doesn't know anything about Kotlin. I have in fact. It works great.
Your argument doesn't have legs to stand on. Languages like Elixir leverage existing runtimes as well. Its not uncommon and its a feature not a bug.
People moving from Kotlin back to Java is not unheard of: https://blog.allegro.tech/2018/05/From-Java-to-Kotlin-and-Ba...
(On Android however it seems it's pretty much the only thing now. I am finding it the hard way now when I am looking for a job after staying on a project too long where things are still 98% Java)
It's an amazing language. Just try not to write "Java code" (as in the Java way) in Kotlin (like many Android devs I see doing).
Can't think of a single developer that would choose Java over Kotlin.
The view being that async-await leads to a "What color is your function" problem ( https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... ).
You don't have to convince me that green threads are far superior to async-await - I already believe that.
But that's not something Kotlin (nor Java, on the language level) could have solved.
Kotlin could be stuck here with a inferior co-routine model; Handicap of a headstart. Tough of course time will have to tell if the model Loom introduces in Java is going to be as great as it sounds.
Well that’s the point - they solved it in the JVM not as a kludge of bytecode.
It's rude and unfair to call out a language as "solving the problems with kludges" when they literally could not have done anything better.
Seems like it fixes trivial things (makes simple classes a bit more terse) but retains the more fundamental problems and hangs on for Java to actually fix those.
Also, Kotlin usually forges ahead on features, and the Java is playing catch up. Take data classes for instance. If anything it seems like Kotlin gave Java a good kick in the pants to get it to start developing faster and adding modern language features.
If Kotlin is so much better, why doesn't JetBrains just port everything into Kotlin/Native?
Instead, they focus on things like value types. Which are definitely cool, but they don't actually solve any of my problems. Typical business apps written in Java don't suffer from performance issues, they suffer from (accidental) complexity explosion and subsequent buginess (of which NPEs is a symptom).
Kotlin syntax makes writing functional code beautiful and simple... map and fold and filter are so much easier to write than in any other language that also have the same functions, such as JS. Again, that alone would be enough to migrate.
But there are still so many more simple, but incredibly useful functions like SubstringAfterLast which takes a nasty, ugly Split function into a beautiful, precise line of code. Just one example of many.
A good example is Kotlin/Native, by choosing a memory model incompatible with JVM code they failed, and were forced to go back into the drawing board for Kotlin/Native with a proper tracing GC.
For example, you need special syntax to use SAM types and Kotlin cannot use all use cases from interfaces with default methods.
That is the thing with the Java Virtual Machine, the bytecodes and runtime are designed for Java, all guest languages have to pretend to be Java.
Just disassemble the amount of boilerplate generated by the Kolin compiler.
Another example is inner classes. Inner class can access private fields of outer class in Java. But in JVM there's no inner class concept, so compiler generates synthetic accessors for outer class private fields and inner class uses those methods to access private fields. That was fixed recently, though, but it was the case for many decades.
Also I remember some funny bytecode with try-finally, I think it's implemented with gotos.
Of course Kotlin generates a lot more boilerplate, that's for sure.
I do think kotlin isnt only aiming to the Java Virtual Machine, it is mucho more.
On the contrary, platform languages slowly acquire the relevant features of the shiny languages, which eventually either fade away or find a niche for survival.
Kotlin will be relevant as long as Android exists, that is all.
Gradle and Google choosing it for Android are the only things that keeps Groovy still relevant.
As for Clojure, it is its own thing, plugging into the host platforms.
Scala native doesn't feel like it has the same impact, perhaps in part due to a lack of momentum (as I perceive it).
Server software for unixy systems used to be near universally written in C and it's still "the" platform language. And it can be certainly be said that alternative languages have come and gone.
But: C has become a niche.
Yet, there are no FOSS language that matches JIT and GC capabilities of the JVM.
Looking forward to the KVM, if Kotlin is so great.
Google had a easy way out after screwing up Sun, buy it.
Scala on the other hand is facing a decline. Less so in Big Data where it is still doing well but I find increasingly it's not being chosen for new backend development.
I would imagine everything is fine now.
If you want to go further you can also use other nice features like suspend functions, hot/cold channels, sealed classes.
No need for FFI, additional IDE plugins, it works across all Java IDEs, no need for idiomatic plugins, annotations to make code understandable by the JVM, full access to JVM opcodes without constraints or special cases, and it will be around as long as the Java Virtual Machine matters to the industry.
Actually you don't really need any new features to write useful programs. They might help, but they are not necessary.
My advice would be to learn both languages and use your own judgement which one you would like more.
It came in and filled the niche that i always thought Scala would fill.
I’ve been doing mostly Swift for the past several years, and i love it.
Scala 3 looks interesting but it seems to be moving slowly.
I look forward to having another Java option if I ever get back to that platform. Java was cool in 1998 but after Swift, I’ll need something nicer on the JVM
You unfortunately cannot add new (stored) properties to existing types like you can in Swift.
Java is already taking hints from Scala and quickly adding Scala inspired features, which is making it similar to Kotlin. I think unless Kotlin innovates and does something not already in Scala, it will likely run into the issue of being too similar to Java ~20.
Just as PSF promoted Google to visionary sponsor, although I understand Jetbrains, but we see yet again our saviour Google on the board of yet another language, even after Rust formed its foundation.
I guess I have no choice to accept this future we've put ourselves in.
and another trend on prog. langs: they're becoming more and more similar feature-wise (eg. pattern matching)
So that justifies giving them a seat at the board of directors and not just a sponsorship?
Apple and Facebook both use Rust but I don't see anything about them being on the board (at least Facebook for now), the least I expect is sponsorship.
Now I would be unhappy to see a company that just pours millions in a project, gets to take decisions but doesn't do anything else to make the project better. But I don't believe that's the case here.
It seems we are all OK with allowing this to happen, but we shall see.
Apple gives back to open source projects. Isn't Swift open source as well as LLVM and Webkit?
Makes sense because they made them and a long time user of them.
If you compare the number of companies using a project and how many contribute, you will likely only need one hand to count the later...
But then again, I guess I have no choice to accept this future we've put ourselves in.
At least I can as an individual give back to Kotlin, no wait...
Sure it's all good when companies fund projects they use, but that does not mean they should instantly get a board seat.
It makes sense why Jane Street sponsors OCaml, does not mean they instantly get a board seat. I don't see Jane Street sponsoring RISC-V and getting a board seat do I?
And it doesn't make sense to do so.
I find is suspicious for companies to join or create a foundation and get automatically propped up on the board, especially Google.
It's going to be much harder to remove them if your values are not aligned with theirs or you dare criticise them.
Honestly I just don’t see it here. Google’s marketplace ambitions have not surfaced in these foundations. I would Love a real tangible counter example of Google leveraging their seat on a language committee to control the language in such a way it only furthers Googles interests. Even with the browser I don’t see them outright controlling tc39 or WHATWG/W3C or the CSS working group. Otherwise HTML imports would be a thing right now (and arguably they should be but that’s another debate)
I don’t defend what they’re doing with Chrome the product but they so far have seemed to be pretty sane with standards bodies
The thing about Google or any entity of their size is that they’re huge and lots of different types of people work there, and I’d wave most aren’t malicious
That doesn’t handwave legitimate complaints here and I don’t like Google have arbitrary outsized influence either but I don’t think that’s the case with these commuters/foundations
I don't see what benefit of putting them on the board would give them, same thing with Rust, just because it's used on Android? Was a gold sponsorship not enough?
> Honestly I just don’t see it here.
You're not looking hard enough, they are bearing 'generous' gifts to these foundations, Example: OpenAI was all about openness weren't they?
But a big somebody bared a huge gift and so much for 'Open AI'.
Don't you think Google and others like them are doing the same thing such that they are getting you to use their products through their 'donations'?
> That doesn’t handwave legitimate complaints here and I don’t like Google have arbitrary outsized influence either but I don’t think that’s the case with these commuters/foundations
Again we shall see, but I am seeing this everywhere and I am not happy with the shift from community to corporation led open source projects. A sponsorship should be enough but they want more as always.
That said, I’m unable to think of or find obvious examples of them having a track record of using foundations like this for their own agenda at the expense of the community, language or only to further their own ends. Even with the browser stuff there’s Chrome the product which makes a lot of changes that does hurt the community but then there’s Googles representation on tc39 and in the web standards groups. With that I haven’t found evidence of malpractice or foul play. Please give me some concrete evidence that they have a history of this as I’m not finding it.
Doesn’t mean that as a whole these companies get a pass for Bad behavior, I think a key to a great argument against something is to be able to scope what it does and doesn’t do, so I hate to say they are doing this for malicious reasons only to be wrong (and again I’m not seeing evidence) and undercutting more legitimate arguments. Fundamentally that’s the arching issue we end up with by just making assumptions without evidence at a minimum
You don't need to provide a board seat to any company that tries to throw money at you, just because they use your language.
Just make them a sponsor, and there are examples of this.
And the special guest is Huawei as well just because they use Rust in some way.
I'd rather have them sponsor Rust without giving them too much control by placing them on the board.
Again, specifically: what control are you worried about? I suspect that you think the foundation has powers it does not have.
Again, I'd rather have them just sponsor Rust, why wasn't a gold or platinum sponsorship like structure considered without placing them on the board of directors.
How about a corporate membership without voting rights?
If it was the primary concern we wouldn't be having this conversation, lots of foundations have this structure.
Right now, it is more likely that Facebook would get on the board before I can even donate.
Looking to give Kotlin another shot for non-Android API consumption and it seems like Ktor is a frontrunner. Looking at Spring WebClient to consume a JSON API makes my eyes hurt compared to other languages.
The companion object makes things like loggers ugly. Skipping parentheses for method calls that take lambdas can be nice, but all it does is safe a pair of parentheses, it makes for inconsistent syntax, and is pretty ugly when the method takes an arg. The lack of implicit upcasting is weird. The set/get sugar is nice, but it looks ugly when it's next to places where it doesn't work.
My god, the Ktor documentation is absurdly bad. Like horrifyingly bad. Google fu throws up results which do not have runnable code or explanation. Enough to put me off Ktor completely and continue my search. Maybe Jetbrains should drop web services framework development and focus on IDE cos Ktor is horrendous and scratch files could use some love.
Absolutely terrible API aswell.
That said: we still enjoy using Kotlin, I just wouldn't ditch Java for it if I had to pick one.
[1] https://sites.google.com/a/athaydes.com/renato-athaydes/post...
But, I have been worried about it’s future. I hope this helps make sure it has a future.
edit: lol @ the down votes
I know this comment is just a joke, but I think it's an indication of a bigger problem.
In order for Kotlin to be taken seriously outside Android, especially in relation to Swift/Rust as a native language, it needs a few changes.
1. Make the compiler native binary and competitive with other languages for startup times outside Gradle workflow.
2. Support linux CLI and make/cake work flow as a first class citizen.
3. Support Linux as a host for Kotlin multiplatform mobile. Right now C is the only true multiplatform language
I made a post on Kotlin forums on this topic if anyone here wants to take it up.
I have been doing pretty alright with Ada, Object Pascal, D, Go, Rust, C#, C++ and Java (yes even on iOS).
Jetbrains recently removed working Linux support for KMM as a host platform.
https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memo...
I switched back to modern Java and did not regret it.
Java is catching up at a fast pace, I don't think Kotlin will ever replace Java or see mass adoption.
On the JVM, Kotlin doesn't matter, it is just another language that pretends to be Java when compiled to Java Virtual Machine bytecode.
It was already hyped up and rapidly gaining popularity for Android devs prior to Google endorsing it. That's why Google endorsed it.
> On the JVM, Kotlin doesn't matter, it is just another language that pretends to be Java when compiled to Java Virtual Machine bytecode.
I mean sure, but this applies to replacing Java elsewhere too.
If Google wasn't playing dirty, they would have kept updating Android Java to be in line with Java, and let the developers choose.
Instead, they purposely stagnate Android Java on a Java 8 subset, let the Android marketing machine push Kotlin over Medium articles, Twitter blog posts, YouTube Android developers channel, Android developer blog posts, MAD training material.
And lets not forget the role of JetBrains, having had a role replacing Eclipse with InteliJ in what concerns Android Studio, now they even dropped support for Eclipse on their Kotlin support, as they are quite open that they want to use Kotlin to drive InteliJ license sales.
Kotlin is just another flavour of CoffeeScript in what concerns the JVM.
I still use and enjoy a few others, namely Rust but unless I need something specific I don't generally need to look past Kotlin.
You get the full JVM ecosystem, terse language that supports powerful abstractions and JVM runtime performance/features - i.e threads, debugging, prod tooling.
But then...
> The code is distributed under the Apache License, Version 2.0.
Joke aside, seems that kotlin is a niche player and will remain a better Java until something like Rust eventually takes over the enterprise market.
I don’t see how Rust displaces Java or Kotlin. It’s very different with different use cases that it’s suited for and different strengths and weaknesses.
Kotlin also seamlessly inter operates with Java, which is a big deal for any company with a large existing Java code base, which are legion.
Kotlin/Native is never going to be a match for other native languages, as its reboot by choosing an incompatible memory model with JVM languages has proven.
While on the JVM, just like trying to replace C on UNIX, JavaScript on the browser, it is just another guest language dancing to Java tunes.
Just another one to share seats between Beanshell, jTCL, Jython, JRuby, Scala, Clojure, Groovy, Ceylon, XTend, without big daddys' help to force adoption down developer throats like they are doing on Android.
They are just betting on a new horse after the old ones failed to win the races they were set off to.
I kept being downvoted when I talked about S4TF going nowhere and the news today prove many of us were right about it.
Similarly I will give about 5 years time for Kotlin fashion to die everywhere outside Android, this assuming that Fuchsia won't eventually become the new darling.
It is quite telling that Google's own business units like Ad Words and Google Pay rather go with Flutter, and write blog posts about it, instead of adopting KMM.
Jetpack Composer is a political answer to Flutter.