Apparently they refuse to support the most popular web IDE because Kotlin for JS is really about selling IDEA licenses. Fair enough, but it means I don't suggest Kotlin for anything except as a Java alternative and Android.
There's better options from companies that are less adversarial to their community.
If I'm understanding correctly, the thing you found offensive in that comment was the JetBrains employee talking about "dragging" people to IDEA. If that's the case, it's important to note that the notion was first suggested by the OP:
> This would not only be beneficial to developers using this editor, but could drag a lot of developers to IDEA when seeking out for a full-blown IDE eventually.
In this context, the JetBrains employee was not saying "it won't sell licenses and therefore we won't do it", they were saying "this won't do what you think it will do".
JetBrains is a company, and like any other company their focus will tend to lean toward where the money is. But my experience with Kotlin over the last several years is that JetBrains is very responsive to the community and their needs.
Obligatory mention whenever anyone dicusses Sun's true motives for creating Java [1,2]. Sun's motives were anything but tidy. On Patrick Naughton's account, Sun's executive decision-making seems quite haphazard and opportunistic. Draw your own conclusions about the vagaries of individual perspectives or how typical this is of executive decision-making in general.
A line that might become amusing when you read the whole account:
> Thus began a long line of sporadic interjections by Bill [Joy| where he was right. He usually is.
Sun created Java to go against Microsoft, that isn't the discussion on the table, rather Kotlin and it being a guest language on the JVM, with a community that usually bashes the platform that made Kotlin possible to start with
It sounds like you are trying to find differences where there are none.
It also looks like you're forgetting that Java has been for years (decades) owned by Oracle, which is renowned for taking very public legal fights to milk Java to the extreme.
Nah, that is Kotlin fanbase trying to move goalposts.
Java has been owned by Sun, and then Oracle, and it was more closed source during Sun's stewardship than Oracle's.
The first lawsuit was done by Sun against Microsoft, and they only missed the one against Google, because they were out of money by them.
Unfortunately Google got away with screwing up Sun, not happy with that, they keep using they flavoured Android Java when selling Kotlin's push into the ecosystem.
Still in all these years, Java was never used to sell Netbeans commercial licenses, regardless of how you to try to change the music.
> Still in all these years, Java was never used to sell Netbeans commercial licenses (...)
But that's completely irrelevant, isn't it? Cherry-picking aside, don't you understand how loss leaders work, and how companies use that strategy to push the sale of their cash cows?
But Sun did invest in the creation and development of Java for the financial benefit of Sun. Jetbrains invested in Kotlin for the financial benefit of Jetbrains.
> JetBrains wants to be like Borland, and like Borland is now getting beyond themselves and better not trip over.
I don't understand what Borland's history has to do with JetBrains' decision to invest their resources on adding support for a programming language to a third-party text editor.
Sounds like a non-sequitur of an unwarranted cheap shot that adds nothing to the discussion besides noise.
Touch grass. JetBrains is trying to be like Borland in the sense that JetBrains is doing with Kotlin what Borland did with Delphi. Create their own all-in-one-place programming ecosystem. You can see it slowly coalescing.
C# and .Net was for a very long time a Windows only thing, they were created to fight against Java so Microsoft can keep selling Windows licenses.
IMO this Microsoft stupidity to not open source .Net and FUD the open source alternatives costed them and the entire dev community a lot, we would have a good alternative for cross platform high level languages with a big framework (as alternative to JS+node+electron+npm+framewoks)
Sure, but they linked a good dev platform with an OS, this prevented .Net to become a much more used platform because most developers developed for Linux server using anything else then .Net (java,PHP,Python or the super shitty at that time JS and node). The open source community might have implemented an open alternative but only some parts of the language and platforms were open and there was a lot of fear that Mono that implemented some non open API could be a liability.
I personally was a big fan of C# and I can't forgive MS stupidity , because of the Windows Team a good language and platform was sabotaged, as I said it could have been a worthy competitor to JS/node especially in the past when JS was shit and even now where npm is filled with leftPads and colorRed packages.
I only done desktop .Net apps so I can't judge, but even if I love the language and the standard library in .Net I would never had considered using it on a server if I had a choice, not because of quality but because of Microsoft bad treatment of the licenses an, the FUD and how they handled it. They managed to drag this platform down that js and node has probably more users and mind-share, they even had to "port "C#" and create TypeScript.
Btw, i did not implied anything about node or npm quality, someone that worked with both seriously in recent years might add their thoughts (so I am not a node fan just a C# lower disappointed on MS behavior).
Kotlin wasn't created to sell intelliJ, it had been the dominance IDE long before Kotlin inception. You found an article that happens to have that wording, that fits you hatred for some programming language. So you parroted the same argument all over this thread. Get a life.
C# was created in response to Java to keep developers in the Microsoft ecosystem.
Its effectivly the same thing, even though Microsofts goal wasn't selling visual studio, because they've got a much more lucrative cash cow: an operating system
The motivation behind c# was keeping people in the Microsoft ecosystem. Wherever they attempted to use a rebranded jvm before that is entirely besides the point
Or use it, and accept that the language support is about as good as it usually is for Emacs? Emacs has never had the full range of features an IDE has.
That's another reason why I don't like programming languages that need a specialized IDE. PLs should be simple. Not being able to use a language efficiently in any editor of your choice is like working with a programming language that needs specialized proprietary hardware to compile.
From 2011. I think their motivations have expanded quite a bit in the past 11 years, as has their commitment to the language, compilation targets and use cases.
Ironically that blog posts mentioned they created kotlin to not accept compromises in terms of compilation speed. I have found kotlinc's performance to be really bad
Does the LSP implementation [1] linked by the JetBrains employee in that thread not work? It pushed a new minor version release a little over a week ago.
It seems pretty reasonable to me for them to not pay employee salaries to build a plugin for a competing product, especially when they already provide a comprehensive IDE solution available for free (in both senses). What other companies are doing that? I don't mean that as a challenge. I'd love to know what the better options are.
What you said would make sense, except they do build a plugin for Eclipse.
Better options would be any language where the stewards are not trying to extract money from you by forcing your IDE choice. Or where they view fostering community good will as being in their best interest. Ex. MS offers an official LS rather than saying "we don't support other IDEs because Visual Studio licenses."
> What you said would make sense, except they do build a plugin for Eclipse.
I don't know a single person who used Eclipse after 2020. Don't you think that supporting Eclipse might be a viable marketing strategy to get people who are stuck in the past on board with newer tech, as if anything, they will probably move on to IDEA?
> Ex. MS offers an official LS rather than saying "we don't support other IDEs because Visual Studio licenses."
MS is a bad example because they recently literally took away a feature from dotnet to push it into VS and drive sales, which was met a HUGE backlash from the community. Dotnet IS the driving force behind Visual Studio. JetBrains actually came in and took a piece of that from them(thankfully, because I personally hate vs/vscode).
Like other answer to your comment said, JetBrains doesn't owe anything to anyone. If there is already a Language Server for Kotlin, great, I don't see how a product-based company could benefit from making something that drives people away from their (already free) product...
> I don't know a single person who used Eclipse after 2020.
So your circle of acquaintances doesn't include anyone who used an IDE in the past year, and you extrapolate your personal anecdote how far?
> Don't you think that supporting Eclipse might be a viable marketing strategy to get people who are stuck in the past (...)
Can we spend a minute discussing how idiotic is this fad-drive development belief? I mean, why is anyone expected to be perceived as smart if they drop something that works in favour of an unproven tool just because it's new?
That’s a fair statement but given that IntelliJ is over 20 years and the IDE of choice for many, if not most, professional Java engineers, it doesn’t apply here.
> (...) and the IDE of choice for many, if not most, professional Java engineers (...)
The same baseless assertion can be made regarding Eclipse, and it would be less doubtful given Eclipse's FLOSS nature.
Again, can we spend a minute discussing how idiotic is this fad-drive development belief? It's weird how, unlike in any engineering field, there's this cargo cult faith that new and untested is automatically better than old and reliable,and anyone who hasn't mindlessly jumped into a bandwagon is somehow the fool in the story.
> I don't know a single person who used Eclipse after 2020.
What happened in 2020? Did I miss the end of the world?
In my bubble, Eclipse : IDEA is about 50:50, and luckily it doesn't matter because of Maven. I am one of those Eclipse users, and I am still waiting for someone to show me a feature that IDEA has and Eclipse doesn't. From my perspective it seems like the same thing, with different aesthetics (e.g. whether you can open multiple projects in the same window, or you need different windows) and keyboard shortcuts (which can be redefined on either side).
So I wouldn't try to convert people to Eclipse, but I also see no reason to convert to IDEA. I have a tool that works and does everything I need, and that makes me happy. Show me a functionality I am missing, and I may change my mind (some people already tried, and then it turned out that Eclipse had that, too); otherwise I am not interested in novelty for novelty's sake.
Uhm, I am not developing for Android. There, I imagine the situation may be quite different.
Mixed language projects is something that only IntelliJ can really do. It’s actually the reason I switched over to it from VsCode for Java since we mix Scala in our project.
I'm curious, how do you see this as being adversarial to their community? It's not like they are taking down kotlin language servers, there are community language servers and extensions for kotlin in vscode and they're linked here as well, by jetbrains employees.
They need users to pay for IDEA to survive, so being open about not wanting to spend developer time to make it easier for people not to use IDEA that could be used to make IDEA better seems sensible from a business perspective. Seems like the community stepped up regardless.
on the contrary, I found their response very fair and reasonable. Quoting:
You can code Kotlin on any device, using any IDE, anywhere, at any time, thanks to the fact that Kotlin source code is stored in plain text files and not in a proprietary binary format. You do have a language server for that. The language server happens to be not developed by JetBrains, but it doesn’t actually restrict you from being able to use it in any way.
In my book, “lock-in” means “you have to pay a single vendor or you can’t use the tool”. You seem to be defining it as “you have pay the vendor or live with maybe slightly worse code completion and no refactorings, until someone else supports these features in a free tool”. I don’t believe your definition to be justified.
For me, it has basically nothing to do with being open source. Despite all the constant hate about electron apps, I've consistently found VS Code to be much snappier to use than any time I've tried using Jetbrains IDEs (whether on beefy desktop or slimmer laptop), and that's even after disabling a huge number of plugins and features that I don't want. That's not even talking about the actual features of each; I think I just prefer a smaller initial feature set with a rich, well-supported ecosystem of third-party as well as first-party plugins rather than a huge default feature set (which inevitable comes with a bunch of things I don't want) and third-party plugins being mostly an afterthought.
> Despite all the constant hate about electron apps, I've consistently found VS Code to be much snappier to use than any time I've tried using Jetbrains IDEs (whether on beefy desktop or slimmer laptop), and that's even after disabling a huge number of plugins and features that I don't want.
I use both vscose and intellij, and I must say that even though vscode can sometimes feel snappier without any plugin running, it's missing a whole lot of features even with dedicated Microsoft plugins running, to the point it feels half-baked. I'm talking about things like basic refactoring support and even symbol recognition.
IDEs like intellij and Clion may have slightly longer startup times, but that doesn't really matter as you're only going to start the app a few times throughout the day.
Ultimately vscode is nice if all you want to do is open text files and Run regex searches, but the minute you want to run the most basic refactoring steps then it's faster and less frustrating to just start intellij, refactor, save files, and quit the app.
I think this probably depends at lot on language. I mostly code in Rust, and for a simple example of one of the "most basic refactoring steps", renaming a type/function/variable/etc. and updating all the uses work quite well using rust-analyzer. I'm not doubting that Intellij might have a lot of nice refactoring features that VS Code doesn't, but I'm definitely able to do a lot more than just regex searches.
Just my experience at work (I don't intend to change your mind or invalidate your opinions) I can see from reading code what IDE the developer used, this is because I investigate bugs and I see trivial JS bugs that Intellij highlights but the author used VS Code and an avoidable bug was put in. Intellij is slower because it actually parses your project and dependencies and even with a dynamic language as JS it can infer many types and show you the error.
Same here. Open a JS project in a Jetbrains IDE and things start going red all over the place. Asking the JS devs about it, they're like "oh we didn't us TS on that file" or "oh yeah we know about that, just ignore it". And the best one "oh yeah, that's a bug, we haven't finished that part yet."
Honestly happens with python devs too when you open their project or code in a "real" IDE that checks for all these things.
We hate electron apps because native apps are much faster
But Java/Kotlin is not native. Before electron, we hated Java apps because native apps are much faster
I develop in Pascal and Kotlin. When I had a laptop without SSD, Jetbrains IDE would take almost 30 minutes to start, while the Pascal native IDE could start in 30 seconds.
Yep. Lately, it seems like a lot of people think “native” means “not web technologies”. Way to many people think that Jetbrains apps are native because they are written in Java.
Yeah, I briefly tried using nvim for csharp dev and discovered that even though csharp lsp is open source, the razor lsp integration is not (or was not at the time) and the vscode plugin downloads some proprietary binary.
But the "proprietary crap" part is where they've implemented all of the Python support, among other things, isn't it? And last time I looked the license prohibited using Microsoft's proprietary plugins with VS Codium.
The Python extension is open source but Pylance isn't. Use Pyright (type checking ext which is essentially Pylance without the ML stuff) instead of Pylance.
Instead of Microsoft's C/C++ extension use clangd.
Remote SSH and Remote Containers have alternatives as well but nothing as good.
Google and Red Hat's extensions work out of the box along with several thousand other extensions.
It's fine to prefer M$ lock in to other lock in. I just take issue with blaming Jetbrains for lock-in while at the same time praising VScode which also has lock in.
OP is referring to some of Microsoft's intellisense language plugins. They are not bundled with VS code by default but they are the best-in-class in terms of language support for autocompletion.
IMO Fleet¹ from JetBrains is their answer to VSC, and hence it doesn't make sense for them to invest in VSC. What people are arguing for is the difference between the interests of JetBrains vs the interests of Kotlin, very similar to the kinds of conversations that went on for early Rust governance.
Programmers spend an inordinate amount of time thinking about languages and tools, but don't want to pay for better ones, even when they are extremely cheap, drastically increase their productivity and save many headaches. Every other week, there is a post on HN complaining about funding open source. One of the few languages offering halfway decent tooling support is bad because... it makes users more dependent on tools? This makes no sense. Same story for Wolfram. If you want nice things, pay for them.
It doesn't have anything to do with price. The point is that I've invested a lot of time knowing my IDE (vscode) very well. Switching IDEs on the basis of a language which I've never used is a huge leap. You could make that leap a lot easier by allowing me to use it somewhere I'm comfortable first.
As others have mentioned in this thread, you are absolutely allowed to write Kotlin in VSCode! There is a perfectly good VSCode extension [1] for it. You may not receive the same extensive support that IntelliJ IDEA provides, but as Kotlin developer who occasionally writes in VSCode, I find it's decently usable. Once you're familiar with the command line, you'll probably be more productive running Gradle commands than fiddling with buttons and UI widgets anyway.
Seems like a no brainer - who wouldn’t want to use an awesome language like Kotlin and have it shared across iOS, Android and Frontend?
However, the actual experience is full of sharp corners. Get ready for nonexistent documentation, hacky plugins, poor debugging support, lack of proper native libraries and head spinning errors.
In general, it feels like doing carpentry using your plumber’s tools.
I use Kotlin without a license. Just the community version of the IDE, they also released an eclipse plugin that is currently unmaintained. But still open source. I think they did their best to help but without hurting their business model.
Groovy has no Netbeans support anymore. Who is to blame. Groovy? Groovy is better as a PL than Kotlin. But Kotlin is no match in terms of performance and pragmatism. I use both instead of Java and I never looked back.
Can you elaborate on why you think it’s terrible to read in plaintext compared to other languages? I’ve been writing a lot of Kotlin recently and the only memorable extra hints (compared to other languages/IDEs) I see on IDEA are named parameters, smart casts, and the type of `it`/`this`. Sometimes I browse GitHub from my phone and I find Kotlin code very easy to read.
Huh? Kotlin code tends to be very compact, often functional, and immutable and non-nullable variables (both by default) severely reduce cognitive load when reading code.
> If it wasn't for Google giving wind to their sails, the Kotlin ship wouldn't have gone anywhere.
I disagree. While the Google announcement to officially support Kotlin surely gave it a big boost, Kotlin was already in widespread use for Android development well before Google announced their support for it in May 2017. Additionally, it was also gaining traction for server side development since before the Google announcement. I had been evaluating Kotlin closely during this time, and made the decision to start using Kotlin in our (primarily Java and entirely server-side) company codebase in late 2016 because I was already convinced Kotlin had a bright future. We weren't the only ones who thought this, I was tracking multiple other companies in our space (financial tech) that were evaluating and/or already moving to it too.
Kotlin is gaining momentum outside of Android, which is the only platform that Google helped with. In other areas, like Flutter, Google is actually competing with Kotlin (KMM).
So Kotlin is already more popular than Scala and now the most used JVM language except Java itself, and is used almost as much as Java 12, 13, 14, 15, 16, 17 and 18 combined. Not sure you should be that dismissive..
You have poor reading comprehension (in addition to a real hatred for one particular language, which seems unhealthy). I never stated that it was among the most popular languages, just that it was gaining momentum.
In 2019, 41% of Kotlin devs claimed to work on web back-ends. In 2020 it was 47%. In 2021 the survey changed wording but "server-side development" had increased to 52% of Kotlin devs.
sorry that's not it, Kotlin was created as a better Java, and is growing out of that niche. If it wasn't for Android, Kotlin is still a good back end language, especially with so much JVM stuff that isn't going anywhere soon out there.
> If it wasn't for Android, Kotlin is still a good back end language
It certainly would. Like so many other JVM languages. Android is what makes kotlin stand out from that crowd.
Arguably "particularly well supported by IntelliJ" is another thing that makes kotlin stand out from the crowd, but that's a two-edged sword. I'd expect the average JVM person to see that as roughly a tie between a quality and a cost (more lock-in).
I don't see any alternative JVM language competing with Kotlin right now to even have options. Scala 3 is in a very different space. Before Kotlin 1, scala 3 was no where near release. I remember eclipse X10, which was like a "transpiler for java" but it wasn't as ambitious as Kotlin with multiplatform planned.
We use Kotlin JS in production and like it quite well. It enabled us to easily share code with the Kotlin backend and Typescript frontend. Kotlin also generates Typescript type definitions which enables us to easily call those Kotlin methods from typescript. The multiplatform vision allows us to compile/share natively code for mobile platforms too.
I also love to see the quickly evolving Jetpack Compose which would enable to write natively executed UI code on most major platforms. (iOS is not there yet and likely depends on new memory model which is currently being developed.)
Same here. To be fair, it has some rough edges as it is still a bit cutting edge. But it mostly works great. Worth a look if you need to share code between IOS, Android, Web, and server side.
We use the Fritz2 ui framework which has been built from the ground up with Kotlin-js. It's a reactive framework desigbed around Kotlin features like co-routines and flows. It comes with a nice component framework, great documentation, and has been rock solid for us. Worth a look if you are looking for something different.
We took some risk by betting on this admittedly risky setup one and a half years ago when I had a few junior Android developers that knew Kotlin and we needed a webapp in a hurry. I ran this as an experiment for a few weeks and then realized that I had nothing to worry about: it's fine. We were hitting all our goals. By now we are super productive with this setup and we are adding lots of features, ui polish, etc. every week. Maybe we'll have to switch at some point but so far we're good on not ending up with the usual mess of technical debt that I've come to associate with javascript projects.
Jetpack Compose looks promising. Once IOS support lands, it will be a strong competitor to Flutter and React Native. If you can do without IOS support, it's usable right now. I'm guessing IOS support would be at least another one or two years out.
Multiplatform is great and getting more usable with every release. We have an API client and some other functionality that we use across JVM on our server and kotlin-js. It should just work for kotlin native, IOS, and android as well but we have not used that so far. I'm kind of looking forward to the web assembly compiler becoming usable as well.
One of our lead developers at work pushed this for a rush demo job last week (he’s a Kotlin advocate). He spent the week fighting with lack of documentation and has now given up and reverted to plain old javascript.
Late last year we had some major instability with our main microservices as they didn't properly scale and it wasn't pleasant. The backend codebase was Java. In any case 2 months before that we got a dev with good Kotlin experience (he wrote a book on it) and he offered to rewrite those services in Kotlin as that instability was occurring. It took him about 5 days for each (sometimes less). And in a few weeks we had services which were rock solid. Amazing really how sometimes a person who knows his stuff can make a difference.
How does Kotlin "scale" differently than Java? I mean I'm anything but a Java fan but both languages run on the JVM, so unless your colleague also changed the architecture of those services I don't see how a switch from Java to Kotlin would help at all.
My guess he implemented those using Kotlin Coroutines to build much more scalable and more thread safe implementations. Concepts it offers like Structured concurrency are really powerful.
True, Coroutines were very heavily used. It was kind of magical how services which nobody wanted to touch with a 10 ft pole due to their complexity for almost years got rewritten in mere days or weeks at most. Those big microservices were broken down to even smaller microservices.
That is interesting. I'm not against compiler enforced null checking, but it's not the killer feature that would convince me to switch to Kotlin from Java.
Your mileage may vary, but for me it's crucial—I can't use a language in production that doesn't have null safety. I want the compiler to force me to consider edge cases, and in many languages the biggest edge case of all is "that value you thought was there isn't actually there".
Did he report the issues back to the Kotlin JS team? My experience is that they are quick to respond in Kotlin Slack.
We use it in production and saves us quite some time sharing code with the backend.
I can imagine Kotlin JS takes some effort since it improved a lot but also changed quite a bit throughout the years. Kotlin Slack helped me a lot through this phase.
No idea. I think the demo schedule drove him to find something that he could get working.
To be fair, I think he was fighting not just Kotlin JS but using React within it and his own lack of web technology experience being predominantly an Android dev.
Seb from Kotlin at JetBrains here; if your lead dev would like to help us improve the experience, feel free to reach out via the email in my profile. We are always keen to learn what obstacles are facing in their adoption of Kotlin/JS, and what we can do to help.
Maybe he could try again with Jetpack Compose for JS? Then he can use his Android knowledge for the UI and there is less complications with bridging Kotlin code in JS/typescript. To be fair though, Jetpack compose for web is quite new so there is not yet a big ecosystem.
It's really not that bad. I would start with downloading IDEA and then following the steps to select a Kotlin/Gradle project (make sure to select Kotlin Build Script) which will spit out a "Hello World" basic setup for you.
From there add a dependency by editing build.gradle.kts and you will be doing OK in no time.
Yeah, but I can not do that without a using the whole project template. Half of all the options in the build file mean nothing to me, much less why they’d need to be there in my starter project.
I don't buy that. The minimal project Gradle build script does exactly 4 things.
1. Enable the Kotlin Plugin
2. Set the package metadata (group and version)
3. Add Maven Central as a repository (equivalent of say npmjs.com)
4. Add the Kotlin Stdlib as a dependency.
You may have accidentally enabled extra stuff through the new project wizard which is admittedly more complex than it should be (especially if you are using IDEA Ultimate with many plugins enabled).
I suggest the following flow:
New Project -> Select Gradle on the side panel -> Check the Kotlin Build Script box -> Select only Kotlin/JVM.
This should set you up with a very minimal project with exactly 3 files (build.gradle.kts, gradle.properties, settings.gradle.kts).
From here you can either create a package i.e go for the src/main/kotlin/com/example/main.kt route or just create main.kt in the top level without a package.
> Java feels like I have to develop a whole program just to get my program to run.
Is this about the "pom.xml" files? In the simplest case, they just contain the name and version of the program, the version of Java you want to use, and the names and versions of the libraries you want to use. You would need to specify this somewhere in any language. And yes, sometimes it gets more complicated, if people want to do more complicated things. It's either this, or having a dialog somewhere in IDE that does the same.
People often overcomplicate things, but it usually doesn't need to be so. As an example of a simple Java code, see this: https://gitlab.com/kittenlord/image
This is a terrible suggestion. IntelliJ Community Edition is enormously powerful and more than sufficient for getting started with Kotlin. I've been coding in Kotlin for years and still don't have a reason to pay for IntelliJ (sorry JetBrains!)
Exactly, it's what I use currently for Kotlin frontend and backend development. I've also used the opensource community edition it for Java and Python development.
There are a few things that you would have to pay up for that might be worth the money depending on what you are doing. I think their C/C++ IDE (CLion) costs money for example and they have an alternative to XCode called AppCode that does not have a community edition. And they have a few other things that might be worth the cash.
But simple Kotlin development works great without that. Everything you need comes with the community edition. You do need a fast computer to run it. It's a resource hog.
Gradle and Maven are both a million times better than whatever constantly changing collection of random stuff you have to use to build a contemporary node project.
Nah. Gradle has its advantages but it's way more complex than building a node project. The Gradle DSL is utterly incomprehensible to anyone that isn't a seasoned Java dev. Honestly, I struggle to think of a language with a more complex build system than Gradle, besides building cpp apps.
Nah, Gradle is a fucking mess no matter what. If you don't absolutely understand the gradle life cycle, how to avoid task configuration, keeping everything lazy, avoid cross configuration, understand that buildSrc is shit, gradle will be hell.
Agreed. Maven is boring, but for most stuff it just works. Hard to customize, but before doing that, ask yourself why you're doing something different than millions of other projects. Go with the defaults and things will work.
Gradle feels to me like trying to set up a webpack project. Loads of magic configuration no one dares to touch after it happens to somewhat work correctly.
Let's not compare Maven to Gradle. One is a stable, rock-solid, decades old declarative build tool with reasonable performance and excellent backward compatibility - the other is a configuration, semantic and maintenance nightmare.
Gradle is a very very good build tool from an engineering perspective - it can seriously speed up compilation, is actually correct (maven sometimes need a clean install to be 100% sure it creates the actual things) and basically has every capability out there.
The only reason Gradle is faster is because it uses a daemon for build caching and leverage JVM code optimization.
Once you apply that same strategy to Maven, it actually tends to beat Gradle in performance too. See Maven Daemon: https://github.com/apache/maven-mvnd
And if you build from inside IntelliJ, I think it already does essentially the same thing (unless you tell it not to) by importing the Maven project into its internal build system and using a compiler daemon: https://www.jetbrains.com/help/idea/delegate-build-and-run-a...
You don't need anything to build a node.js app. If you use typescript then yes you'll want typescript, but honestly the experience out of the box in node is pretty fantastic that you don't need anything else, as far as build goes.
Granted if you are talking frontend browser code then sure webpack, but that tool has been around and stable for many years now.
Added bonus too is browser adoption is way better than ever so you don't really need a transpile either, typescript being the exception.
Not sure I agree. NPM as a technology is actually pretty decent and fast. The biggest issue is that package.json doesn't allow comments. Webpack is shit. But there are good alternatives to it now - primarily esbuild.
I'd take that build system over Java's dog slow build systems any day. Just a shame about the JS ecosystem itself. Too many badly written libraries not written in Typescript (inexcusable these days) with a gazillion dependencies.
There's a lot of garbage TypeScript libraries too. I think a lot of this just comes down to size. Smaller languages tend to focus together on maintaining and contributing just one package that does the thing. TypeScript and JavaScript as lowest common denominator languages for many scenarios means there's a lot more options for better and worse. What hurts both as well is they are multi-paradigm while the broader communities are general pushing very hard into a single paradigm which necessitates more libraries and ecosystems.
Loving FP and admiring `fp-ts`'s work, I can't help but think our communities would be better off doing FP in FP languages instead of writing unergonomic and idiomatic code to much of the splintered TypeScript community. Yet, we'll writing things this way because it feels like the correct way to do software, meanwhile a bootcamper would find it incomprehensible; this same person would find an FP language more approachable because there's only one way to code it.
How is Java’s build tool slow? The single frontend compile step is literally the slowest in a badly architected project we use, even though it goddamn deploys to wildfly!
Java literally compiles as fast as it gets, while npm chews through the same files multiple passes, and goddamn barely does anything yet takes eons of time.
Yeah, I have no idea what that person is talking about. I'm in the same situation as you; we can compile hundreds of thousands of lines of Java code in dozens of different jars in less time than it takes for one of our frontend javascript builds to run.
The problem isn’t necessarily the quality of gradle or maven but rather that you get one more build dependency, thus increasing complexity of the project.
Yup, gradle is a huge barrier to entry - esp. with the whole disparity between kotlin dsl and gradle dsl.
At its core, gradle as a task runner is pretty neat. But the layers of abstraction built upon it often make things superhard when you need to deviate from the setup offered by the starters.
While the official docs have started to show examples in both, almost always a stackoverflow answer or online blog post you find while googling is in the other dsl and converting between them is non-trivial.
All examples in the official docs (bar a few things like custom plugin development) are in Kotlin now. Also the support for the Kotlin build scripts in IDEA itself is a ton better now, it used to break all the time and desync etc but no more.
Gradle certainly isn't great but it's crappiness is overblown especially when comparing it to stuff like npm + webpack.
Kotlin/JS actually does work with Maven [1] – it's just all the MPP and Kotlin/Native stuff that is heavily Gradle-focused. I hope they eventually get to updating the Maven plugins once the multiplatform features stabilize.
Technically it might work but you are fighting an uphill battle in terms of documentation, stuff that's just not supported at all, bugs, etc. With Kotlin-js especially, I would strongly recommend to not bother with maven. It's a bit cutting edge and you'll have an easier time doing what everybody else is doing.
If you go the gradle route, of course use the Kotlin Script variety. Gradle is a bit complex and having your build logic written in Kotlin seems like it is the right thing to do.
> having your build logic written in Kotlin seems like it is the right thing to do
Yes, in the abstract it does, but the but way Gradle actually does that (evaluating different parts of the program in different special and magical ways) is extremely confusing. And I don't understand how it could possible require the vast amounts of memory it does.
Maven is horrifically verbose, but at least its model makes sense after learning a few key concepts and the IDE can help you work with that model without setting fire to the CPU.
IMHO maven is not something that is actively supported by many people using Kotlin. If it works at all, good for you. Otherwise, you are on your own. I'd advice against using that with Kotlin.
I have plenty of experience with maven and with ant before that. No project I've touched in the last six years used either of those other than a few conservative and, frankly, clueless/hopeless customers that I've helped out in some of my freelancing projects.
I don't get pedantic about persuading customers that maven is dead as a door nail but there is a pattern of behavior of mostly elderly (i.e. my age) slightly out of their depth CTOs insisting that maven is the way to do things because that's all they know.
I'm experienced enough to not fix what ain't broken. A build system either works or it doesn't. And it's not worth my hourly rate arguing against it. Anyway, it's not that hard to get them working regardless of what you use. I'm old enough to remember DOS batch files being an acceptable solution. Actually wasn't that hard to do either. I love bash shell scripts for the same reason.
People get hung up on build systems performing magic that they don't understand. Maven is mostly just a really convoluted way to compile Java code which isn't even all that hard when you understand what it does. Having done that with batch files I both appreciate what maven. gradle, etc. do and recognize that it doesn't matter much at all. Gradle does most of the same things as maven with less fuss. I'm still well capable doing the same with just bash and a compiler. But it's not worth my time. These days, I spend more time on figuring out github actions than on gradle. The stuff that gradle does is only a tiny part of the business of doing CI/CD these days. Gradle is the easy part.
I like how, last I checked anyway, there was no way to say "install this package" with Gradle; I had to go get the URL first. There might have been a way to do it after first manually adding a repository (maven central or whatever), but I couldn't figure it out quickly.
And then to upgrade to the latest I had to manually go figure out what the latest was, and manually change the line number to the latest version. I did see there's a separate plugin you can install to now add it though, built by a third party, but still.
I don't understand your first bit, "install this package" isn't a thing in the java world. There are just dependencies, you don't "install" them.
But this:
> And then to upgrade to the latest I had to manually go figure out what the latest was
Yeah, in the java world you write code against specific known dependency versions. That's why when you try to build it again in a couple months, it still works. I sure wish the JS community would learn this old trick.
NPM has had package locking since what feels like a million releases.
I wish the Java community (which I'm actually also a part of) would stop rejecting everything that's not "the Java/enterprise way" and be humbled by exploring better alternatives, or alternatives with different tradeoffs for once.
I think his point was more of a cultural difference. My IDE actually lints non pinned dependencies as a potential source of errors, whereas in the JS world it seems very common to not pin.
npm uses locks per default, and to disable that, you need to create a file called .npmrc at the root of the project and add package-lock=false to it. I don't think any popular project does that.
It's also a common practice to use npm ci in all build scripts to never update packages even if they declared a version range in package.json, and package.lock not being able to satisfy package.json won't cause lock to get overwritten.
The fact that npm ci does what npm i should do (well, except for starting from scratch each time [0]), says it all. npm is a joke.
[0] Yes, that's right. npm doesn't allow to to install incrementally respecting the lockfile. You can install incrementally with npm i and roll the dice, or install from scratch with npm ci to respect the lockfile. Basically the npm authors took the rm -rf node_modules/ workaround and productized it.
If you have a package.json and you run npm i it generates a package-lock.json from it.
If you run npm i against that package.json and package-lock.json, the latter will never be updated, even if the package.json would be happy with newer versions.
If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above.
But of course you may think this behavior is a joke, I do not.
How can I incrementally install exactly what’s in the lockfile, raising an error if it’s incompatible with package.json? This is what I expect npm i to do, but as far as I can tell, npm simply doesn’t support.
1) For local development, I’m seeking a command I can use after pulling, to safely and quickly install any needed dependencies that have been added by others. Currently I use npm ci but it’s absurdly overkill (and therefore very slow).
2) For CI itself. I cache node_modules/ across builds, which significantly speeds up my builds. Currently I npm i, and check if lockfile changed, and if it did, checkout lockfile and npm ci.
I shouldn’t need to npm ci ever unless my node_modules/ became corrupt for some reason. Because npm ci ALWAYS blows away node_modules/, it’s not a reasonable piece of everyday functionality, it’s just a semantically ambiguous way to rm -rf node_modules/ && npm i -—respect-lockfile (made up flag I wish existed). The obvious explanation is that the npm developers couldn’t figure out how to reliably reconcile node_modules/ with the lockfile, so just gave up and shipped npm ci.
Or if the rm -rf node_modules/ isn’t strictly necessary for npm ci, then give me npm ci —-skip-drop-node-modules, that would be equivalent and fine for my purposes.
I wish it were so simple. Maybe I’ve just been bit by too many bugs in npm over time, but I repeatedly see npm i change the lockfile when incrementally installing a new package that was correctly locked. Fortunately at least npm ci has always been reliable.
What do you mean ci is super fast? Is it intended to be caching the packages somewhere other than node_modules?
> I repeatedly see npm i change the lockfile when incrementally installing a new package that was correctly locked
There's been some bugs in the implementation but never had anything in the last few years, other than some people accidentally committing unapplied package.json changes, and built a precommit hook and a server-side check for that in many projects.
> What do you mean ci is super fast? Is it intended to be caching the packages somewhere other than node_modules?
Quality of the packages has been discussed to death, say about that anything you like, but npm has been rock-solid for me in the last few years. Definitely not a joke IMHO.
> Yeah, in the java world you write code against specific known dependency versions. That's why when you try to build it again in a couple months, it still works. I sure wish the JS community would learn this old trick.
I've been writing JS with npm locked to specific, exact versions of dependencies since 2014, IIRC.
Not everyone does this, obviously, but the tooling has been able to at least do a decent approximation of this for a long time (and I was and am very far from being a bleeding-edge adopter).
Okay - "Download and make this package available to my code", if that makes you feel better. "npm install (dependency name)" will 'download and make this package available to my code' from the NPM repository, for the current node project you're in. I can also specify custom repos to use, rather than NPM, if so desired. Gradle's default is "nah, go find the fully qualified URL package name and version number for me and paste it in the gradle build file for me, in the right location".
Once you do that in Node, the package lock will specify what version you've downloaded, to make it a repeatable build. You can tweak it to indicate you want to pin the version at a given levels, as well; that's done in one place, and separately from the package-lock file that gets generated, that tells you what -actually- is being used.
My follow up point is that when that version eventually goes stale, it's as simple as 'npm outdated' to determine if there's something more recent, and 'npm update' to update everything (based on whether you've pinned to a major/minor in your dependency list). You can also update specific packages with 'npm update (package name)'. I sure wish the Java community would learn this obvious 'trick' that every OS package manager enables. I know I want Jackson, say, I should be able to say "gradle install jackson" or whatever, and it would tell me all the options in the repo with jackson in the name. Then 'gradle install jackson com.fasterxml.jackson.core' and it would add that to my gradle file, with the most recent stable version. And 'gradle update jackson' would seek to update that dependency to the latest stable (with some syntax to pin the release, major, and maybe the full version, to enable 'gradle update' to update everything within a particularly defined scope).
> There are just dependencies, you don't "install" them
Pray tell me where the dependency comes from then? When I add a ‘This package requires dependency x at version y’ to my gradle/maven file, it doesn’t magically appear on my system.
Or rather, I think it does magically appear on my system, which is incredibly confusing.
The dependency comes from the list of repositories you provide. Even in nodejs you don't manually enter the full URL to an NPM package. You just yarn add node-ipc==10.1 and your tooling will figure it out on its own.
If you enable the general maven repository (the maven() you see at the top of many gradle build scripts), you'll get the code from maven. If you also add your personal repositories (which most people probably don't have), you'll get packages from there as well. I'm not sure how you add a second repository to node package managers, but I assume it's possible in some way without specifying the http download url.
The biggest difference between the two ways of package management in my opinion is that node packages are just a word or two and Java packages are a full com.example.product.service.package name. That's a lot better in my opinion as it distinguishes between projects much more easily. I thought node-ipc was related to the nodejs project, for example. Some nodejs packages use namespaces, but most don't.
Another difference is that nodejs has tons of tiny packages (I'll never get over how silly it is that is-odd and is-even appeared in my node folder by transitive dependencies) whereas the Java world generally uses huge packages almost exclusively. This leads to more boilerplate code (actually having to write simple functions like that yourself), but also to less dependencies that can break.
It downloads it into cache for the first time and uses it at compile time at every subsequent build? How is it magical?
Should it display ads instead and put random executables to my path? Or create a 1000000 file directory everywhere on which windows god damn chokes to open?
Could be! Given that I've been across multiple Java shops, including with people who have been in the Java ecosystem for decades now, and I've never had anyone point out how to do this, and in fact seen those self-same people work around these perceived limitations, I doubt it. But it's quite possible the functionality is there, just so buried no one knows about it. Certainly, I haven't seen a response, yours included, that explains how to do it.
Alright, I'll bite. With dependency management being 1) and the update flow being 2).
1.1) Gradle is a build system. As such it doesn't care where you are getting your dependencies. You can skip all public package repositories and only use your own private one or mix and match. Adding repositories is literally as easy as doing the following to your build.gradle file:
1.2) As has been mentioned in previous comments, you add dependencies to the project rather than install them in the system. Gradle then has various cache folders where these dependencies recide and will fetch those that it doesn't find locally (new libraries, new versions etc). This is akin to how most software defines its dependencies. Python's pip & requirements.txt, Flutter's pupspec.yaml etc.
1.3) Complaining about having to use a full resource identifier ('com.google.guava:guava:31.1-jre') for the dependency rather than just an alias ('guava:31.1-jre') for the package name simply sounds like complaining for the sake of it. What if a fork exists of guava ('my.forks:guava:31.1-jre'), how would that get used along side the original if dependencies are only defined by their project name?
2.1) In my books, package updating should be methodical processes where each and every update is made in isolation, thoroughly tested and then merged in. In that respect I find it very nice that the build system isn't constantly telling me about a new library version everytime it runs, as it pushes naive developers to upping all libraries to their latest versions immediatly and then scratch their heads when unexpected behaviour starts popping up all over the place.
2.2) Various IDE's have mechanisms for notifying visually about when a package has a new version available to them. There are also various tools available to check for package version statuses, such as the 'Gradle Version Plugin' just to name one. I use this plugin extensively to get information on stable dependency updates.
2.3) If you want to always use the latest version of a dependency, you have various mechanisms available to you. It is easy to declare if you want to always go for the latest major, minor og patch versions automatically. See 'https://docs.gradle.org/current/userguide/single_versions.ht...' for details. I'd hate to work an a project that had not clear version definition though as that would just signal very naive developers and/or sloppy practices (automatically going for latest patch versions is fine in my books).
I've found Gradle to be very straightforward, intuitive, and easy to use. I switched one of my projects from Maven over to Gradle, and coming from Maven XML, the Grade configuration language/DSL was amazing and a breath of fresh air.
I’m going to have to really disagree. While XML might be verbose, it’s dead simple and maven is extremely well documented. Gradle on the other hand is cryptic, relies on stack overflow to document it, and breaks your build scripts every release.
Maven to Gradle is a huge improvement, but I think a lot of people here are coming from the JS world. Package.json is incredibly simple compared to Gradle.
Disagree, maven to gradle is a downgrade. Yes, xml is boring, but it's still incredible simple, almost just a verbose package.json. And it's convention over configuration, if you do stuff like everyone else, it just works.
Gradle however, is a dsl in a language almost no java devs use. All gradle files are different, so copying an example from somewhere else probably won't work in your context etc.
Is it? Where does my special css file go, what option is valid in this context, do I need babel, or this other 1000 package? It does tell you something that literally every framework will generate you a file, while you can easily write your build script by hand for even large java projects.
My project is a programming language interpreted, and from the start it was written in multiplatform Kotlin. Then als to this it was trivial to create a web frontend where the entire implementation runs in the browser. All of this is done without a single line of Javascript, which helps in reducing the pain of web development.
The primary implementation is running on the JVM, but almost all code is also reusable in the web version.
It's all open source so anyone that is curious about how this looks like in an actual project is freelance to have a look here. https://kapdemo.dhsdevelopments.com
pron wrote an insightful comment on Kotlin’s future sometime ago, https://news.ycombinator.com/item?id=24197817. He has actively commented on Kotlin this past decade in good faith. The key quote:
> Kotlin's design goals are now contradictory. It seeks to be a low-overhead language, i.e. provide abstractions that don't add overhead over the target platform, give access to all platform capabilities, and at the same time target multiple platforms -- Java, Android, LLVM and JS -- over none of which does Kotlin exert much influence (maybe a bit on Android).
I agree with pron. I don’t see the longevity of the language outside of Android. Too much of drive to use Kotlin focuses on developer experience hype, which is great for starting projects but pretty bad for maintaining them a decade later.
It's well entrenched in server development. The notion that it is Android only is a myth. There are an enormous amount of Kotlin server developers out there. Speaking as someone who has done Java for 25 years and Spring/Spring boot for the last twelve years. The last five of which have been exclusively in Kotlin. I know this market. The Kotlin ecosystem outside of Android is huge. Every Java server framework that still matters supports Kotlin:
Spring, Quarkus, Javlin, Vert.x, etc. It's for a simple reason: Kotlin worked nicely with those frameworks before they even actively started supporting it and people used it for the same reason Android developers started using Kotlin. It's just way nicer to use than Java and there are no downsides to using Kotlin with a framework that is exclusively designed for Java. It just works. So several years ago, all those frameworks started adding Kotlin extension functions to their libraries and designing features specifically for Kotlin users.
Android developers got a little headstart on the transition to Kotlin for two reasons: 1) google had some issues with Oracle that caused the Android version of Java to be stuck on a version without lambda functions for quite some time 2) Android developers frequently end up doing greenfield projects and they'll grab whatever works when that happens. So, about seven years ago, Kotlin was a drop in replacement for Java on Android that had a lot of nice language features that Java simply did not have. Irresistable for Android developers stuck on the Java 5/6 feature set. Google upgraded the java language version used on the platform over time. But most of that happened after they endorsed Kotlin as the main language.
Something similar happened with Spring but just a lot slower. I used Kotlin with Spring 4.x already in 2018. It had absolutely zero kotlin support but it was a nice upgrade nonetheless. Just worked and added a lot of value (data classes, nullability, etc.). With Version 5.x they added a lot of Kotlin support and they've been iterating on that for the last four years.
Be that as it may, but a core benefit of kotlin (as a developer) is that it has actively sought out good design patterns (eg. builders, composition etc.) and codified them into the language. In Kotlin often the best approach is also the most succinct one - which doesn't hold true for most of the platform-native languages (swift probably being an exception).
As long as it keeps doing that, even at the cost of a larger API surface area (or occasional backward incompatibility), I (and I suspect many others) will be quite happy to use it.
I also agree with him, it is the same fate as all guest languages on platforms where they aren't part of the picture of the people driving the platform.
You see this in any platform, not only Java.
On Android there are some Google folks that pushed for it at the expense of updating Android Java to more modern versions, knowingly comparing Kotlin with their pseudo Java.
Actually I am quite surprised that Android 13 is actually going to support a Java 11 LTS (subset of course). Which although commendable that they are finally doing something, flies in the face of the latest version being Java 18, and they could at very least support the latest LTS version.
I (reluctantly) agree with pron as well. Kotlin's push to become a multi-platform language -- and escape the JVM -- has taken years, and seems far from 'production ready'. Unfortunately, the facets of Kotlin that most people use and care about like language design, ergonomics, Gradle, coroutines, etc., seem to have suffered as a result of this. In the beginning they were running laps around Java with functional and quality-of-life improvements; in recent years, they've kept up with Java (sealed interfaces, records) while adding a few improvements; Loom and pattern matching will be coming to Java in the near future, and I'm worried it will be a while until Kotlin catches up.
Records is what Java calls data classes which kotlin had since 1.0
I don't think these criticisms really hold water to be honest, though Ron may have a stronger take on this because he works on the Java team on Loom, and Loom is one of the few areas where big JVM upgrades can actually drastically simplify the programming model. Most of the other things Java has been doing are just catching up. The needs of stability and their general culture prevents them moving as fast as the Jetbrains guys did when designing Kotlin.
> Records is what Java calls data classes which kotlin had since 1.0... Most of the other things Java has been doing are just catching up.
My criticism is within the context of pron's quote:
>> It seeks to be a low-overhead language, i.e. provide abstractions that don't add overhead over the target platform, give access to all platform capabilities, and at the same time target multiple platforms... over none of which does Kotlin exert much influence
By "catch up" I'm referring to the effort required to maintain interoperability and feature-parity with the target platforms. Although Java may be behind Kotlin's sheer number of features, when Java adds one of those features (like Sealed Classes or Records) it often comes with changes to the JVM itself. JetBrains has a choice to either update their feature to match or be compatible with the JVM implementation (e.g., adding the @JvmRecord annotation), or risk breaking their goal of interoperability.
What about when a platform adds net-new features, like Java is planning to do with Pattern Matching? Discussions relating to pattern matching in Kotlin have had little activity in recent years[0] and it isn't clear whether they're planning to implement it or not. Even if the plan is to wait until JVM pattern matching is stable, they'll still need to implement it for other platforms; and if they don't implement it, there will be a feature gap that may lure some devs back to Java.
Yes, but that's an abstract argument. When you look at how it's worked out in practice it hardly matters.
For many years Kotlin didn't even use invokedynamic for lambdas. Did anyone care? No. The benefits of indy for lambdas turned out to be minor and sometimes theoretical, the benefits of better language level features were significant and immediate. The Java guys keep doing this: they add JVM changes for every new language feature even when it's of questionable value, which means lots of users just never adopt them because it'd wall out Android users or people who can't upgrade their whole JVM for backwards compatibility reasons. Meanwhile Kotlin has the same feature for years already, and if you want the JVM features for some reason then the compiler just starts using them eventually when support is widespread enough. In practice, it works. The "not a native platform" argument is well overblown.
Now like I said, there are rare exceptions. Coroutines is one. I stay away from them when possible. I'd rather wait for Loom and stay tied to one platform because coroutines are just very complicated and have a big effect on the user model. Nonetheless, I'm in a minority on that one. For people who want async/coroutines today, Kotlin has an offering and Java does not. Coroutines are widely adopted so clearly, in this space something is better than nothing.
> Yes, but that's an abstract argument... The "not a native platform" argument is well overblown.
My argument isn't that Kotlin is bad because it isn't a native platform, it's that because Kotlin isn't a native platform AND their goal is to provide a bunch of features that are fully interoperable with multiple platforms, the time required to accomplish that will eat into the development of Kotlin itself. Let's not forget that interoperability is something JetBrains proudly promotes -- if that breaks, isn't reliable, or important features from $PLATFORM aren't available with Kotlin, then fewer people will want to use it.
And to be perfectly clear: I love Kotlin and have been a proponent of it since at least 2018. I think we ought to be critical of the things we enjoy and not just give them a free pass.
> For people who want async/coroutines today, Kotlin has an offering and Java does not. Coroutines are widely adopted so clearly, in this space something is better than nothing.
Coroutines are exceptional -- especially compared to alternatives like Reactor or RxJava -- but development seems to have lost steam after 2020. Many things are still marked as `DeprecatedCoroutinesApi` or `ExperimentalCoroutineApi` with no obvious roadmap; Flows seem to have lots of open issues and unanswered questions for basic use cases.
(I am not criticizing them for taking a slow and precautions approach, just remarking that things noticeably slowed down while things like Kotlin Multiplatform ramped up.)
It's apparent that Kotlin's forward progress on many projects was derailed by the need to rewrite the compiler, which apparently sucked up far more resources than they expected. I also worry that now it'll be even more derailed by the shutdown of the JB Russian offices - a mad decision IMO that is hard to understand (perhaps customers were threatening to boycott them).
I don't perceive interop as being a particularly big drain on their time, in contrast. It has boiled down to a few annotations or compiler flags here and there. If anything the biggest overhead comes from the demand to use the new JVM features, even when it's not entirely clear why.
The sprawling, highly abstract and often experimental/opt-in nature of the coroutines API is one of the reasons I try to avoid it indeed. The tiny extension to the threading API Loom provides feels far more right, to me. I already understand threads. I don't want to have to grapple with the large set of new concepts and APIs coros have introduced to Kotlin. Value types are another area where they shouldn't have bothered, IMO, it's not something you can do properly independent of the runtime and Java's approach is superior there. But then there are also many counter-examples where Java's approach has massively slowed them down. How many years are Loom, Valhalla and Panama running now?
The Java approach is always "too little, too late". Sealed interfaces are nice, but they only really shine when coupled with switch statements that the compiler checks for exhaustiveness (because that gives you actual sum types).
Unfortunately, that's still in preview in Java 17. Also, Java's decision to only check switch expressions but not switch statements for exhaustiveness still makes their usage error prone.
In Kotlin, sum types (sealed classes) are properly supported today.
Java has to get it right. It’s by design for them to be a late mover. They can’t risk implementing a half ass feature because they have to support it for eternity.
I perfectly understand that reasoning. And if you're working for an agency and have to deliver a solution that nobody will maintain for 5 years and then some people who weren't part of the original team will have to pick it up again... then yeah, that approach might make sense.
But meanwhile, I think there are enough people who don't mind the occasional backwards incompatibility if it means finding better ways to write code now.
> I’m not sure I understand why kotlin will need to catch up with loom?
"Catch up" as in making sure that it's compatible with -- and ideally leverages -- those new platform features.
> Blocking kotlin code should benefit immediately.
I'd be remiss if I downplayed the value of that; however, Kotlin Coroutines won't benefit immediately, which is what many people who've invested in the Kotlin ecosystem use for structure concurrency. There's a uncertainty amongst the community whether Loom will complement coroutines or conflict/supersede it.
I wish apple realize that kotlin multiplatform is the real threat to the swift ecosystem, and that they refocus the swift project on making it a true cross-platform language
It exports typescript typing too. We are successfully using it for sharing businesses code from our backend with our frontend! Even models can be shared.
> It exports typescript typing too... Even models can be shared.
Do you know if this is possible with Kotlin/JVM, or only Kotlin/JS?
We've been sharing models via Kotlin/JVM -> Open API Spec -> Open API Generator, which is far from perfect or painless, and I was looking at alternatives like https://github.com/ntrrgc/ts-generator.
We use ts-generator and are pretty happy with it. Better than our JSweet solution we used earlier. We just use the type generation aspect, not the http client stuff.
Kotlin jvm cannot but you transform your kotlin jvm easily into kotlin multiplatform code. Kotlin multiplatform is not the same thing as kotlin js and can be used both by jvm and js code.
You can also leverage the expect/external/actual keywords
This. Kotlin is a great language with a lot of potential, but JB keeps locking it away in their own ecosystem. I used to do stuff with it before but this attitude has driven me away.
How have they "locked" it in? That's just BS, you are completely free to write your own tooling. The fact they're not making plugins for the language for competing products is in no way "locking it away".
Can Rust replace C or C++ yet, atleast for green field projects? Never liked either in school but always felt bad never getting into low level code after my systems classes. Hoping I could just learn Rust one day instead.
> Can Rust replace C or C++ yet, atleast for green field projects?
Mozilla has been replacing parts of Firefox C++ with Rust for a decade. They recently celebrated Rust hitting 25% of the LoC in the main repo. More broadly, serious code at large companies is written in Rust: A chunk of Google's Fuchsia OS, Dropbox's storage engine, Amazon's VM manager, etc. There are niches where C/C++ are better suited but in general Rust is good for whatever if the team wants to use it.
Probably some embedded stuff on some obscure hardware, or where special tooling is required. Do note that these languages have been around for decades, so change doesn’t come overnight. C++ still has its uses.
I've worked with both Rust and Go quite a bit, but not professionally with C or C++. Those two cover a lot of potential green field stuff, like networking, CLI, embedded, etc (maybe not games/graphics as much). Rust is significantly harder to pick up, so check out Go if you haven't already considered it. Most people become productive quickly. That said, much of what you learn in Rust is generally useful for understanding, so it depends on what your goal is.
I wasn’t under the impression that Rust is all there for embedded micros? I know some people have proven it can be done, but when I go to work with the latest Atmel/MicroChip/Nordic/STM chips, the tools normalized are C tool chains. To use Rust, I’d have to blaze paths. Frankly I’m more intrigued by upython for some (but not all) of the embedded work I do.
Totally, and could even be for old projects too. Is more a problem of will and commitment.
The pace of Rust is increasing, and anyway for the things is not possible to change right now Rust interacting with C/C++ is less hairy than other langs FFI...
Since lots of Kotlin code is normally ran on the JVM, some of that code might depend on java libraries or jvm specific stuff. They won't be able to be transpiled to run in the browser.
Svelte apps aren't written in JS but in Svelte's own component syntax files. It's "HTML" but all the parts are extended (JS -> reactive, HTML -> directives, CSS -> scoping) and it needs its own compiler to transform the source to something everything else understands.
Yes, but JSX is much more conservative in what it introduces to the language. Other than the XML syntax rest of js is mostly left untouched.
In a svelte file, a lot of usual js constructs like labels, additions, assignments etc. have different semantics making it more work for another language to support it.
Data classes, co-routines and flows, internal dsl support, null checks, smart casts, type inference, an IDE that is actually smart, a standard library that is a bit more comprehensive than what a browser has, a lot of kotlin and kotlin multiplatform libraries, and more.
The general feel of the language is that of one developed by people who deeply understand what a nice language should feel like. It has a lot of features and syntactic sugar that eliminate verbosity, make things more straight forward to use and so on. It really shows that this is a language designed from the ground up to be genuinely nice to use by people who really know what they are doing because their core business is selling developer tools to developers.
I like typescript. It is a big upgrade from Javascript and MS has a lot of the same mindset that Jetbrains brings to the table in terms of developer friendly-ness and language ergonomics. Kotlin has most of the features that make typescript nice but without the whole business of trying to keep it compatible with javascript. That adds a lot of complexity, ambiguity, and weirdness to typescript that Kotlin simply does not have or need.
The biggest thing was automatic null checking. That is such a pain in Java and has bitten me so hard many times. Having the language prevent you from writing code that can crash because of a null access violation is a big step forward.
There were other things that made Kotlin seem more modern to me, but I'm foggy now on what they were. But, when I wrote Android, I would always choose Kotlin for new projects.
- The annotation support is just better. JS ecosystem has forever been debating on decorator spec, but kotlin annotations (esp. with addition of KSP) provide good mechanism for compile time code generation.
- Support for builder dsl is just better. The js ecosystem has embraced ugly & verbose embedded XML (JSX) thanks to fb, but in kotlin we can do something like:
html {
body {
div(id="hello") {
span(text="whatever")
}
}
}
This is just syntax sugar for lambdas passed as last arg to a function, but it makes code a lot more readable.
- Inline methods - we don't have to worry about being functional vs being performant in most common cases. The implementations of map/reduce etc. in stdlib are all inline methods and compile down to for loops.
- Implicit it (single argument in lambda) and implicit this (in class methods) are minor niceties but they reduce verbosity of everyday code quite a bit.
- Interfaces don't get erased - you can use reflection to get interface references, check if an object complies with an interface at runtime. In TS this requires ceremony and assistance from third party libraries like zod/fp-ts etc.
- Extensions are cool, you can add extension functions to classes you don't control to mold their API in specific contexts. In JS world we can monkey patch whatever and TS interface merging helps with that but its a pattern generally frowned upon and prone to conflicts (which extension functions are not).
- Companion objects are nice to have. Instead of static methods/properties, you have a singleton associated with a class which can comply with any interface, can have its own extensions, can be passed around etc.
- Kotlin doesn't have F#/OCaml style pipelines, but you can achieve similar chaining by combining let/apply/with/also extensions. Eg.
- expected & actual are pretty handy for multiplatform development
What TS does better:
- Structural typing: its a better fit when modelling types for a highly dynamic language. Being able to define interfaces for data coming from sources you can't control without needing mappers etc. makes life simpler.
- Features like intersection type, index types etc. are useful and missing in Kotlin.
- Compilation times are much better.
- large collection of typedefs in the definitively typed repo.
My current role involves mostly working with TS and a day doesn't go by that I don't miss kotlin.
No comment on decorators (I think they were a mistake to implement at all, and the TS team agrees), but extension functions? Putting aside the question of how often it makes sense to uses classes at all in Typescript, you can always just... extend a class (or interface) with whatever function you want? It's not like Typescript has sealed classes/interfaces. I might be misunderstanding?
Most everything else seems to come down to "Typescript is meant to be runtime-only", which definitely has upsides and downsides (I agree that the lack of meaningful reflection support is annoying).
Let's say we have a list of strings and want to filter for those starting with "a". In Kotlin, we can use an extension function defined on the standard Java ArrayList object:
myStringList.filter { it.startsWith("a") }
...and on arrays:
myStringArray.filter { it.startsWith("a") }
...and on, for example, a boolean array (a standard JVM primitive array object):
myBooleanArray.filter { it != false }
This works for any kind of array and any kind of list, etc., even though the objects are ordinary JVM arrays and lists.
In Java, because it lacks extension functions, the stream functions are often not accessible from the object itself, so you have to hunt for where they've decided to put them for this particular type.
In the first case, we do have a stream method on the list:
And in the last case, with a boolean array, that method doesn't work and the solution I've seen suggested is this wonderful mess (involving a different static method on a different class):
IntStream.range(0, myBooleanArray.length).mapToObj(i -> myBooleanArray[i]).filter(b -> b != false).toArray();
> you can always just... extend a class (or interface) with whatever function you want
Not quite. Extension functions are statically resolved and abide by usual access modifiers.
So within a class, I can have a private extension method for another class (say C). Now if my class receives any instance of C, I can call these extension methods on this instance. But when I forward this instance to someone else, they wont have access to any of these extensions.
Libraries like exposed use this quite extensively.
> Most everything else seems to come down to "Typescript is meant to be runtime-only"
Yes, this one too because it would involve type directed emit.
> kotlin annotations (esp. with addition of KSP) provide good mechanism for compile time code generation.
Could you explain this a bit more? I thought kotlin annotations were like Java annotations - additional metadata attached to classes/fields/methods/etc but could not be used by themselves to generate code like a decorator.
Yes, that is precisely what annotations are - a common unified way to attach metadata that various tools can agree upon.
KSP [1] is a new addition to the kotlin ecosystem that facilitates cross-platform annotation processing. Various annotation processors can use this metadata to generate code - the generated classes etc. will be separate entities as opposed to direct modifications to targets.
Decorators are more powerful in that they can act upon their target directly but also (usually) have runtime overhead - this overhead is one of the reasons why the js proposal had to undergo substantial revisions.
Yeah, atleast last time I tried kotlin-js it took a minute or so for any change in IDE to actually end up in browser.
I don't understand understand the js tooling setup completely (I mostly used kotlin on backend) but the gradle-webpack integration seems to have quite some overahead. Perhaps moving to esbuild can make things faster.
I don't have a very powerful system (4yr old linux machine with 8GB ram) so ymmv.
Apparently they refuse to support the most popular web IDE because Kotlin for JS is really about selling IDEA licenses. Fair enough, but it means I don't suggest Kotlin for anything except as a Java alternative and Android.
There's better options from companies that are less adversarial to their community.