This is great for Kotlin! But I need to make an observation about Google...
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).
I think we have to understand that Google is a large company filled with people with technical skills. These people are rewarded for contributing to open source. So they do. That's it. It is entirely possible that maybe Google employees might want a feature that others don't, but I haven't seen that evidence.
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.
This lacks nuance. You ignore the effect they have on the ecosystem as a whole. Mentioning the "Go community" and their "agreement" of Google's decisions without acknowledging this is disingenuous at best. They have already swayed and gatekept large swaths of the (web)development "community" by their decade-long dominance and no one can make an impactful, meaningful decision in that field without their implicit approval. Their dominance is felt best by the way they control the conversation i.e. what we don't talk about - i.e. the web among other things they touch sucks, continues to suck and it is going to get worse and less free and they are significant negative contributers. So yeah, I'd rather see them cut into pieces.
Your comment lacks any content. You make vague claims of "effect on the ecosystem" without mentioning what that is. Give an example. Can people not create web frameworks? Can people not create products hosted on the web? Can people not use AWS or Azure for all their computing needs?
You can't just claim "everything they touch sucks" without a single example or evidence to back it up. You look like a hater.
A lot of people here aren't necessarily pro-Googlers, but rather open-source contributors who want to secure a future for themselves. That's not a bad thing, and Google's partnership with open-source has been mostly benevolent. People are quick to point to the "killed by Google" argument, but how is Google going to kill an open project? If they stop funding it and nobody takes up the mantle of maintaining it, maybe it's not actually that useful anyways. In either case, you still have the option to maintain the code yourself.
Thanks for the ad hominem attack. FYI, I have no google stock, never worked for google, have never contributed to a google open source project. If they’re supposed to be paying me for pointing out common sense on this thread ... they’re late on their payment.
> Thanks for the ad hominem attack. FYI, I have no google stock, never worked for google, have never contributed to a google open source project. If they’re supposed to be paying me for pointing out common sense on this thread ... they’re late on their payment.
Foundation needs money (to hire employees) and resources (server time and bandwidth) to run. Sponsors of the foundation will fund this. It's as simple as that.
Point out where this arrangement hasn't worked well. Otherwise you're just spreading FUD.
> A company as large as Google is kind of expected to be using every technology in existence
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
Sure, I do welcome the language getting support however, I can't help but think it may be to do with them being fined by Oracle in that lawsuit costing Google billions.
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.
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 :) )
Copy title, paste into search engine box and access from the search engine list. It seems FT wants to get the traffic and the indexing more than money from subscription.
What's in it for them, though? Just being users of a language does mean they need to back them up financially or set up foundations or influence them in any way
What is your point? Maybe you need to make it more clear. Note:I am neither pro nor con Google, although I have both praised them and critized them in the past, for different things.
I started using Java in the 90's and worked for Sun back in the day, so I have a reasonable amount of experience with it.
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.
Where I work we use Groovy heavily for testing (with the Spock Framework - which is amazing), in our Jenkins pipelines, and for Gradle Plugins in our build.
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.
This reminds me - a Java language architect was asked what his favorite non-Java JVM language is. He said Clojure because it's not trying to just be a "better Java".
> Another thing I'd like to see changed is better support for DSL's
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.
we use jooq extensively it's probably the most valuable tech in our backend.
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
String templating elevated to "tagged templates" [0] which dispatches template on your own function is suprisingly acceptable solution. I'm using it to drive mssql sql generation [1] and it works really well with type system around combinators. It's perfect, extremely lightweight way to achieve embedded dsl like experience.
I actually think that once you have Kotlin on top, it might open the door to another VM or bytecode generator. What's the point of having that abstraction if you're so tied to some other company VM?
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.
100% agreed. I use Java for work, used to use Python for little side projects, but started using Kotlin for side projects recently. It feels like the best of both worlds to me: the strict structure of Java, with the ease of writing new code of Python.
So Roman Elizarov is the Lead Language Designer, and also 1/3 of the Language Committee, so the Language Committee has to be united against him in order to block any design decision.
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.
I'm assuming that if/when more organisations join, the Language Committe can be extended.
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.
A question for HN - I like Java a lot for the ‘http API talking to SQL database’ usecase, with my goto for that being dropwizard or spring boot.
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 have to consider not only the language but what the team working on it will look like. It is still a bit hard to find server-side kotlin devs. On the other hand in my experience, Java devs pick up Kotlin really quickly (as do Python devs interestingly whereas they struggled with Java).
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).
Strictly imo, using Kotlin with Spring Boot defeats the purpose if you're trying to get away from traditional Java web frameworks (didn't think I needed to spell this out due to the next sentence, but HN gonna HN).
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)
My old team used Spring and Kotlin and it was a really productive combination. Spring isn't standing still. They have first class support for Kotlin and rewriting their framework to support the graalvm.
Spring is not standing still, and I'm not trying to claim it is, but there's still a fair bit of ceremony around a lot of features
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)
Or http4k, which implements "server as a function" and is fantastic for an API backend, with lenses/contracts, auto-serialization on top of your choice of Kotlinx/Gson/Moshi/Jackson, nested routing, so much more.
Scala support is still being finished, however the project team decide to go ahead releasing 4.0.0 at the beginning of the year avoiding the block until the Scala support work was complete. You can follow its development on GitHub or the official Discord server.
JavaScript's support has been moved to the reactiverse project. It's an incubation like project for projects that aren't fully 1.0.0 yet. In there you will find https://reactiverse.io/es4x/, the EcmaScript support For Vert.x. It's a new approach of using vert.x with GraalVM to provide modern ES language features such as ES12, instead of the old Nashorn ES5.1.
It also changes the development workflow from a maven-based project to a NPM-based project which should be more familiar to JavaScript developers.
It's not surprising that the company behind the language would promote use of tools native to that language. They have the incentive to fix the tools if bugs are found to make the ecosystem more attractive. Whether it's a good choice for your use case - you need to evaluate it.
It depends on your needs I guess. Not all API can be handled by just a few classes. If your plan is to maake a microservice that expose a single value, yes spring boot is likely overkill. But when you have complex models with runtime configuration and profiles and so on... Maybe we need to specify what we are really talking about when we say API. For some it just means a partial implementation of REST.
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.
My team uses Kotlin + Dropwizard + Postgres a lot. I would absolutely recommend trying Kotlin out on your next API. You will find the code very easy to learn coming from Java, and it is honestly a joy to work with compared to Java. You will find your code much more concise yet more readable. Also, IntelliJ gives you all kinds of hints for how you can make use of Kotlin language features.
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.
We use MyBatis annotations. Usually, for our specific use case we are calling a Postgres sproc. It was a little tricky for one part since we have a json type column, so we had to create our own little pgobject mapper which took a day to figure out how. Other than that, it has been a breeze.
Kotlin never appealed to backend developers (based on job ads, new open-source projects in the domain). Data pipelines, concurrency and streaming are becoming more and more part of what a backend dev should know. Instead, I've noticed that Scala is used in many systems where Java historically was less ergonomic for the task. Spark, Delta, Deequ, Scio, Finagle, Flink, Kafka, the Typelevel & ZIO ecosystems, Akka are some of the examples. Using Kotlin as a sugary interface to Spring Boot? Maybe for some that would be an incentive.
Kotlin is taking off on the backend. It took a little longer than some people might have hoped but all the big boys are doing backend development in Kotlin now. Square/Netflix/Uber/Twitter/AirBnB all traditionally Java houses have adopted Kotlin in one way or another.
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.
Yeah also somewhere after Java 7 (I think) Java stagnated because the next version was too ambitious (stuck in development-hell). To get back on track they cut a bunch of features, labelled it Java 8 and moved Jigsaw (the biggest hurdle) to Java 9. After this they also moved to the fixed release cycles.
Java stagnated because Google torpedoed Sun, left it sink without bothering to own Sun, Oracle was the only one that bothered to keep their buy offer (IBM withdrew theirs), and and to spend a couple of years setting the house straight.
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.
I'd choose Java over Kotlin. The benefits of Kotlin seem minor - mostly syntactic sugar - and the tooling is more limited than Java. They seem to solve problems with kludges (like their coroutines are really just state machines in JVM bytecode, which creates issues like irreducible control-flow) rather than properly engineering solutions like Java try to do.
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.
It's way more than terse classes. The syntax everywhere is cleaner. Higher order functions look so much nicer. Using val/var is superior to having to remember to write 'final' all the time. Kotlin also handles nullability way better. Ah, also, default arguments for constructors/methods. These features prevent a lot of developer mistakes, and thus better code is often achieved.
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's only improvement over Java were its scope functions, that alone would be an overwhelmingly good reason to migrate. Scope functions are awesome, cannot stress that enough.
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.
Kotlin fixes just trivial things - like nullability for example. Java still doesn't have a good solution, only about 5 bad ones and nothing is in sight. It even looks like Java designers simply don't consider it a problem anymore ...
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).
Not at all, because Kotlin wants to take it all, so they need to make the choice if they want to expose JVM features, or keep the language portable across all platforms that JetBrains wants to target with Kotlin.
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.
This is not always the case. One example is checked exceptions which are purely Java thing and do not exist in JVM (outside of metadata). That always amused me, it's like a switch to remove checked exceptions from language, you can turn it any time without backward compatibility issues.
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.
You're correct but you're forgetting that the jvm IS java. When it isn't trivial to solve at the language level they have the power to change the runtime.
And on top of that Kotlin is now basically stuck with async-await forever. Removing async-await from the language and designing a more superior model the JVM now allows for with Loom is probably not going to happen. Adding a new model based on the new possibilities Loom provides will probably cause too much fragmentation (unless they come up with some really clever interop) so thats also unlikely.
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.
Life experience of seeing guest languages come and go, during the last 30 years, and never succeeding in the goal to replace platform languages.
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.
Entirely replacing estabilished languages doesn't really ever happen, it's just the nature of the game.
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.
Scala, Clojure, and Groovy are all mature languages that haven't gone anywhere. No one has a goal of replacing Java, and they all benefit from improvements to the JVM.
Of the JVM languages, AFAIK only Kotlin is making a serious push to get off the JVM using something like LLVM. Interesting idea, though I wonder how long they can preserve compatibility between JVM and native targets.
Scala native doesn't feel like it has the same impact, perhaps in part due to a lack of momentum (as I perceive it).
It does, but not in the same platform-antagonistic way. Clojure instead embraces many different platforms and runs on them through various dialects; Kotlin wants to become a platform.
Other than Android, where Google is pushing Kotlin no matter what, I would use the platform's official language, Java.
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.
You can't go wrong with either choice. Both languages are mature enough to be used in production. I, personally, would use Java, but that's just my preference.
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.
I'm doing a kotlin project. You won't find it hard or unfamiliar if you're used to Java. You still got gradle, and you still can use whatever java lib you want. It just feels much nicer in kotlin. Just jump into it, you can swap back if it doesn't suit you.
I've been using Kotlin in the backend since 1.0 (4 years now??) and it's great, but it does have a few small annoyances. We still have most of our codebase in Java and routinely, we create new Java code instead of Kotlin for everything, interestingly enough (mostly because when a module is already written in Java, it's mostly a source of confusion to add a few Kotlin files - so we tend to only use Kotlin when creating new modules that are fully Kotlin). Also, some of our developers just don't seem to have enough abstraction power for the higher level of code you can write in Kotlin (specially when you start using things like Kotlin builders to make code "prettier", or just abust a little bit the "everything is an expression" feature to completely avoid separete statements - e.g. functions without braces).
I've been writing Kotlin professionally for the past 2 years. I'd highly recommend it as a worthy successor to Java. It's very powerful and thoughtfully designed. Java just feels so old and clunky after using it.
I've not had the pleasure but I hear Scala is great too.
I don't know why you are replying with this like some kind of gotcha...
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.
Syntax sugar on the JVM, as it is never to be more than a blip on the Java Virtual Machine.
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.
I have no idea about any politics involved, but Kotlin is a really well designed language. Fixing Java piecemeal as has happened so far just seems like an impossible task, while the JVM is flexible enough to support it.
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.
The JVM is just a detail, as a language designer, an utterly boring one. Who cares if your language is running on that or via native compilation. In fact, after seeing what happened at Microsoft with UwP, I’ll take convenience over ahead of time compilation any day.
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.
Languages without platforms fade away, history is full of examples.
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.
Kotlin outside of Android is still a fancy new thing. I am not commenting on its capability but the trend.
(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).
Try it out! I’ve been building with Java for about 13 years and just started playing around with Kotlin last year, and I must say that I fell in love immediately.
I would, main reason being calling Java from Kotlin is seamless. It makes most things easier by being expression oriented and having less verbose yet familiar syntax also saner type system. So you can just use it as better Java.
If you want to go further you can also use other nice features like suspend functions, hot/cold channels, sealed classes.
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
I like Scala but it's pretty complicated. I'm hoping Kotlin might be just approachable enough for the masses that we can drop the boilerplate that Java still requires.
Kotlin is like Scala (more ergonomic and with immutable collections in the standard library), but without implicits and with Java's weaker type system. It also has more compilation targets than Java (js, llvm, jvm).
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.
I understand that side (and I'm personally against Google's behavior, hegemony and influence on almost everything). But Google is one of the few companies that gives back to projects they use. You can't say that of many other companies that use tools and make sure they never contribute back (either financially or as code). As long as they don't put their adcrap in any of those languages or the things around them...
I'm not sure why the victim complex about Apple in your comment, he said too few companies do it and that remains true whether or not Apple is in that group. In fact that conversation has nothing to do with Apple.
> I'm not sure why the victim complex about Apple in your comment, he said too few companies do it
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.
Google is highly invested Kotlin and it’s success with Android and what I’m certain is the fact that they have huge Java code adds that I could see them having real value in slowly converting to kotlin and allowing Kotlin to be the first class choice where Java would be.
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.
I can understand caution and concern and it’s healthy to have it.
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
Kotlin is not a community led project. It has always been a Jetbrains led project, and that move to a foundation is a way to try to distribute responsibilities a bit more. At least thats how they sell it.
This isn't actually true. KHTML is LGPL 2.0, so you can release source code for the pieces you modified and binary blobs for the rest. WebKit proper (as opposed to WebCore, which was based on KHTML, and JavaScriptCore, which was based on KJS) was originally not open source.
I agree with your general Google paranoia, but in this case I'm okay with it since Google is easily the number 1 user of Kotlin thanks to its roll in making Android development infinitely more productive.
> well Google's using all three in different ways...
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.
If you mean by dedicating workforce (which costs money, and a lot for them because of their salaries policies) they are buying a seat? Yes. The same way a major contributor (not just code, but doc, funding, community building...) to a FOSS project often has more power on the decisions than users.
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.
The foundation was created as a project of the core team. Nobody was a "special guest." All parties agreed to the terms. That's what the founders of an organization does.
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?
Right, but the structure is a secondary concern, in that you're concerned about the structure because it enables particular actions. What kind of vote are you worried about?
Okay. I still don’t understand specifically what your concern is. I would love to understand, but I’ll drop it. Given the scope of the foundation and what it is and is not in charge of, I find this attitude very confusing.
Well Google does run and control the largest Java platform in the world by far. I think it would be a good thing to have them on your side when you are developing a language that interoperate with Java.
I’ve used Kotlin on Server Side in production at a pretty significant scale and I think it’s the most underrated thing for people using JVM on servers. I recently had a podcast with one of Spring dev advocates (Josh Long) https://spring.io/blog/2021/02/11/a-bootiful-podcast-doordas... (shameless plug) and brought similar discussion to table. I will seriously urge folks to try it and hopefully foundation will bring more goodness!
We used it for 1 year. Using spring boot framework.
Unfortunately we had to ditch it.
Issues with multi annotation support. Problems with instant run / partial compile. Slower performance. This was about a year ago. Maybe things have been improved. But we also noted that many outstanding bugs were ignored by the main devs behind kotlin. Did not feel like a mature language. At least not now.
We've been using it since 1.0 and I agree with you that there's many rough edges... many projects may never run into them, but like you, we did have these issues you mention... slower performance by the compiler and IDE are very, very noticeable on a large Kotlin project (at runtime, we haven't had many issues - there's only a few cases Kotlin is slower than Java, but you can keep those in mind and avoid them when necessary[1])... one more issue is Dokka (the equivalent to Javadocs for Kotlin). It's still in alpha and it's pretty terrible, if I may say... it generates documentation that requires lots of JS libraries to run, which is just ridiculous. We ended up writing the documentation conversion ourselves instead of using Dokka (this was actually for an Android project - because we hadn't needed to publish docs for backend Kotlin before).
That said: we still enjoy using Kotlin, I just wouldn't ditch Java for it if I had to pick one.
Have only used Kotlin with Spring Boot for server side REST api and the resulting code was, a lot of the time, very un-digestable. Quite ugly to the eyes.
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.
Just to update any1. I gave Ktor a shot. Tried to do something very basic - consume a URL. Was using Scratch files in IntelliJ.
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.
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.
I’ve only ever used Kotlin for competitive programming, but I must say there is no other language that I get so much joy from using. I’m serious, Kotlin makes me happy.
But, I have been worried about it’s future. I hope this helps make sure it has a future.
Any thoughts on if we are seeing the beginnings of a JetBrains acquisition from Google? There seem to be significant overlap between the JetBrains investments (people capital, intellectual property: IDE, language) and Google significantly using all of these things.
Jetbrains has a order of magnitude better internal culture that Google so I hope that never happen.
JetBrains is one of the few NO bullshit company that continually refine it's products for improving the user experience.
It is highly unlikely (I hope I'm not wrong). The way Jetbrains is financed and managed, they don't need that and they don't have pressure from any venture capitalists to go anywhere near that. That would also really likely harm their reputation really badly (but I said that of github as well and it was not as bad as I feared, so don't believe everything/anything I say).
Kotlin is definitely already taken seriously outside of Android. Anecdotally most of the devs I talk to in the web dev world see it as a possible replacement for Ruby/Node.
Neither does KMM, as it only allows for business logic and Kotlin/Native has an incompatible memory model with the JVM ecosystem, requiring code to be explicitly written for Kotlin/Native.
Both iOS and Android use garbage collected memory. It's just that iOS uses simpler garbage collection in the form of ARC. KMM code runs fine on JVM right? If you start from JVM code, yeah it needs to be rewritten, but that's not the premise.
Tried Kotlin, honestly I was not impressed. Tools (maven/gradle) wasn't as straight forward to setup as one would have expected. I am not impressed with the language itself and I had issue with conflicting libraries and kotlin versions.
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.
Kotlin has already pretty much replaced Java for Android devs. I see it doing something similar to Java use more generally (albeit more slowly than it did with Android).
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.
Kotlin is my go-to general purpose language these days.
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.
Closed by default/final by default is a bad bad decision that reeks of premature optimization. No I don’t want to litter my code with “open” just to allow it to be extensible. Makes Kotlin a non-starters for me.
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 is slowly getting in the industry as well. But really comparing Rust and Java (meaning the JVM, its languages and all the libs and tools) is not fair. They have different targets and respond to different needs. Of course, like everything, there are problems where their capabilities overlap and they would both work really well. But I have trouble believing this "new language that will rule them all" idea. We didn't really see that happen anywhere (or maybe we did and I'm missing an example of that).
Kotlin is meaningless outside Android development.
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.
Rust will never take over the enterprise market from Java or Kotlin. It is a language for completely different use cases. I it more of a competitor to C++.
Kotlin on the server is growing in popularity and ecosystem, just a week ago Netflix open sourced a new Graphql client.
Also Pivotal (the company behind Spring boot) is investing a lot in Kotlin.
To have tried many language on the server, Kotlin is a gift and has made me as a developer both more productive and happier! It truly is a state of the art language in ergonomics that everybody should give a try
I don't think any of these language efforts went anywhere near the support Kotlin now has in Spring. Doesn't mean it will not fail, but it is already further than any other..
Sure they were, Pivotal was screaming across all winds on Java conferences, just like they are doing nowadays with Kotlin.
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.
I remember many years ago when Pivotal's website was featuring a module for Spring Scala saying something about concise API and other functional buzzwords. The same for Groovy, earlier.
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...
[2] https://en.wikipedia.org/wiki/WHATWG
[3] https://news.ycombinator.com/item?id=26121937