yole

The list of third parties your data may be submitted to is actually disclosed on a page linked from the data collection and use policy, and it's not a very long list: https://www.jetbrains.com/legal/docs/terms/jetbrains-ai/serv...

1) There's a "No" button in this dialog. It allows you to opt out from detailed data sharing, and you can still use the plugin. 2) In the next plugin update, we'll make it so that the detailed data sharing prompt is shown only in EAP builds of the IDE, and detailed data sharing is never enabled in release builds.

Just to clarify: No one is forcing you to use AI assistance features. All the deeply integrated features start working only after you explicitly log in to JetBrains AI service.

Just to clarify: 1) the AI Assistant plugin is not bundled, it needs to be installed separately; 2) once the plugin is installed, you need to explicitly log in to the AI platform.

Therefore, there's no risk of your code being submitted to a third-party service without you performing several explicit actions to authorize it.

To provide even more control over the use of AI Assistant at the organization level, we're adding support for per-repository opt-out flags in the next update of the AI Assistant plugin.

Actually there's no difference in terms of how sharing code is handled. Both Copilot and AI Assistant send your code to a LLM, and neither of those tools will use your code for training code generation models.

Could you please clarify which exactly part of the data privacy policy led you to believe that there are no restrictions on how the code will be used?

JetBrains IDEs ask you whether you want to submit usage data on the first startup, and honor your choice. You are not watched if you don't give an explicit, opt-in permission for that.

A lot of our work is open-source. You can easily see that our investment into improving our products, visible through the open-source repositories, has been steadily increasing every year.

If it was this easy, we'd have enabled this by default. Unfortunately by far not all UI freezes in IntelliJ IDEA are caused by GC, and ZGC is not a wholesale performance improvement even for those scenarios which do depend on GC.

No, IntelliJ IDEA doesn't use Graal at this time.

I'm not in contact with the research team and don't know which practical applications they have in mind, but as far as IntelliJ is concerned, we don't have any current plans to use the results of their work.

This is a research project. At this time there are no plans to invest into it on the same level as we're investing in Kotlin.

What exactly do you mean by "copyright and licensing"? JetBrains products do not violate any copyright or licenses from Oracle, and even if they change the license of future versions of Java, current versions are available for us to use. And Oracle has been investing into two different IDEs, NetBeans and JDeveloper.

Yes, we have an issue in our issue tracker for that already; will fix in the next update. Sorry!

We're now resuming the development of the Eclipse plugin, and you'll see new updates very soon.

You can't reuse UI code between iOS and Android. You do have the ability to reuse the business logic code (domain models and so on).

You can do isomorphic (server-side and client-side) rendering in Kotlin. For mobile UI, you can build native UIs in Kotlin for Android and for iOS, but the UI code will be different for each platform, built on the native API of the corresponding platform. At this time we have no plans to build a solution for reusing UI code between mobile platforms.

It's a bit different from a regular export/import relationship. An exported declaration is usually made visible to an unlimited number of clients, and an actual declaration matches a single specific expect declaration.

We've fixed this already; the fix is being deployed. The correct URL is https://github.com/JetBrains/kotlin/releases/tag/v1.2.0

In Kotlin, every module contains either common code or platform-specific code. I'm not sure why you consider the module-level distinction to be less clean than being able to mix common and platform-specific code randomly within a single file.

And your example shows that there is no way to verify that each module provides a consistent API.

It's not really "to make the IDE's job easier", it's to make it explicit that the given class needs to match a certain contract, and to make the validation errors more clear.

Even with Kotlin Native in mind, we have no plans to break Kotlin's backwards compatibility guarantees, and we do plan to support the new JVM features such as value types. So if Kotlin works well as a Java enhancer for you today, it will only work better in that role in the future.

There is now: https://blog.jetbrains.com/kotlin/2016/09/kotlin-netbeans-pl...

Yes, the plan is for Kotlin to replace Java at JetBrains. I don't see how the performance requirement follows from that. The performance of JetBrains products is determined far more by the implementation algorithms than by the compiler used to build their source code. Kotlin's performance is on par with Java, and that is all that JetBrains needs for its internal use.

As the post says, yield and async/await will be based on exactly the same mechanism. Either the entire mechanism will be implemented, or it will be postponed.

The Kotlin team does not have any near-term plans to work on the CLR backend. However, there are people at JetBrains who want one, so it's possible that it will appear at some point in the future.

This used to be the case a while back, but James is no longer working with us.

Kotlin does have lazy map/reduce/filter: those are available through the Sequence interface.