![]() Among other things, we are working on a new-generation Kotlin compiler that will run much faster than the current one. To make a smart compiler run fast you certainly need to optimize every bit of the toolchain, and this is something we are constantly working on. Can one be smart and fast at the same time? The Kotlin compiler figures out a lot of stuff on its own to keep the code clean and type-safe at the same time. ![]() And this is why we have smart type inference and overload resolution algorithms that support lambdas and extensions function types, we have smart casts (flow-based typing), and so on. Among other things, this means that we don’t want types all over the code. Then, we also want clean readable code without unneeded noise or ceremony. So, we want static type safety to catch bugs early and get precise tooling (completion, refactorings and find usages in the IDE, precise code navigation and such). Kotlin is designed to be used in an industrial setting where projects live long, grow big and involve a lot of people. This means that the compiler has to be pretty smart, and here’s why. It is usually a complicated tradeoff, and in Kotlin, we decided in favor of clean readable type-safe code. The first two factors are kind of obvious, let’s talk about the third one: the smartness of the compiler. How smart your compiler is: whether it figures many things out without bothering the user with ceremony or constantly requires hints and boilerplate code.How much your toolchain is optimized, this includes the compiler itself and any build tools you are using.Codebase size: compiling 1 MLOC usually takes longer than 1 KLOC.There are generally three big reasons for long compilation times: Compilation pauses break the flow and make us feel stuck, stopped in our tracks, unproductive. Compilers are smart pieces of software but healthy human work schedules is not what compilers are smart at.ĭevelopers tend to be happier when they feel productive. While both situations arguably have their pros and cons, I believe it’s best to take breaks consciously and not when your compiler tells you to. If time-to-test is too long, you start browsing the social media or get distracted in some other ways, and lose track of what that change you made was.If time-to-test is too short, you are never forced to get some coffee (or a sword fight),.This is often referred to as time-to-test. This post is about one very important aspect of every developer’s life: How long does it take to run a test (or just hit the first line of your program) after you make a change in the code. Let’s start with the obligatory XKCD comic #303 In this post, I’ll tell you about a huge and largely invisible part of Kotlin which makes it compile much faster on relatively small changes that happen a lot in an everyday run-test-debug loop.Īlso, we are looking for Senior Developers to join the team at JetBrains working on fast compilation for Kotlin, so if you are interested, look at the bottom of this post. Incremental compilation across module boundariesĬompiling a lot of code fast is a hard problem, especially when the compiler has to perform complex analyses such as overload resolution and type inference with generics.Can one be smart and fast at the same time?.Let’s start with the obligatory XKCD comic #303.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |