EPISODE 1767

[INTRODUCTION]

[0:00:00] ANNOUNCER: Rust is a systems programming language created by Graydon Hoare in 2006 and first released by Mozilla in 2010. It's designed for performance, safety, and concurrency with the focus on memory safety without a garbage collector. Rust's ownership model ensures safe memory management, making it viable for tasks that require control over system resources, such as embedded systems, WebAssembly, and game development. RustRover is a dedicated Rust IDE that was created by JetBrains to support the growing popularity of Rust. Vitaly Bragilevsky is a developer advocate at JetBrains and has expertise in Rust and IDE tooling. He joins the podcast with Lee Atchison to talk about Rust, the current Rust developer ecosystem, using an IDE to make Rust more accessible and more.

This episode is hosted by Lee Atchison. Lee Atchison is a software architect, author, and thought leader on cloud computing and application modernization. His best-selling book, Architecting for Scale, is an essential resource for technical teams looking to maintain high availability and manage risk in their cloud environments. Lee is the host of his podcast, Modern Digital Business, produced for people looking to build and grow their digital business. Listen at mdb.fm. Follow Lee at softwarearchitectureinsights.com and see all his content at leeatchison.com.

[INTERVIEW]

[0:01:38] LA: Vitaly, welcome to Software Engineering Daily.

[0:01:40] VB: Hi. Thank you for having me here.

[0:01:43] LA: Most listeners probably know what Rust is, but I don't think everybody does. For those who don't, can you start by telling me, what type of programming language is Rust?

[0:01:55] VB: Sure. Rust is usually called a systems programming language. When it was created, it was supposed to be used as a replacement for languages, like C and C++ with a low-level systems, jobs, something like implementing operating system drivers, or whole operating systems, and doing some what we usually call systems programming. Maybe that's why there is no garbage collection, for example, in Rust, and there are other tools for managing a memory, and it is really low level. But it turned out that it's not necessarily systems programming language these days, because it is used in all other domains as well, like web development, for example. Right now, it's more a general-purpose programming language. Or an interesting one in terms of programming language theory and stuff like that, and it's quite popular, I should say.

[0:02:55] LA: I always thought it'd be interesting to build a dynamic web application using C++. I used to use C++ way back in the old days. I've actually done some things with web apps with C++ many, many, many, many years ago. It's not as hard as you would think, but of course, the whole C ecosystem causes all sorts of issues that you have to deal with. Now, the whole idea behind Rust was to solve some of those problems, right? I've never used Rust. Now, can you tell me, how is Rust better than C and C++ trying to do the same sorts of things, since it's that sort of a language?

[0:03:35] VB: When you say better, that means that you are trying to compare these languages. Comparing languages is not something - from my point of view, it is not very productive. You're right. When I, for example, read the most famous book about Rust, which is called The Rust Programming Language, you just immediately get this feeling that they are trying to solve C++ issues. One of the most famous issues with C++ is memory management. It is very easy to introduce some error regarding memory access. You have a pointer, you allocated memory for it, and then you free double times, okay. That's the usual thing that comes up when you work with C++. 

Of course, there are techniques in C++ and in C how to avoid these errors. Rust makes it easier to avoid them by adding specific mechanisms for making it actually impossible to free memory twice, okay. This other thing. We have very thorough control on the memory management in Rust. Compiler knows exactly where memory is allocated, where it has to be freed. There is no burden of trying to remember this stuff from a programmer.

[0:05:03] LA: Unlike languages like Java and Ruby and other languages, it does it by keeping track of the memory usage real-time, versus cleaning up afterwards.

[0:05:16] VB: It does it by tracking it at compile time. This is very important. When you write code in Rust, you have to provide the compiler with sufficient information about these locations, memory allocation, and locations where you don't need that memory anymore. At compile time, everything is decided. Then you just run your program. There is no overhead in terms of runtime memory management here. Because everything was decided at compile time.

[0:05:51] LA: Interestingly, that it solves the memory management problem. Yet, it really never took off as a system programming replacement language. You don't see Linux kernel drivers written in Rust too often.

[0:06:03] VB: Let me disagree here.

[0:06:04] LA: Okay.

[0:06:04] VB: First, Rust was introduced as a language for Linux kernel, I think a year ago, something like that. It was introduced officially, so it is a supported language. For projects which are big enough, of course, it's very difficult and impossible and useless to rewrite everything to Rust. It is possible to implement something in Rust. Of course, there are issues with coexisting several languages in one project. In Linux kernel, you have C as the first-class programming language, and then some other languages which are not that first class. Still, it is possible. I don't know where we are going to be in 10 years. Chances are some parts of Linux will be implemented in Rust. I think it will be like that.

Of course, so it's not about replacement. I know that many C, or C++ developers actually don't like this attitude of Rust developers who try to persuade everyone to rewrite everything to Rust. That's not a good idea. The goal of programming language is to solve some issues and to write new software, to write new components of software. This is something we need Rust for, so we can add some code to Linux kernel, to make it safer in some cases, because of these memory safety features of Rust. There is no goal to rewrite everything.

[0:07:39] LA: Describe a sweet spot project. What would be a project that is right in the middle of the sweet spot of what Rust is good at, as well as what it's popular at.

[0:07:49] VB: It's difficult to choose one such project. When I say that Rust is popular for web development, I don't think it's the main application area right now. If you look at practical applications, we see for example, software for vehicles, they use Rust there, or some software for companies who run some Internet infrastructure, for example, proxy servers, or CDN applications. That stuff is also implemented in Rust. We can easily imagine some audio processing software implemented with Rust and get a lot of very good performance, and it's very nice safety.

[0:08:33] LA: And predictable performance.

[0:08:35] VB: Exactly. Predictable performance, exactly. Also, financial applications. We can do that in Rust. I know that Rust is very popular in blockchain technology for implementing things. All these applications are, well, I would say, they are pretty ready for using Rust as a programming language.

[0:08:55] LA: You mentioned web apps again. I know it's not the sweet spot application, but you say it is usable in that environment. Does Rust have a solid web framework, like Rails is for Ruby, or Django is for Python, or all the thousand different ones that exist for Java? Is there a web framework for Rust that works for web applications?

[0:09:20] VB: Well, there are thousands of them. Well, maybe not thousands. It's not that old like Java, but dozens for sure. Of course, if you compare them with those very old projects, like Ruby and Rails, of course, they are much younger and they are not that sophisticated. They're not that mature. There are a lot of them. What is interesting actually, there is a lot of research in this area. When people try to come up with new ideas, like, look, I would say that web is a sweet spot for us because, well, it is doable. Also, you can get amazing performance. In terms of performance, of course, it's incomparable with everything you've just said.

It's much better in terms of performance than Ruby, or PHP, or even Java. You have some big plus performance. Then, of course, you have this immaturity of ecosystem. But then, it takes a lot of years, like many years to actually to come up with something really winner in terms of web frameworks. We're not there yet in Rust.

[0:10:31] LA: It's just too young of a language really is the problem. It's not that there's any limitations. It's just a maturity issue.

[0:10:38] VB: Yes, yes. I would say so.

[0:10:40] LA: It makes sense. Where do Rust developers come from today? Are they typically ex-C developers that discover Rust? Are they ex-Java people that discover Rust? Or are they new developers? Who typically comes to Rust commonly?

[0:10:59] VB: This is a great question, especially because I have a very good answer. Look, they are mostly, surprisingly not C, or C++ developers. We don't see many C and C++ developers converted to Rust. In fact, we see a lot of Python and Java script developers coming into Rust ecosystem. This is very interesting, actually. They know how to use programming languages already. I would say, it is very difficult to start programming career with Rust. Rust as a first programming language in one's life, this is something - well, it is possible, but it is very difficult. 

If you already have some experience in programming, mainly Python and Java script as the most popular languages these days, then it's relatively easy for you to grasp several new concepts, especially about this memory management system. Then you are ready to write code in Rust. Those folks, I think in Stack Overflow developer survey, there is very nice diagram about people who are using one programming language and want to start working with other programming language. If we look at this diagram, it's very visible that Python folks and Java script folks come to Rust. I also see this on conferences, Rust conferences, they are full of people with this background, and not that many C and C++ developers.

[0:12:38] LA: Yeah. If I can read between the lines there for a moment, it seems like, if you're a native C, C++ developer, you've already bit the learning curve, so to speak. You already deal with the shortcomings of the languages and you consider them just things you have to deal with, and you already have your tools for dealing with them. Maybe when there's a religious language, religious war aspect to that as well, too. Bottom line is there's no strong motivation for somebody who is very knowledgeable in C and C++ to move to Rust.

There is for someone who's in Python or JavaScript to move those sorts of languages, to move to Rust, because predictability and performance is something that you may not see early in your career, but very quickly, you will start running into problems with predictability issues, depending on your types of programs you're writing and your applications you develop, of course. Very quickly, you realize that languages like JavaScript and Python, and Java and similar languages aren't very predictable and have all sorts of issues associated with them, because of garbage collection primarily. Does that make sense, as far as the rationale for why you've seen that? Or am I just blowing smoke with them?

[0:13:58] VB: Well, actually, I agree with you. This is exactly the case. In C and C++, if you work professionally with those languages, you know how to deal with those issues. You have linters, you have static analysis tools, you have a lot of stuff to get the job done without those issues. Of course, if you work with Python and JavaScript, you might want some more performance. One other thing here is that if you come from one of those languages, you're already exposed to some Rust, because Rust is slowly becoming the main language for implementing tooling for other programming language. We see that in JavaScript, where we have several JavaScript runtimes implemented with Rust, for example, Dino.

In Python, we have these tools, like UV, or package management, implemented package management for Python implemented in Rust. If you are using those tools, and you see how efficient those tools are, then you might think that it might be the case that it makes sense to learn some Rust.

[0:15:11] LA: Makes sense. Yeah. What's a competition to Rust? Is Go competition? Or are the use cases different?

[0:15:20] VB: Well, Go is definitely a competitor to Rust. Well, it's definitely visible. A couple of weeks ago, I was at Rust China Conference. I had a discussion about exactly this. Go is extremely popular in China. Rust is not that popular. Folks there say that, well, it depends on big companies switching to Rust. If some big companies start switching to Rust, and they use mostly Go these days, then this might be a signal for many others to switch to Rust as well. At least, this is doable. If you have Go in your projects, you can switch to Rust.

Other competitors, well, there are newer programming languages, like Zeke, for example, which sometimes which tries to solve similar problems to Rust. Both traditional and newer languages can be those competitors.

[0:16:27] LA: That makes sense. Let's switch gears a little bit. Let's move from Rust to RustRover. RustRover, of course, being the development environment created by JetBrains and for Rust project development. Tell me a little bit about RustRover.

[0:16:45] VB: At JetBrains, we had for many years, IntelliJ Rust plugin. It was a plugin for other IDE, such as IntelliJ IDEA, or [inaudible 0:16:55]. Then two years ago, maybe a year and a half, we decided to launch a dedicated ID. For JetBrains, it was quite a bold move. Because launching an IDE for new programming language, it can be risky. There were other tools available for us as well. Still, we decided to do that.

For us, it is a IDE, which allows you to do everything you might need to do with Rust. It's not only about writing code, but it's also about all other stuff that you might need. You can develop database applications. We have a support for that. Might be web publication. We have support for that. We have powerful debugger and all sorts of tools that you expect from a full-featured IDE. Yeah, so this project, we launched it one year ago. Now it's, I would say - well, for me, of course, for me, I am from JetBrains. For me, it is very important tool for doing Rust. There are others as well. Still, I think that there is a lot of things that make RustRover very useful.

[0:18:15] LA: I have to tell you, I'm a big fan of the JetBrains toolset. That's my main development environment is the JetBrains toolsets. I use personally, just for your reference, I use RubyMine, I use PyCharm, I use WebStorm. I also use DataGrip a lot. Yes, I use DataGrip as a separate tool versus the ones that are integrated in all the other ones. It's just my own personal preference, but everyone has their own preference. Anyway, I love the JetBrains tools, but I've never used Rust, and so I've never used RustRover. If I did start to use Rust, how would I find RustRover compared to those other JetBrains tools that I may be familiar with?

[0:18:57] VB: Well, first and foremost, it's a tool which is built on IntelliJ platform, which means that everything you already know. You know those shortcuts, you know how to change your color themes. You see all familiar panels and tabs and everything is very familiar to you. The only new thing is actually, your experience when it comes to coding in Rust. Everything else is just what you're used to. We actually see that those folks who have prior exposure to JetBrains tools, of course, they like RustRover, because it's very familiar to them and it gives them new opportunities regarding Rust.

[0:19:39] LA: Right, right. If you're not familiar with the tools, what other tools might you be using for Rust? Why is RustRover better?

[0:19:47] VB: Personally, once again, about this word better.

[0:19:53] LA: Avoid that word better. What are some other tools that people use and what do you offer that's different than what they offer?

[0:20:02] VB: Yeah. Mostly, we have their so-called rust-analyzer, which is LSP implementation, implementation for language server protocol. This implementation is used in almost all other code editors, like Visual Studio Code, or Neovim, or Helix, or other editors available out there. All of them have extensions or plugins based on rust-analyzer. RustRover has its own code analysis engine, so it doesn't use Rust-analyzer. We basically written front-end part of Rust compiler and analyze everything by ourselves.

In terms of features, I don't think that we, or Rust-analyzer have more features regarding Rust. What we actually promote with Rust-Trover is the overall experience. Because, well, of course, you need to write code. You need code completion. You need some error highlighting. You need automatic imports, for example, so you don't want to do some boring stuff. Both rust-analyzer and RustRover provide them. Because, well, this is basic features when it comes to writing code. Then you also need other stuff. You need a debugger, and we have it at RustRover. We have, as I said, a database support. We have tools for looking into your memory and analyze what's going on in memory. We have a profiler.

A lot of stuff which is already available in RustRover. it is out of the box experience that we actually deliver. Then, of course, we provide a lot of small features. We are trying to make difference with them. For example, one line of development that we actually have in RustRover is supporting developers coming from other programming languages. In technical terms, we implement our own parser for Rust code, which is very permissive. We allow all sorts of constructs which are not actually Rust. But we can parse them, we can analyze them, and we can suggest fixes.

Well, we know that Python developers coming to Rust, they are used to some things like, I don't know, list.ad. They're adding elements to a list. We know that they meant to use vector, which is ubiquitous in Rust. We know that, well, it's a good idea at this location to suggest changing their code to using vectors, right? Or in C++, there is increment operation, operator++. There is no such thing in Rust. We know that, well, of course, if you write ++, chances are you want to have something like, +=1, which is a Rust way to do that. A lot of small features, how we try to understand what was intended. We suggest fixes.

[0:23:18] LA: One thing you didn't mention, though, which actually, some of the JetBrains does focus a lot on is, well, you started getting to use your AI automation system. Some of what you're talking about is part of that AI ecosystem. You have within the JetBrains universe, a pretty powerful generative AI environment in general. I'm assuming that same environment that's available in RubyMine, PyCharm, etc., is also available in RustRover. Can you talk a little bit about that ecosystem, what that provides?

[0:23:54] VB: Yes, we have the same system, which is called AI Assistant. It works across all our IDEs. The goal of AI Assistant is to integrate AI with your IDE as much as possible. We know these days, like I am old school guy. I'm not a big fan of AI. I realized that it really helps a lot in many cases. The goal of any professional should be like, if there is a tool, well, let's apply it. If it helps, why not using it, right? We have this AI, and then we work on integrating it into basic software development workflows. Of course, it can generate code for you.

We have several ways to ask AI Assistant to generate that code. Of course, we have chat, which is ubiquitous these days. It is also, the most recent development, which is not - I think it is not released yet, but it is available in early access previews. When you just write your inside your code, just some basic words, implement this and that, and then we generate code from this instruction. You don't use additional tool, right? You write exactly in your editor, and then you get the result. Very, very cool feature, and it simplifies everything a lot.

If you've got a mistake, some error in your code, then we can ask AI Assistant to explain that code. If you want to do some refactoring, we can suggest you a refactoring. Then IntelliJ platform was famous for refactoring for many years. Now, we integrate these capabilities with AI Assistant. We know that in many cases, AI in general, it can give you wrong recommendations, or it can break your code. If you integrate AI Assistant with powerful refactoring tools, then you can make it easier to come up with correct code as a result of applying AI. That's what we do in RustRover as well.

I would also mention here, we have code completion. One recent addition to AI tooling is so-called full line code completion, where you can run - so, we run local model, local element to generate code for you. This is something which doesn't require accessing some external servers, AI providers. It runs locally. If model is able to suggest something, then we show it in your code. You can either apply the suggestion, or refuse applying it. Yeah, these are main stuff, main idea, as I said. Integrating AI into basic software development workflow. This is what we do. We do that in other tools as well, but we also do that in RustRover.

[0:27:09] LA: I'm very impressed with your AI tools. I've used several of the different GitHub's tools. I've used Amazon Q, which is its own set of pros and cons. I settled on using the JetBrains AI, not only because of its integration. I mean, Amazon Q integrates with JetBrains too, but not only because of its better integration, but because it seems to one, generate seems to be fewer incorrect answers in context, because it seems to know the context better. Two, it tends to generate examples based on, again, context awareness of what you're currently doing. It'll even do things like, when you suggest to write a sample of a code segment, it'll write it using variable names and naming structures that's consistent with what you're currently working on. A lot more likely, it's compatible and be able to plug it in and all that stuff.

That all comes back to, you have a pretty deep context aware knowledge of the developer's environment at the time you run AI. I do a lot of AI development, so I know how hard that is to do. Reg isn't easy and things beyond reg is very, very difficult. How deep is your context aware capabilities today? Where do you see that going as far as improving your context awareness to be able to do even more interesting things?

[0:28:40] VB: When you write something in chat, AI Assistant chat, we add a lot of different information about that, because we know that information from your project configuration files. For example, in Rust, there is Kaggle TOML file. From that, we know that you already use this and that dependency. It means that we can provide this additional information, without you mentioning it explicitly. We add that information implicitly. We try to come up with mostly as full context as possible.

These days, I think the main issue with providing context is just about size. It's impossible to load just millions of bytes of context, right? One of the things we do, we try carefully to limit that context. We also try to include as relevant information as possible.

[0:29:42] LA: For instance, whatever editors you have open, the code for those editors are likely things to be included into the context of an AI request, or as well as the configuration. You know that they're writing a Python app versus writing a C++ app, or they're in an HTML file, and so you know they're writing HTML, or JavaScript, or CSS, or something like that. You know that context and you provide as much of that as you can, but based on where the developer is. You could ask the exact same question while editing one file compared to a completely different part of your application, and you'd get a completely different context associated with that.

[0:30:25] VB: Exactly, exactly.

[0:30:27] LA: The other tools tend to do that too. But I don't find they do nearly as good of a job as you do on that. I think you're saying, it's probably related to the IntelliJ back-end knowledge of what you have with the development environment. You seem to have a really good knowledge outside of the AI environment of what the code is that's being worked on currently, besides just open editors and things like that. You tend to include that, and I really find that - I guess, I'm saying I'm impressed with how you do that and what you're able to accomplish. I guess, the follow-on question I would have is you already do a great job there. What's next?

[0:31:04] VB: Well, we have a lot of research going on inside JetBrains, especially in terms of AI and additional things that we can do. You mentioned this deep knowledge about the context. I think it comes from research as well. It is very difficult to choose whatever goes to that context. We compare different approaches. We try new ways to integrate that. I don't think that I actually - fully aware about particular road map that we have. I think it is also, it's something that it shouldn't be published because it's part of the game in this area, right?

What I know for sure, from the side of RustRover team. What I know for sure is that we also try to find the solution to this problem. How to make AI better at Rust? How we can help Rust developers to walk around their error messages, for example. This is something what we are thinking about. We can use a lot of traditional tools to explain errors, some sort of highlighting, some special sorts of highlighting, which is directly related to what's going on in Rust code. Then we also think, how we can help in terms of AI to explain that error. Maybe how to ask AI to add additional details, which are more relevant for us and maybe less relevant for other programming languages.

For example, in Rust, it is important, as we discussed earlier, this stuff about memory safety, memory management. Whether you copy data, or clone it, or want to avoid that stuff. It might be a good idea while explaining errors to provide additional detail about how to avoid such situations. This is something that we are focused right now. Because we would like to see AI not as a general tool, but also, as a tool targeted at Rust developers. That's what we're doing in RustRover team.

[0:33:37] LA: The context of where language aware, of course, yeah, that it's basically what you did. That all makes perfect sense. One of the things that I do notice, which I like is, whatever tool I'm using, I tend to have access to the parts I need of other languages when I need them. For instance, when I'm using RubyMine and developing a Rails app, or I'm using PyCharm and I'm developing a Django application. I still edit a lot of HTML files, JavaScript files, CSS files, and all of the environment I need to develop that, and by the way, all the AI support I need for that is all available to me. That's actually wonderful, to the point where I only go to something like WebStorm when I'm doing a heavy JavaScript specific project for our front end. I only use WebStorm for that.

Otherwise, all the other front-end editing that I do, I'll do within the RubyMine, or the PyCharm environments. That's a great way for all that to work together. DataGrip does the same thing. What's interesting is it's made the lines between these tools a little bit blurry, right? When should you be using WebStorm versus RubyMine? When should you be using RustRover versus WebStorm, or pick another tool? When should you be doing that? I know JetBrains has gone pendulum shift, maybe is a great way to say it, on this topic before. For a long time, JetBrains focus was on creating another tool, creating another tool, creating another tool. When you started doing RustRover, you were creating a tool for Rust. You've done the same thing with Ruby and Python and everything else as well.

Now you're swinging the other way. You're looking at integrating all these tools back together again into a single development environment that can be shared and used. What I'm leading to here is a discussion about your project called Fleet. Can you tell me what Fleet is and how it represents the shift and where you see it going and where do you see JetBrains going with it?

[0:35:54] VB: First, I should mention that besides those separate tools, like PyCharm, or RustRover, we also have IntelliJ IDEA Ultimate. There, you can install all those plugins as well and have exactly the same experience. You can install a Rust plugin into IntelliJ IDEA Ultimate, and then you can work with Java, Kotlin, or Rust. You will have the same experience as in RustRover. It's up to you whether you want a stand-alone tool, or you may want to have everything included. Here, you choose whatever works better for you. I have IntelliJ IDEA Ultimate with almost all plugins installed.

Today, I was writing code in Scala, for example, with our IntelliJ Scala plugin. I have Rust installed there as well. If I work on just precisely on Rust project, then I would choose RustRover, just because when you create new project, you see only what's relevant to Rust development. When you have those actions, or quick fixes, you just see whatever you might use for Rust and not anything else. It's personal choice. If we are moving to Fleet, then with Fleet, there was a little bit different idea behind it.

First, Fleet is polyglot development tool. Some time ago, I published blog posts about polyglot development in Fleet. There was a very funny project there where I tried to use as many programming languages as possible. I end up with a dozen of them, almost all languages supported by Fleet. It was microservice application, where different microservices are implemented in different programming languages. There is Rust there, there is C++, there is C Sharp, and also JavaScript and other languages as well.

This development is much easier in Fleet. Because you use exactly the same interface, you have a single editor. On top of that, with the so-called smart mode, if you enable it, you don't have to. But if you enable it, you get much more sophisticated support for other programming language technologies. Not just basic editing stuff. The idea behind Fleet was to make this very smooth experience when it comes to work with many programming languages.

Fleet is under preview right now. It's not a released product. It is available for free for everyone, because it is a preview, so everyone can try it. It uses very lightweight UI. We can see the Fleet as a platform for experimenting with UI. We know a lot about UI, for example, in a couple of years, we implemented so-called new UI for IntelliJ IDEA and other IntelliJ-based tools. We're experimenting much more with Fleet. When you have not yet a product, not commercially released product, you can experiment a lot.

We tried to find new horizons in UI for software development. This is Fleet. Many languages and new ideas in UI, making it, for example, we have key maps there. When we were developing key maps for Fleet, we tried to make them as smooth as possible for particular operating systems. If you work on a macOS, then you are used to use some particular shortcuts for any other applications. We respect all that in Fleet. The same for Linux and Windows, okay. Big, huge experiment in this area of editors for software development. There are many others. We try to make our own, very new project.

[0:40:21] LA: This actually answers one of my follow-on questions too, I think. Let me see if I can get this right. The follow-on question was, how does Fleet compare to IntelliJ IDEA, which is your universal base product that's language independent and has all these plugins you were talking about. It sounds like, the way to think about it is the universe of IntelliJ tools, whether we're talking about IDEA, or we're talking about RubyMine, PyCharm, RustRover, etc., they're all in the same class. They all work together. The difference isn't whether or not you can program an HTML in one, but not in the other. The difference is which ones do they focus on? RustRover focuses on Rust, yet you can still do Rust development in other environments.

Fleet is different than all of that, because the idea behind fleet is to try and create a new environment with new ideas and new thoughts that are different than the way people have used the IntelliJ tools in the past. Is that a fair way to compare it?

[0:41:27] VB: Yes. Also, we don't try to include many IntelliJ idea features in Fleet. We are not trying to re-implement them for Fleet. It's not our goal. We know that some developers prefer feature-rich environment, where you can access almost everything with a shortcut, and you have menu item for everything, basically. We don't do that in Fleet. It's not only about being new. Of course, it's new. But it's also about providing new experience in terms of chances are many developers just don't use those advanced features. We try to distinguish. We have integrated development environment with everything included, with everything implemented, new features every month, new additional tools for you, and then something which is more basic, but it might work better for many developers out there. Those who just don't need all those advanced features. We want to make the experience better.

[0:42:43] LA: Yeah, that makes sense. This has been a great conversation. I want to thank you for joining me today. Thank you for coming on Software Engineering Daily.

[0:42:53] VB: Thank you. Thank you very much.

[END]