July 28, 2025 • 35 mins
Inside JetBrains' New Bazel Plugin with Justin Kaeser
In this episode, Alex Eagle, co-founder and CEO of Aspect Build, talks with Justin Kaeser, team lead at JetBrains, about the upcoming general availability of their new Bazel plugin for IntelliJ IDEA, PyCharm, and GoLand.
They unpack what’s new, what remains the same, and why JetBrains decided to create a new plugin in the first place. The conversation also covers the future of the old plugin, current Bazel support in CLion and Android Studio, and what actually happened to BSP.
If you use Bazel with JetBrains IDEs or you're curious about the direction of Bazel tooling, this episode is worth a listen.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Hello and welcome back to Aspect Insights, your favorite
podcast about Bazel and its ecosystem. My name is Alex, I'm
a founder at Aspect Build. We make a monorepo developer platform based on
Bazel and we needed to work with editors and IDEs.
So I'm very excited to speak today with Justin Kaiser
from JetBrains, maker of Intellij,
(00:22):
Webstorm, Pycharm. All of these editors, I guess I should
say ides based on common platform
and the journey we've been on over many years to
make that work well and some exciting announcements of what's
coming next. So with that, welcome to the show,
Justin. Hello. Happy to be here.
(00:45):
Thank you so much for coming and chatting with everyone. How are you doing today?
Relatively wonderful. As I say. That's a
great tagline. I love that one. So, yeah, how long have you worked at
Jetbrains? I feel like it's been since forever. It has been since forever,
but to be a bit more precise, nine weeks and nine
years and two weeks. Okay, so you just had
(01:08):
your nine year anniversary when you hit 10 years. We should send you a cake.
Please do. Okay, I guess I've just committed. I
would love that aspect cake with some
basal insights on top because I mean we, we do
need them. I have to mention. So since we started this
Basel project Bazel plugin at first,
(01:30):
maybe against some skepticism within IntelliJ, within
JetBrains. More recently since this year we are actually migrating
to Bazel, our Intellij Monorepo which has been
traditionally built with JPS, which is the JetBrains
project system tool built into IntelliJ. Ah, you're going
to dog food now. That's actually very positive development
(01:52):
for Bazel. Yep. It's great for us, for us as
a team to get that feedback internally
soon. Yeah. How far through the migration are you now? Is it just committed or
have you started? It builds on CI but the developers aren't
using it yet. Okay, well, they're going to want some
incredibly effective IDE support for
(02:14):
Bazel. So yeah, we're working on it. It's a bit,
how should I put it, Intimidating because then
soon 2000 developers will be complaining to us.
Well, yeah, developers that you actually have a shared
manager with at some level. And so yeah, they can escalate and say, hey, make
Justin and his team fix my problem. Exactly. So I was just
(02:36):
looking back at the Basil did a Survey, User Survey
2025 on Put the link in the show notes and the second
top pain point on the last slide there is IDE
integration and Tooling. So I'm sure everyone knows that this
is a important topic, but that should be another reason to remind you.
It's right. I'm well aware. Yeah, it's right after documentation
(02:59):
and learning curve. Yeah. So the way our
team started was actually I was switching
to the customer success engineering team part time at least. And we
started just talking to all our largest customers and found out
there is a very large chunk of them who are using
Bazel already or are in the process of migrating to Bazel and
(03:22):
none of them were all too happy with their IDE experience
and in particular in IntelliJ IDEA and
sealion and Goland and all that.
So we figured let's start a team and
start working on that. Well, let's chat about the history for a minute
because I've also been a die hard IntelliJ user, at least
(03:46):
back when I was doing Java at Google for a long time. Intellij has been
around since I started programming. I guess, I mean, like what,
2005 or something? 2000,
okay. I guess our 25 year anniversary.
Yeah. Okay. It's a 25 year old ide. And is it still the
same code base essentially? Like if you go back through the git history, you go
(04:07):
all the way back to the initial commit or was it rewritten from scratch at
some point? I'm not sure, but the earliest commits
I've actually seen are around early
2000s. Okay, so that is
a big old code base. Yeah. And when I was at Google we had the
Blaze plugin that was developed, I guess by the Blaze
(04:27):
team internally and it was a little
understaffed. When Was this? Maybe
2012 or something. And then
Eclipse got popular and there was actually a time at Google when they said, you
have to stop using IntelliJ. We want everybody to use Eclipse. And
I said no thanks, and continued to do it anyway because I was
always of the opinion that I know how to like. I'm pretty handy with the
(04:51):
IntelliJ Project Configuration dialog boxes and I'm happy to just point it to the class
path myself. And I don't need a plugin, thank you very much. And so you
can make it work, right? Especially if you're not changing your project very frequently,
but not something most people want to do. Fortunately,
IntelliJ came back at Google kind of with a vengeance, because when Android came out,
they needed a good way to develop Android apps and Google chose to build
(05:13):
Android Studio on top of Intellij, or I guess I should say on
top of Jetbrains. Am I Saying the right thing. Intellij, the. You can say
the Intellij platform. Okay, yeah, so like the
sort of the generic part that underlies the support for all the different languages.
Yeah, I mean Android Studio is interesting because it's still
(05:34):
very actively being developed and has its own
plugin. So I guess tell me your history with that whole
development. The history of the Basel plugins, of which we have way
too many right now. When our little team
started just a few years ago,
there was just the Basel
(05:56):
plugin for IntelliJ, the Bazel plugin for Clion and the Basel
plugin for Android Studio. So actually three plugins,
but actually they are all based on a common code base.
The one you find under GitHub, bazel build, intellij.
Those are the three that JetBrains maintains. And then there's a couple more plugins at
(06:17):
Google. Right. Those were the ones at the time that
Google maintained. Oh okay. And then they donated to
open source. Put it like that. Yes. Well it was maintained by
Google only in open source. They were taking
contributions from people. However,
(06:37):
that's where the problem started. They were not very liberal about
these contributions. So basically which
contributions would be accepted and what features would be developed
was based primarily on Google's internal, internal needs.
So that's why all our customers were a little bit
unhappy with the situation because they had a lot
(07:00):
of trouble upstreaming their changes to this
main open source plugin. So
basically every larger customer we talked to had
their own fork of this plugin. So
yeah, that was not great for maintenance, not
great for building. Yeah,
(07:23):
common base, common platform
of Basel support in Intellij basically.
So well, at first we tried to get involved
by contributing, but yeah, that at the
time turned out to be a little tricky.
So we just kind of decided we already had a prototype
(07:47):
to build our own Bazel plugin for IntelliJ because
how hard can it be really? It turned out to be quite hard. At least
it turned out to be quite hard to address the problems that
the main pain points that people had
with Google's plugin. That
turned out to be a multi year effort of not just writing
(08:08):
a plugin, but changing things in the IntelliJ platform. Working
with developers of the underlying
APIs like the project model in Intellij.
And well, I think just in the past half
year or so we managed to really plow
through all the remaining major blockers to
(08:32):
be able to deliver a new plugin that does what
I think our customers want and need. Right.
Which is awesome. And so my understanding is that it's very close
to. You're close to the GA launch. Tell us
about that. Yeah, so we're gonna announce it
together with a 2025.2 release of
(08:54):
IntelliJ IDEA, which I'm told is in about
two weeks. But don't take that as an official
announcement. It's just a rough timeline. And
so since the previous release I think we've
addressed many of the major pain points around project
models and indexing performance
(09:16):
and well, many, many small things.
I could link you the youtrack and see and
you can see for yourself how many issues have been closed. So it's
about 100 in the past three or
four months. But we are
announcing some major new features,
(09:39):
at least new for our plugin, which is like the support for
Go and Goland. Previously we were only available for IntelliJ
idea. The Python support has been improved, made more
just stable, cover more use cases. We've
improved JVM support. So actually the JVM
Java Kotlin Scala support has been the major focus
(10:02):
of our development so far because, well, my
team belongs to IntelliJ IDEA, which is primarily JVM
IDE. Yes. And of course Kotlin is a language that Jetbrains
developed and I think still owns. Yes, exactly. Well,
I don't know about the ownership. There is some kind of cooperation
foundation together with Google, but I'm not the authority on that.
(10:25):
But yeah, we have very large team devoted just to
the development of Kotlin, the language, tooling
around it and so on. So maybe I. What other
languages, like you mentioned Clion earlier, do you still have C
support in this plugin or is that a different plugin? This plugin currently doesn't support
C, so right now we don't have any
(10:47):
c support in IntelliJ IDEA, so
right now it's not in our cluster scope. However,
the Clion team is still maintaining the
fork of the Alder that was originally
Google's plugin for IntelliJ and Clion, but they
will be maintaining it only for clion for the time being. The
(11:09):
general direction we want to go is to have really a single
plugin that works for IntelliJ, for Clion, for.
For all our IDEs. Really? Yeah. So I was going to ask about
Webstorm as another example. JavaScript and TypeScript are the
most popular languages according to some metric. Yeah,
so they're not the most popular languages
(11:31):
to use with Bazel. However, at least among our
customers, I've gotten some interest for JavaScript, TypeScript, also
for Rust in Principle, Me and our team
would love to support everything. We just have to focus on the
most impactful use cases in the near term. So that
means right now this is JVM Go and Python
(11:53):
and these are the things that will be supported by the 25.2 release
and with them Intellij idea, Goland and Pycharm. Yes.
And so phpstorm. Hard to imagine that that
gets on the roadmap ever. Rustrover and webstorm could happen
Sea lion when that team is ready to integrate with
(12:14):
you. Ruby mine. Hard to imagine that ever happens. What
about. I know one company that uses Ruby with Bazel.
Yes, I think. And one company that uses Perl with Bazel.
So that's something. Yeah, well, I guess maybe.
Interesting technical insight. I'm certainly curious how
much of the plugin is language specific and how much is generic to the
(12:36):
platform. Like I imagine you integrate with the project model and the project model
is language agnostic. The project model are unfortunately
very language specific. We have project model
for Java that is
mostly reused by Kotlin and
Scala because they all integrate with Java. And actually
(12:59):
this Java project model has been a huge
pain point that we only were able to solve
very recently. Is it because it wasn't expressive enough to
represent Bazel's dependency graph? That's part of the problem
and that's also not the fully solved problem
yet. But yes, the main
(13:22):
problem here was when you ask Bazel for
sources that belong to a target, it will give
you a list of source files. The Java
plugin and the Java project model in IntelliJ
only allow you to list directories
to which sources are attached. And
(13:45):
one directory of sources in Java could only
also belong to exactly one IntelliJ module.
So you have two problems here. Bazel can give you
lists of sources that do not match all the sources within a
directory. Every time you don't use a glob,
that's already a problem for the Java project model. Yeah,
(14:08):
especially if within that directory you have
multiple targets. Yeah, like a common case. I guess. Actually
in Java it's typically not. You typically don't put tests
in the same folder with production sources. Right. Because like
you can always discourage that. Yeah. And well, I still
encourage our customers to use directory
(14:31):
level globs to define their JVM targets
because that will still give you better performance in IntelliJ.
However, it's. As of the next release, it will not be
requirement to have a working project model at
all. Okay, yeah, that's great. Because Glob does have a
performance penalty. In Bazel.
(14:53):
And a performance benefit IntelliJ essentially. So,
yeah, I think you wanted to talk about, well, why do we even
need a Bazel plugin for
IntelliJ, right? Yeah, I think there are
a lot of editors and IDEs, and certainly one thing is that
if you have to like your team had to do a bunch of effort for
(15:16):
the IntelliJ platform, so then somebody has to go do the same effort for Visual
Studio code and Visual Studio and Atom and a bunch of other
editors. Yeah. Though the efforts might
be in different points. So
one of the main efforts problems we have to solve
basically is the sync. So we
(15:39):
have a project model in IntelliJ. Actually, for every
language we have a project model and we have to have a
separate different project model in Bazel.
And now we need to match those project models.
But why do we have different project models in the first place?
So we're solving different problems in the IDE and
(16:01):
in the build tool. In the build tool, we want
consistent build, we want a reproducible build. We
want to automate taking everything that goes
into the final product, the final target, whatever you want to
call it, and make sure that is built
consistently in the editor, in the ide. Well, we
(16:23):
want a way to run that, sure. But
primarily we want to get live up to date
information on how is my code doing? How am I
doing in my code on the file that I have open right
now, is there, am I going to break anything by
adding this line? For instance, now I could
(16:45):
just call Bazel and say, please build this file and
oh, oops, something invalidated three
levels of dependencies or something and I'm going to wait five minutes
or something. In not so good cases in
IntelliJ, we avoid that by just looking
at the direct dependencies of this file in
(17:08):
terms of symbols, basically on dumb down level.
So we want to see if those all the symbols
that my current file depends on resolve.
And I can simulate the
compiler in my editor. So IntelliJ
doesn't run a presentation compiler in the background or
(17:31):
anything. It builds an ast. So sort of
that represents your code. And this AST can actually
also represent errors. So it can tell you, okay,
you have some error in your code here, but that doesn't mean I won't
tell you where the others are, other errors are, or
that you cannot start typing and fix
(17:53):
something else in your file at the same time or in another file. You can
get all the errors and warnings, you know,
inspections, improvements. You could make life.
Yeah, so this, this concept exists for all Languages and
is usually implemented with a language service or at least
in the last few years it feels like that's been the case. Which is protocol
(18:15):
that like Microsoft owns and it allows you
to, you know, like Clang for example has a clang D which is a demon
that speaks this language server protocol which means editors can ask it for completions
or error diagnostics. I think you're saying like this is not
what IntelliJ does. It has a different. Doesn't use that property. IntelliJ
predates the LSP the language. Yes. By 15
(18:37):
years or something. Yeah, yeah, exactly. So it
does it in its own way unfortunately. Some might say
by actually re implementing basically the whole logic of the
language of the compiler, type checker and whatnot. Yeah. So when
there's a new version of java, when like Java 21 came out there was a
lot of work to do I imagine to support it. Yeah, any new version of
(18:59):
any language incurs some work there. It's.
Yeah, it depends on what the language does. I was involved in
Scala a long time. For a long time. For first
six years at JetBrains and Scala 3 was
always on the horizon there. I don't know. In 2019
we went to, we
(19:21):
convened to hack on the Scala 3
support 2025 I think the Scala team is
now final aiming to have a complete Scala
3 support. Well Scala 3 is a moving target but yeah, that's just
as an aside. So yeah, there's a lot of work to do there.
Unfortunately basically all, all of it has to be done by
(19:43):
JetBrains. It's not usually the case that
the language authors will contribute this.
So for Scala is there a language server protocol implementation? There is
and that's actually interesting segue.
The implementation of this language server protocol for
Scala is based on the build
(20:06):
server protocol. So in the Metals Scala
language server they decided they don't want to re
implement the Scala type
checker. Everything that has turned out to be very hard
to nearly impossible in our experience. So instead they
just ask the build tool to run an
(20:28):
incremental build and give you the output, give you the
list of errors and warnings and those will just be pushed
to the editor via lsp. So there's a two stage
architecture there. This build server protocol
could in principle be implemented by any build tool.
Initially it was in Scala implemented by Bloop, which
(20:51):
was a kind of wrapper for build tools that would
just optimize the
incremental compilation part so you can get sub second
feedback time on the current files or
targets that you're building and that works okay for
a language server as long as you don't have
(21:13):
funky edge cases. Now, I was involved
in the design and implementation of this build server
protocol, also in Intellij in the Scala plugin at the
time. In the Scala world, it did gain some
traction. So basically every Scala build tool implements it by now
and some use it to integrate with IntelliJ.
(21:36):
And this kind of spawned, well, initially just
an intern project. What if we tried to implement the build
server protocol for Bazel? So we did that and the
first results were quite promising. So things
basically worked right, just. Well, the path from
basically work to thing that works in
(21:59):
enterprise production environments is actually quite long. But this
was the seed of what we used to build the new Bazel plugin
initially. So I would say we had the ambition
of making IntelliJ plugin that other
build tools could also integrate with. So abstracting
away the how do we set up the project model
(22:21):
exactly, because that is a huge
pain for any build tool author that wants to integrate with
IntelliJ. So yeah, that was our ambition. We followed it for quite a while,
but as we weren't making
progress, we would have liked just on the Bazel side,
due to aforementioned issues like
(22:44):
actually the project model and very many
details how we integrate with IntelliJ. But also
how do we get information from Bazel into intellij
and like, the more details we add, the
more troublesome it gets to figure out
how exactly do we model this build tool agnostic way.
(23:08):
So we basically just decided, okay, let's rip this out
and just, just support Bazel and tries to support Bazel
really well. You know, at the time the build server protocol was
created, we kind of had the issue that
everybody in Scala was creating a new build tool every half
year or so and it was basically impossible to
(23:30):
keep up with that on IntelliJ side. Realistically,
one person can barely support one build tool. That was
me. I was supporting SBT mostly and not as
nicely as I would have liked, but now the situation is a
bit different. There's more, I would say consolidation
on bigger tools like Bazel.
(23:53):
And so yeah, we want to focus on Bazel. Maybe we'll
figure out how to abstract some of this later
on, but that we'll do that when we need it.
Great. Okay, well, first of all, since we're live streaming, we have a few minutes
left. If anyone listening in on and signed in with
YouTube or LinkedIn, please send us some questions if you have them. We'd love to
(24:15):
take live questions and Keep it interactive. I was just showing if you're on video,
the build server protocol. There's a website for it you can look
at. I also like you mentioned that it was kind of a
workaround because the Scala compiler is slow but you want to get
sub second interactive feedback in the editor. And so
making a compiler do that is a different task from
(24:38):
making a compiler do one off builds on the command line.
There's a great talk that Anders Hejlsberg did, who's the author of
Typescript and C and Turbo
Pascal, I think like you know, one of the preeminent
compiler designers of our time. I'll put that in the show notes too. He
was, he did sort of a lunch talk with Seth Juarez and like
(25:00):
went into the details of, of how you build such a thing, which as a
compiler geek myself I found really interesting. And yeah, like some, some
compilers have that. I think LLVM is another example and it's
part of why clangd is possible is that it like the
compilers built with that sort of query model in mind and not only
with like you know, produce the final executable or the,
(25:22):
the object file or whatever it is the compiler outputs. So I see why it
was the build server protocol sounds appealing and I'm glad that you
decided to cut scope so that you could get something out that works for
Bazel for sure. Yeah. One other link that I'll put in the show notes,
we decided not to try to do a live demo right here in the but
you can go watch a demo. This from your co worker at Jetbrains
(25:44):
and I think he's showing the current version of the plugin. Is that right? Yes,
a very recent version. Okay. So yeah, if you want to see how this actually
looks in practice, like this is a great sort of getting started with Bazel Java
video and it includes bringing in third party dependencies from the
Maven ecosystem and then getting them to show up without the red squigglies
and have completion and things like that working in the ide. Right. Yeah. I
(26:05):
also recently did a similar talk at a conference. So I think
now with our plugin it's fairly easy to get started on simple
projects with Bazel. So I will still need a bit more
material for onboarding people, but it's
not a huge pain to just start a JVM project,
add in some Python, add in some shell scripts, wire it all up
(26:28):
in a single build tool. So I think Bazel
will be ready for the desktop for the
casual user quite soon. That's awesome. Yeah, I mean, I'll make a
plug also for like, we have an init command that gives you like a workspace
that's ready to go with a bunch of important features, like having the Tools directory
and like the initial requirements file setup. If you're doing Python,
(26:52):
like, there's. There's some steps to go through, even just for Java to set up
rules, JVM external and get the Maven compilation set up. Yeah, I
mean, maybe, maybe we can do an extended demo of this sometime later.
I should also point out, while we're looking at some links, you've got a bunch
of posts on the Jetbrains blog that I follow and you mentioned you're working on
another one right now. Now, probably anybody interested in this should go. Is
(27:13):
there like a particular post that you think they should read or just like, should
they subscribe to your future posts? They should read the post that I'm
going to post in roughly two weeks on the new
the GA release. It's mostly about what features
we added, but I think it marks a major milestone for
us. So this is the point where I expect
(27:36):
most people will be able to roll this out in their larger
companies. It's already been rolled out over a
fairly large code base with like 6,000 developers at one of our
customers and works smoothly enough.
I would say. Naturally, Miles on it. It's no longer bleeding edge.
Exactly. Exactly. Cool. All right, well, we did get a couple of questions. Thanks
(28:00):
for. Thanks. Those who are listening. So from Sergey going to be
released anytime soon? You mentioned maybe in a couple of weeks, but definitely
with 2025.2. Is the releases targeted? Yes,
two, three weeks, something like this. And then the other part was, is it going
to remain open source? I expect most of it's going to
remain open source. The core definitely. We may or
(28:22):
may not add things that are not open source
or certain features may be not open source. So
do you have like an internal repo that you sync to GitHub and
it has a superset of the files? Yeah. So it's actually part of the Intellij
Monorepo. And right now it gets synced completely to
the Hirsch Gotten repo. I guess you can add that to the notes.
(28:44):
Yeah. And you can also contribute directly
to the Hirsch Gotten repo. Great. So yeah, you do accept
contributions. I'm just curious, which tool do you use to sync
the changes between the monorepo and the GitHub? I think it's some custom tool.
Okay. I didn't set it up. Yes, you're accepting contributions. Have you
had contributors on that repo yet? I guess I can go click on Insights and
(29:06):
see who's contributed. Quite a few people.
Cool. Yeah. I'm waiting for GitHub to crunch the latest data.
Just for me. Yes, just for you. Hang
tight. It says you will also find many contributors from
Google in there because we merged part of the, we call it
the OG originally, Google's Basel plugin
(29:29):
into this one. Yeah, so the answer is.
I guess I should really look just in the recent history because this Hirschgarten
repo has commits going back to 2015. Yeah, the
actual start of the project was maybe
2020 when we had these experimental internship
projects and we only really started going in
(29:51):
23. Really? Yeah. So yeah, I mean it looks like
you've got a couple dozen contributors on there, which is great.
So from multi. Very related question. So like,
obviously it's easy for me to send you a PR to that repo to fix
a spelling mistake, but what if I wanted to like, you know, add typescript
support? Let's say, like, if you wanted to add a new language
(30:11):
ecosystem, could people outside Jetbrains manage
to do that and upstream it? Or do you think that's something only Jetbrains could
do? I think people outside could do it with
some help from us. It's complicated.
So if you say I just want some basic support
that will work on my project, that will be
(30:33):
something that an intern can deliver in
a few weeks to months. If you want something that works
on an enterprise scale project, this will be
at least 3, 6, 12 months.
So if somebody did want to add support for their language and
was able to get to that first quality bar you mentioned, do you think that
(30:56):
kind of contribution could be accepted? Or do you. Does this. Does your repo really
only want the enterprise quality? No, we take
like proofs of concept, I would say too.
We'll probably put them behind a feature flag until they're stabilized. But we have
had proofs of concept in there for a long time under feature
flags. Okay. So yeah, that can be a basis for
(31:18):
further development or just the rewrite if we decide it
doesn't work this way. That has happened for Go, for
instance. Okay. So I guess the answer is if your
organization really wants to commit some resources to adding support for another
one of the JetBrains IDEs.
Rust Rover is probably a good example where like Rust is actually like
(31:40):
increasing in popularity. It's an ecosystem that would be great to have support for.
Yeah, cool. And then related how. How much of the code that's
required to implement that is open source. Like is there every
Everything's in the Kirch garden repo that somebody would need. If they wanted it. What
might be a bit tricky if you're targeting a closed source IDE
like Clion, Rust, Rover, I think
(32:02):
then it will be hard to find the
APIs you need to integrate with. Sure. So you'll need some help from
somebody at Jetbrains if you want to do these things. Yes.
Yeah. I mean forever ago when I was working at
Google I actually had a project of contributing a
Jetbrains plugin and there was some nice person over there who
(32:24):
helped me figure out the model for interacting with the test
result pane because we were writing our own test
like JavaScript Test Runner. It ended up being called Karma, but I
appreciated having that help to see some of the internal APIs for sure.
Awesome. So I think we covered everything that we meant to cover. We know
why we need a special plugin for the editor, especially for Intellij
(32:47):
because it has its own special project model. The stuff is now
almost shipped and within a couple weeks, probably most people
listening to this, you'll have like a week or less hopefully before there's
a GA release, but they could certainly go and try the pre release if they
want to see what this looks like or else watch the demo video. Today's release
or last week's release will be very similar to the GA
(33:08):
release. If you're using the 2025.2 EAP
versions of IntelliJ, great, but we might add another feature or so.
Okay, well we should definitely keep watching your blog posts for what those
features are and I think the call to action here is
Go, give it a try. If you don't use Intellij already,
then give it a try anyway. Python,
(33:31):
Java, Kotlin, Scala and Go.
Yes, if you develop in one of those languages, come give this a try
maybe. I do have one final still behind. A feature flag by the way, but.
Okay, so for Go it's more experimental so
Go will be included in the ga, yes, yes. Okay, meaning something's
up there I guess. I do have one question specifically for Go, which is that
(33:53):
the GO compiler added something called Go Packages driver as a way
to say I know better where the third party packages I've put are. They're not
just on the Go package path in like the standard locations. And of course Basil
loves to put things in weird locations. Do you still need the Go packages driver
thing for the Golan support? Honestly, I don't know.
Okay, well I know that thing has been difficult to use,
(34:15):
so I'll be. Excited if it's completely outside of my personal
area of knowledge stuff. Okay. All right, fair enough. The answer
is we're not sure. So yeah, I guess we should all go give this stuff
a try and then come contribute back on GitHub like
like good consumers of open source do.
Yes, please do. And we also are happy to receive
(34:36):
your bug reports on our YouTrack. Okay.
Which also add in the notes. Yep,
that sounds great. So yeah, I'll make sure we include all those links on there.
And thanks for coming to tell us all about your work and really
excited after a few years of of what turned out
to be a difficult project of let's just make a new plugin. It's time to
(34:58):
launch. Yes. Congratulations. Thanks for having me and thank you.
See you all next time.
Hello and welcome back to Aspect Insights, your favorite
podcast about Bazel and its ecosystem. My name is Alex, I'm
a founder at Aspect Build. We make a monorepo developer platform based on
Bazel and we needed to work with editors and IDEs.
So I'm very excited to speak today with Justin Kaiser
from JetBrains, maker of Intellij,
(00:22):
Webstorm, Pycharm. All of these editors, I guess I should
say ides based on common platform
and the journey we've been on over many years to
make that work well and some exciting announcements of what's
coming next. So with that, welcome to the show,
Justin. Hello. Happy to be here.
(00:45):
Thank you so much for coming and chatting with everyone. How are you doing today?
Relatively wonderful. As I say. That's a
great tagline. I love that one. So, yeah, how long have you worked at
Jetbrains? I feel like it's been since forever. It has been since forever,
but to be a bit more precise, nine weeks and nine
years and two weeks. Okay, so you just had
(01:08):
your nine year anniversary when you hit 10 years. We should send you a cake.
Please do. Okay, I guess I've just committed. I
would love that aspect cake with some
basal insights on top because I mean we, we do
need them. I have to mention. So since we started this
Basel project Bazel plugin at first,
(01:30):
maybe against some skepticism within IntelliJ, within
JetBrains. More recently since this year we are actually migrating
to Bazel, our Intellij Monorepo which has been
traditionally built with JPS, which is the JetBrains
project system tool built into IntelliJ. Ah, you're going
to dog food now. That's actually very positive development
(01:52):
for Bazel. Yep. It's great for us, for us as
a team to get that feedback internally
soon. Yeah. How far through the migration are you now? Is it just committed or
have you started? It builds on CI but the developers aren't
using it yet. Okay, well, they're going to want some
incredibly effective IDE support for
(02:14):
Bazel. So yeah, we're working on it. It's a bit,
how should I put it, Intimidating because then
soon 2000 developers will be complaining to us.
Well, yeah, developers that you actually have a shared
manager with at some level. And so yeah, they can escalate and say, hey, make
Justin and his team fix my problem. Exactly. So I was just
(02:36):
looking back at the Basil did a Survey, User Survey
2025 on Put the link in the show notes and the second
top pain point on the last slide there is IDE
integration and Tooling. So I'm sure everyone knows that this
is a important topic, but that should be another reason to remind you.
It's right. I'm well aware. Yeah, it's right after documentation
(02:59):
and learning curve. Yeah. So the way our
team started was actually I was switching
to the customer success engineering team part time at least. And we
started just talking to all our largest customers and found out
there is a very large chunk of them who are using
Bazel already or are in the process of migrating to Bazel and
(03:22):
none of them were all too happy with their IDE experience
and in particular in IntelliJ IDEA and
sealion and Goland and all that.
So we figured let's start a team and
start working on that. Well, let's chat about the history for a minute
because I've also been a die hard IntelliJ user, at least
(03:46):
back when I was doing Java at Google for a long time. Intellij has been
around since I started programming. I guess, I mean, like what,
2005 or something? 2000,
okay. I guess our 25 year anniversary.
Yeah. Okay. It's a 25 year old ide. And is it still the
same code base essentially? Like if you go back through the git history, you go
(04:07):
all the way back to the initial commit or was it rewritten from scratch at
some point? I'm not sure, but the earliest commits
I've actually seen are around early
2000s. Okay, so that is
a big old code base. Yeah. And when I was at Google we had the
Blaze plugin that was developed, I guess by the Blaze
(04:27):
team internally and it was a little
understaffed. When Was this? Maybe
2012 or something. And then
Eclipse got popular and there was actually a time at Google when they said, you
have to stop using IntelliJ. We want everybody to use Eclipse. And
I said no thanks, and continued to do it anyway because I was
always of the opinion that I know how to like. I'm pretty handy with the
(04:51):
IntelliJ Project Configuration dialog boxes and I'm happy to just point it to the class
path myself. And I don't need a plugin, thank you very much. And so you
can make it work, right? Especially if you're not changing your project very frequently,
but not something most people want to do. Fortunately,
IntelliJ came back at Google kind of with a vengeance, because when Android came out,
they needed a good way to develop Android apps and Google chose to build
(05:13):
Android Studio on top of Intellij, or I guess I should say on
top of Jetbrains. Am I Saying the right thing. Intellij, the. You can say
the Intellij platform. Okay, yeah, so like the
sort of the generic part that underlies the support for all the different languages.
Yeah, I mean Android Studio is interesting because it's still
(05:34):
very actively being developed and has its own
plugin. So I guess tell me your history with that whole
development. The history of the Basel plugins, of which we have way
too many right now. When our little team
started just a few years ago,
there was just the Basel
(05:56):
plugin for IntelliJ, the Bazel plugin for Clion and the Basel
plugin for Android Studio. So actually three plugins,
but actually they are all based on a common code base.
The one you find under GitHub, bazel build, intellij.
Those are the three that JetBrains maintains. And then there's a couple more plugins at
(06:17):
Google. Right. Those were the ones at the time that
Google maintained. Oh okay. And then they donated to
open source. Put it like that. Yes. Well it was maintained by
Google only in open source. They were taking
contributions from people. However,
(06:37):
that's where the problem started. They were not very liberal about
these contributions. So basically which
contributions would be accepted and what features would be developed
was based primarily on Google's internal, internal needs.
So that's why all our customers were a little bit
unhappy with the situation because they had a lot
(07:00):
of trouble upstreaming their changes to this
main open source plugin. So
basically every larger customer we talked to had
their own fork of this plugin. So
yeah, that was not great for maintenance, not
great for building. Yeah,
(07:23):
common base, common platform
of Basel support in Intellij basically.
So well, at first we tried to get involved
by contributing, but yeah, that at the
time turned out to be a little tricky.
So we just kind of decided we already had a prototype
(07:47):
to build our own Bazel plugin for IntelliJ because
how hard can it be really? It turned out to be quite hard. At least
it turned out to be quite hard to address the problems that
the main pain points that people had
with Google's plugin. That
turned out to be a multi year effort of not just writing
(08:08):
a plugin, but changing things in the IntelliJ platform. Working
with developers of the underlying
APIs like the project model in Intellij.
And well, I think just in the past half
year or so we managed to really plow
through all the remaining major blockers to
(08:32):
be able to deliver a new plugin that does what
I think our customers want and need. Right.
Which is awesome. And so my understanding is that it's very close
to. You're close to the GA launch. Tell us
about that. Yeah, so we're gonna announce it
together with a 2025.2 release of
(08:54):
IntelliJ IDEA, which I'm told is in about
two weeks. But don't take that as an official
announcement. It's just a rough timeline. And
so since the previous release I think we've
addressed many of the major pain points around project
models and indexing performance
(09:16):
and well, many, many small things.
I could link you the youtrack and see and
you can see for yourself how many issues have been closed. So it's
about 100 in the past three or
four months. But we are
announcing some major new features,
(09:39):
at least new for our plugin, which is like the support for
Go and Goland. Previously we were only available for IntelliJ
idea. The Python support has been improved, made more
just stable, cover more use cases. We've
improved JVM support. So actually the JVM
Java Kotlin Scala support has been the major focus
(10:02):
of our development so far because, well, my
team belongs to IntelliJ IDEA, which is primarily JVM
IDE. Yes. And of course Kotlin is a language that Jetbrains
developed and I think still owns. Yes, exactly. Well,
I don't know about the ownership. There is some kind of cooperation
foundation together with Google, but I'm not the authority on that.
(10:25):
But yeah, we have very large team devoted just to
the development of Kotlin, the language, tooling
around it and so on. So maybe I. What other
languages, like you mentioned Clion earlier, do you still have C
support in this plugin or is that a different plugin? This plugin currently doesn't support
C, so right now we don't have any
(10:47):
c support in IntelliJ IDEA, so
right now it's not in our cluster scope. However,
the Clion team is still maintaining the
fork of the Alder that was originally
Google's plugin for IntelliJ and Clion, but they
will be maintaining it only for clion for the time being. The
(11:09):
general direction we want to go is to have really a single
plugin that works for IntelliJ, for Clion, for.
For all our IDEs. Really? Yeah. So I was going to ask about
Webstorm as another example. JavaScript and TypeScript are the
most popular languages according to some metric. Yeah,
so they're not the most popular languages
(11:31):
to use with Bazel. However, at least among our
customers, I've gotten some interest for JavaScript, TypeScript, also
for Rust in Principle, Me and our team
would love to support everything. We just have to focus on the
most impactful use cases in the near term. So that
means right now this is JVM Go and Python
(11:53):
and these are the things that will be supported by the 25.2 release
and with them Intellij idea, Goland and Pycharm. Yes.
And so phpstorm. Hard to imagine that that
gets on the roadmap ever. Rustrover and webstorm could happen
Sea lion when that team is ready to integrate with
(12:14):
you. Ruby mine. Hard to imagine that ever happens. What
about. I know one company that uses Ruby with Bazel.
Yes, I think. And one company that uses Perl with Bazel.
So that's something. Yeah, well, I guess maybe.
Interesting technical insight. I'm certainly curious how
much of the plugin is language specific and how much is generic to the
(12:36):
platform. Like I imagine you integrate with the project model and the project model
is language agnostic. The project model are unfortunately
very language specific. We have project model
for Java that is
mostly reused by Kotlin and
Scala because they all integrate with Java. And actually
(12:59):
this Java project model has been a huge
pain point that we only were able to solve
very recently. Is it because it wasn't expressive enough to
represent Bazel's dependency graph? That's part of the problem
and that's also not the fully solved problem
yet. But yes, the main
(13:22):
problem here was when you ask Bazel for
sources that belong to a target, it will give
you a list of source files. The Java
plugin and the Java project model in IntelliJ
only allow you to list directories
to which sources are attached. And
(13:45):
one directory of sources in Java could only
also belong to exactly one IntelliJ module.
So you have two problems here. Bazel can give you
lists of sources that do not match all the sources within a
directory. Every time you don't use a glob,
that's already a problem for the Java project model. Yeah,
(14:08):
especially if within that directory you have
multiple targets. Yeah, like a common case. I guess. Actually
in Java it's typically not. You typically don't put tests
in the same folder with production sources. Right. Because like
you can always discourage that. Yeah. And well, I still
encourage our customers to use directory
(14:31):
level globs to define their JVM targets
because that will still give you better performance in IntelliJ.
However, it's. As of the next release, it will not be
requirement to have a working project model at
all. Okay, yeah, that's great. Because Glob does have a
performance penalty. In Bazel.
(14:53):
And a performance benefit IntelliJ essentially. So,
yeah, I think you wanted to talk about, well, why do we even
need a Bazel plugin for
IntelliJ, right? Yeah, I think there are
a lot of editors and IDEs, and certainly one thing is that
if you have to like your team had to do a bunch of effort for
(15:16):
the IntelliJ platform, so then somebody has to go do the same effort for Visual
Studio code and Visual Studio and Atom and a bunch of other
editors. Yeah. Though the efforts might
be in different points. So
one of the main efforts problems we have to solve
basically is the sync. So we
(15:39):
have a project model in IntelliJ. Actually, for every
language we have a project model and we have to have a
separate different project model in Bazel.
And now we need to match those project models.
But why do we have different project models in the first place?
So we're solving different problems in the IDE and
(16:01):
in the build tool. In the build tool, we want
consistent build, we want a reproducible build. We
want to automate taking everything that goes
into the final product, the final target, whatever you want to
call it, and make sure that is built
consistently in the editor, in the ide. Well, we
(16:23):
want a way to run that, sure. But
primarily we want to get live up to date
information on how is my code doing? How am I
doing in my code on the file that I have open right
now, is there, am I going to break anything by
adding this line? For instance, now I could
(16:45):
just call Bazel and say, please build this file and
oh, oops, something invalidated three
levels of dependencies or something and I'm going to wait five minutes
or something. In not so good cases in
IntelliJ, we avoid that by just looking
at the direct dependencies of this file in
(17:08):
terms of symbols, basically on dumb down level.
So we want to see if those all the symbols
that my current file depends on resolve.
And I can simulate the
compiler in my editor. So IntelliJ
doesn't run a presentation compiler in the background or
(17:31):
anything. It builds an ast. So sort of
that represents your code. And this AST can actually
also represent errors. So it can tell you, okay,
you have some error in your code here, but that doesn't mean I won't
tell you where the others are, other errors are, or
that you cannot start typing and fix
(17:53):
something else in your file at the same time or in another file. You can
get all the errors and warnings, you know,
inspections, improvements. You could make life.
Yeah, so this, this concept exists for all Languages and
is usually implemented with a language service or at least
in the last few years it feels like that's been the case. Which is protocol
(18:15):
that like Microsoft owns and it allows you
to, you know, like Clang for example has a clang D which is a demon
that speaks this language server protocol which means editors can ask it for completions
or error diagnostics. I think you're saying like this is not
what IntelliJ does. It has a different. Doesn't use that property. IntelliJ
predates the LSP the language. Yes. By 15
(18:37):
years or something. Yeah, yeah, exactly. So it
does it in its own way unfortunately. Some might say
by actually re implementing basically the whole logic of the
language of the compiler, type checker and whatnot. Yeah. So when
there's a new version of java, when like Java 21 came out there was a
lot of work to do I imagine to support it. Yeah, any new version of
(18:59):
any language incurs some work there. It's.
Yeah, it depends on what the language does. I was involved in
Scala a long time. For a long time. For first
six years at JetBrains and Scala 3 was
always on the horizon there. I don't know. In 2019
we went to, we
(19:21):
convened to hack on the Scala 3
support 2025 I think the Scala team is
now final aiming to have a complete Scala
3 support. Well Scala 3 is a moving target but yeah, that's just
as an aside. So yeah, there's a lot of work to do there.
Unfortunately basically all, all of it has to be done by
(19:43):
JetBrains. It's not usually the case that
the language authors will contribute this.
So for Scala is there a language server protocol implementation? There is
and that's actually interesting segue.
The implementation of this language server protocol for
Scala is based on the build
(20:06):
server protocol. So in the Metals Scala
language server they decided they don't want to re
implement the Scala type
checker. Everything that has turned out to be very hard
to nearly impossible in our experience. So instead they
just ask the build tool to run an
(20:28):
incremental build and give you the output, give you the
list of errors and warnings and those will just be pushed
to the editor via lsp. So there's a two stage
architecture there. This build server protocol
could in principle be implemented by any build tool.
Initially it was in Scala implemented by Bloop, which
(20:51):
was a kind of wrapper for build tools that would
just optimize the
incremental compilation part so you can get sub second
feedback time on the current files or
targets that you're building and that works okay for
a language server as long as you don't have
(21:13):
funky edge cases. Now, I was involved
in the design and implementation of this build server
protocol, also in Intellij in the Scala plugin at the
time. In the Scala world, it did gain some
traction. So basically every Scala build tool implements it by now
and some use it to integrate with IntelliJ.
(21:36):
And this kind of spawned, well, initially just
an intern project. What if we tried to implement the build
server protocol for Bazel? So we did that and the
first results were quite promising. So things
basically worked right, just. Well, the path from
basically work to thing that works in
(21:59):
enterprise production environments is actually quite long. But this
was the seed of what we used to build the new Bazel plugin
initially. So I would say we had the ambition
of making IntelliJ plugin that other
build tools could also integrate with. So abstracting
away the how do we set up the project model
(22:21):
exactly, because that is a huge
pain for any build tool author that wants to integrate with
IntelliJ. So yeah, that was our ambition. We followed it for quite a while,
but as we weren't making
progress, we would have liked just on the Bazel side,
due to aforementioned issues like
(22:44):
actually the project model and very many
details how we integrate with IntelliJ. But also
how do we get information from Bazel into intellij
and like, the more details we add, the
more troublesome it gets to figure out
how exactly do we model this build tool agnostic way.
(23:08):
So we basically just decided, okay, let's rip this out
and just, just support Bazel and tries to support Bazel
really well. You know, at the time the build server protocol was
created, we kind of had the issue that
everybody in Scala was creating a new build tool every half
year or so and it was basically impossible to
(23:30):
keep up with that on IntelliJ side. Realistically,
one person can barely support one build tool. That was
me. I was supporting SBT mostly and not as
nicely as I would have liked, but now the situation is a
bit different. There's more, I would say consolidation
on bigger tools like Bazel.
(23:53):
And so yeah, we want to focus on Bazel. Maybe we'll
figure out how to abstract some of this later
on, but that we'll do that when we need it.
Great. Okay, well, first of all, since we're live streaming, we have a few minutes
left. If anyone listening in on and signed in with
YouTube or LinkedIn, please send us some questions if you have them. We'd love to
(24:15):
take live questions and Keep it interactive. I was just showing if you're on video,
the build server protocol. There's a website for it you can look
at. I also like you mentioned that it was kind of a
workaround because the Scala compiler is slow but you want to get
sub second interactive feedback in the editor. And so
making a compiler do that is a different task from
(24:38):
making a compiler do one off builds on the command line.
There's a great talk that Anders Hejlsberg did, who's the author of
Typescript and C and Turbo
Pascal, I think like you know, one of the preeminent
compiler designers of our time. I'll put that in the show notes too. He
was, he did sort of a lunch talk with Seth Juarez and like
(25:00):
went into the details of, of how you build such a thing, which as a
compiler geek myself I found really interesting. And yeah, like some, some
compilers have that. I think LLVM is another example and it's
part of why clangd is possible is that it like the
compilers built with that sort of query model in mind and not only
with like you know, produce the final executable or the,
(25:22):
the object file or whatever it is the compiler outputs. So I see why it
was the build server protocol sounds appealing and I'm glad that you
decided to cut scope so that you could get something out that works for
Bazel for sure. Yeah. One other link that I'll put in the show notes,
we decided not to try to do a live demo right here in the but
you can go watch a demo. This from your co worker at Jetbrains
(25:44):
and I think he's showing the current version of the plugin. Is that right? Yes,
a very recent version. Okay. So yeah, if you want to see how this actually
looks in practice, like this is a great sort of getting started with Bazel Java
video and it includes bringing in third party dependencies from the
Maven ecosystem and then getting them to show up without the red squigglies
and have completion and things like that working in the ide. Right. Yeah. I
(26:05):
also recently did a similar talk at a conference. So I think
now with our plugin it's fairly easy to get started on simple
projects with Bazel. So I will still need a bit more
material for onboarding people, but it's
not a huge pain to just start a JVM project,
add in some Python, add in some shell scripts, wire it all up
(26:28):
in a single build tool. So I think Bazel
will be ready for the desktop for the
casual user quite soon. That's awesome. Yeah, I mean, I'll make a
plug also for like, we have an init command that gives you like a workspace
that's ready to go with a bunch of important features, like having the Tools directory
and like the initial requirements file setup. If you're doing Python,
(26:52):
like, there's. There's some steps to go through, even just for Java to set up
rules, JVM external and get the Maven compilation set up. Yeah, I
mean, maybe, maybe we can do an extended demo of this sometime later.
I should also point out, while we're looking at some links, you've got a bunch
of posts on the Jetbrains blog that I follow and you mentioned you're working on
another one right now. Now, probably anybody interested in this should go. Is
(27:13):
there like a particular post that you think they should read or just like, should
they subscribe to your future posts? They should read the post that I'm
going to post in roughly two weeks on the new
the GA release. It's mostly about what features
we added, but I think it marks a major milestone for
us. So this is the point where I expect
(27:36):
most people will be able to roll this out in their larger
companies. It's already been rolled out over a
fairly large code base with like 6,000 developers at one of our
customers and works smoothly enough.
I would say. Naturally, Miles on it. It's no longer bleeding edge.
Exactly. Exactly. Cool. All right, well, we did get a couple of questions. Thanks
(28:00):
for. Thanks. Those who are listening. So from Sergey going to be
released anytime soon? You mentioned maybe in a couple of weeks, but definitely
with 2025.2. Is the releases targeted? Yes,
two, three weeks, something like this. And then the other part was, is it going
to remain open source? I expect most of it's going to
remain open source. The core definitely. We may or
(28:22):
may not add things that are not open source
or certain features may be not open source. So
do you have like an internal repo that you sync to GitHub and
it has a superset of the files? Yeah. So it's actually part of the Intellij
Monorepo. And right now it gets synced completely to
the Hirsch Gotten repo. I guess you can add that to the notes.
(28:44):
Yeah. And you can also contribute directly
to the Hirsch Gotten repo. Great. So yeah, you do accept
contributions. I'm just curious, which tool do you use to sync
the changes between the monorepo and the GitHub? I think it's some custom tool.
Okay. I didn't set it up. Yes, you're accepting contributions. Have you
had contributors on that repo yet? I guess I can go click on Insights and
(29:06):
see who's contributed. Quite a few people.
Cool. Yeah. I'm waiting for GitHub to crunch the latest data.
Just for me. Yes, just for you. Hang
tight. It says you will also find many contributors from
Google in there because we merged part of the, we call it
the OG originally, Google's Basel plugin
(29:29):
into this one. Yeah, so the answer is.
I guess I should really look just in the recent history because this Hirschgarten
repo has commits going back to 2015. Yeah, the
actual start of the project was maybe
2020 when we had these experimental internship
projects and we only really started going in
(29:51):
23. Really? Yeah. So yeah, I mean it looks like
you've got a couple dozen contributors on there, which is great.
So from multi. Very related question. So like,
obviously it's easy for me to send you a PR to that repo to fix
a spelling mistake, but what if I wanted to like, you know, add typescript
support? Let's say, like, if you wanted to add a new language
(30:11):
ecosystem, could people outside Jetbrains manage
to do that and upstream it? Or do you think that's something only Jetbrains could
do? I think people outside could do it with
some help from us. It's complicated.
So if you say I just want some basic support
that will work on my project, that will be
(30:33):
something that an intern can deliver in
a few weeks to months. If you want something that works
on an enterprise scale project, this will be
at least 3, 6, 12 months.
So if somebody did want to add support for their language and
was able to get to that first quality bar you mentioned, do you think that
(30:56):
kind of contribution could be accepted? Or do you. Does this. Does your repo really
only want the enterprise quality? No, we take
like proofs of concept, I would say too.
We'll probably put them behind a feature flag until they're stabilized. But we have
had proofs of concept in there for a long time under feature
flags. Okay. So yeah, that can be a basis for
(31:18):
further development or just the rewrite if we decide it
doesn't work this way. That has happened for Go, for
instance. Okay. So I guess the answer is if your
organization really wants to commit some resources to adding support for another
one of the JetBrains IDEs.
Rust Rover is probably a good example where like Rust is actually like
(31:40):
increasing in popularity. It's an ecosystem that would be great to have support for.
Yeah, cool. And then related how. How much of the code that's
required to implement that is open source. Like is there every
Everything's in the Kirch garden repo that somebody would need. If they wanted it. What
might be a bit tricky if you're targeting a closed source IDE
like Clion, Rust, Rover, I think
(32:02):
then it will be hard to find the
APIs you need to integrate with. Sure. So you'll need some help from
somebody at Jetbrains if you want to do these things. Yes.
Yeah. I mean forever ago when I was working at
Google I actually had a project of contributing a
Jetbrains plugin and there was some nice person over there who
(32:24):
helped me figure out the model for interacting with the test
result pane because we were writing our own test
like JavaScript Test Runner. It ended up being called Karma, but I
appreciated having that help to see some of the internal APIs for sure.
Awesome. So I think we covered everything that we meant to cover. We know
why we need a special plugin for the editor, especially for Intellij
(32:47):
because it has its own special project model. The stuff is now
almost shipped and within a couple weeks, probably most people
listening to this, you'll have like a week or less hopefully before there's
a GA release, but they could certainly go and try the pre release if they
want to see what this looks like or else watch the demo video. Today's release
or last week's release will be very similar to the GA
(33:08):
release. If you're using the 2025.2 EAP
versions of IntelliJ, great, but we might add another feature or so.
Okay, well we should definitely keep watching your blog posts for what those
features are and I think the call to action here is
Go, give it a try. If you don't use Intellij already,
then give it a try anyway. Python,
(33:31):
Java, Kotlin, Scala and Go.
Yes, if you develop in one of those languages, come give this a try
maybe. I do have one final still behind. A feature flag by the way, but.
Okay, so for Go it's more experimental so
Go will be included in the ga, yes, yes. Okay, meaning something's
up there I guess. I do have one question specifically for Go, which is that
(33:53):
the GO compiler added something called Go Packages driver as a way
to say I know better where the third party packages I've put are. They're not
just on the Go package path in like the standard locations. And of course Basil
loves to put things in weird locations. Do you still need the Go packages driver
thing for the Golan support? Honestly, I don't know.
Okay, well I know that thing has been difficult to use,
(34:15):
so I'll be. Excited if it's completely outside of my personal
area of knowledge stuff. Okay. All right, fair enough. The answer
is we're not sure. So yeah, I guess we should all go give this stuff
a try and then come contribute back on GitHub like
like good consumers of open source do.
Yes, please do. And we also are happy to receive
(34:36):
your bug reports on our YouTrack. Okay.
Which also add in the notes. Yep,
that sounds great. So yeah, I'll make sure we include all those links on there.
And thanks for coming to tell us all about your work and really
excited after a few years of of what turned out
to be a difficult project of let's just make a new plugin. It's time to
(34:58):
launch. Yes. Congratulations. Thanks for having me and thank you.
See you all next time.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
CrimeLess: Hillbilly Heist
It’s 1996 in rural North Carolina, and an oddball crew makes history when they pull off America’s third largest cash heist. But it’s all downhill from there. Join host Johnny Knoxville as he unspools a wild and woolly tale about a group of regular ‘ol folks who risked it all for a chance at a better life. CrimeLess: Hillbilly Heist answers the question: what would you do with 17.3 million dollars? The answer includes diamond rings, mansions, velvet Elvis paintings, plus a run for the border, murder-for-hire-plots, and FBI busts.