If you're on a computer, click the three dots that are to the right of "Save" and then click "Open Transcript". These are auto-generated so the fidelity may not be there but it's one shortcut to reading the podcast.
Which is a surprise to me because I don’t really consider the jetbrain products to be “performant”. They run fine, sure, but take a long time to start up or open a project, and can get sluggish if left open for awhile.
It can take long on an old system, but that doesn't matter much [to me] when the IDE works fast throughout the day even when periodically opening and closing projects.
IntelliJ start up time is much better now. Take a look on IntelliJ CE (ported to Apple Silicon) vs VS Code (under Rosetta 2) https://www.youtube.com/watch?v=Erg0Dz0MXww Of course this is unfair comparison, but you can see that the start up isn't slow.
Jetbrain stuff has always been slow - until I got an AMD 5600 (ram at 3200). For whatever reason, this combo of chip and updates to their software maybe (I turn off a lot of the add ins) - I've stopped being annoyed at the speed. It's "fast enough".
This was my main thought. Maybe all that effort expended on managing the runtime could be aggregated into a unified effort in a more cohesive (to your goals) language.
IntelliJ had been based on java for twenty years. It has worked well as a mainstream cross platform application that has been around before, and outlived, other approaches.
Moving to another language would surely be many more orders of magnitude than plugging in a new JIT?
They didn't write the runtime, they just modified a (relatively) small piece of it. From the article:
> JetBrains forked the OpenJDK project in order to facilitate better control over how the IDEs looked on Macs a well as other HiDPI screens; JetBrains Runtime was born and we bundled it with our IDEs from 2014.
> There are many facets of the runtime, and we do not know every little crevice of it, rather we focus on the part of the code that handles the rendering of UI on screens.
Here's the problem: they selected Java many, many years ago back when Apple shipped Java as part of Mac OS X. I believe they're based on IntelliJ and presumably have added a considerable amount of their own code over the last 20 years. They certainly didn't know that the Oracle acquisition would lead to Apple removing a not unpopular feature due to legal risks.
With a large cross-platform codebase like that, Java is an understandable choice and at any point the cost of switching would be greater than the cost of fixing the current issue.
This isn't it's own runtime. It's a modified JDK and when you're one of the largest pieces of GUI software in Java, you're obviously going to have things you want to change in it.
They've created a huge platform. They're going to have needs that aren't met in a pre-packaged thing.
VSCode avoided using any frontend frameworks, does that mean they made a wrong engineering choice?
Ah, yes. The classic let's rewrite everything from first principles instead of using a proven, state-of-the-art runtime for which we just to reimplement font rendering.
> To this end, we began to investigate how we could handle this transition with grace. It soon turned out that we had to re-write a lot of the JIT system, a core component of the JVM itself, which was something we had little to no experience in.
Why couldn't they just merge the (presumable) upstream OpenJDK support into their fork?
So, uh, is there an M1 build available now? It’s not clear to me from this blog post or scanning the release notes for the past few releases. Last time I tried PyCharm, in November I believe, it wasn’t really useable through Rosetta so was waiting for the native JRE.
28 comments
[ 3.0 ms ] story [ 68.2 ms ] threadIs there a transcript somewhere?
If you're on a computer, click the three dots that are to the right of "Save" and then click "Open Transcript". These are auto-generated so the fidelity may not be there but it's one shortcut to reading the podcast.
For reference, it starts in around 3 seconds on my 2013ish laptop. (actually, more like 2014 - Haswell i7)
That changes on Apple M1 Silicon. PyCharm and IntelliJ native are very fast, as is Apple’s XCode. Life is sweet.
Moving to another language would surely be many more orders of magnitude than plugging in a new JIT?
I don't have any hopes for it besides Android, which is working thanks Google gatekeeping Java updates and pushing Kotlin instead.
> JetBrains forked the OpenJDK project in order to facilitate better control over how the IDEs looked on Macs a well as other HiDPI screens; JetBrains Runtime was born and we bundled it with our IDEs from 2014.
> There are many facets of the runtime, and we do not know every little crevice of it, rather we focus on the part of the code that handles the rendering of UI on screens.
With a large cross-platform codebase like that, Java is an understandable choice and at any point the cost of switching would be greater than the cost of fixing the current issue.
They've created a huge platform. They're going to have needs that aren't met in a pre-packaged thing.
VSCode avoided using any frontend frameworks, does that mean they made a wrong engineering choice?
See https://confluence.jetbrains.com/display/JBR/JetBrains+Runti...
Ugh.
Why couldn't they just merge the (presumable) upstream OpenJDK support into their fork?