The Rider 2025.2 Release Candidate Is Here!
https://blog.jetbrains.com/dotnet/2025/07/24/the-rider-2025-2-release-candidate/

The Rider 2025.2 Release Candidate Is Here!
https://blog.jetbrains.com/dotnet/2025/07/24/the-rider-2025-2-release-candidate/
The ReSharper and .NET Tools 2025.2 Release Candidates Are Now Available.
https://blog.jetbrains.com/dotnet/2025/07/24/resharper-dot-net-tools-2025-2-release-candidate/
Previously I said local single-line code completion is the acceptable level of "AI" assistance for me and that JetBrains one was somewhat useful, only wrong half of the time, and easy to ignore when it is.
I've changed my mind.
See, I code primarily in TypeScript and Rust. Both of these languages have tooling that's really good at static analysis. I mean, in case of TS, static analysis is the whole product. It's slow, it requires a bunch of manual effort, but holy hell does it make life easier in the long run. Yes, it does take a whole minute to "compile" code to literally same code but with some bits removed. But it detects so many stupid mistakes as it does so, every day, it's amazing. Anyway, not the point.
The other thing modern statically-typed languages have is editor integration. You know, the first letter in IDE. This means that, as you are typing your code and completions pop up, those completions are provided by the same code that makes sure your code is correct.
Which means they are never wrong. Not "rarely". Not "except in edge cases". Zero percent of the time wrong.
If I type a dot and start typing "thing" and see "doThing(A, B)", I know this is what I was looking for. I might ctrl-click it and read the docs to make sure, but I know "doThing" exists and it takes two arguments and i can put it in and maybe even run the code and see what it does. This is the coding assistance we actually need. Exact answers, where available.
So, since I've enabled LLM completion a few months ago, I've noticed a couple of things. One: it's mostly useful when I'm doing some really basic boilerplate stuff. But if I wrote it often enough, I could find ways to automate that specific thing. It feels like this is saving me time, but it's probably seconds on a day.
Two: I am not used to code completion being wrong. Like, I see a suggestion, I accept it mentally before I accept it in the dropdown. I'm committed to going there and thinking about next steps.
And then it turns red because "doThing" is not, in fact, a method that exists.
And I stop working and go write this post because I forgot what I was even doing in the first place already.
I'm turning that shit off.
️ Rider and ReSharper 2025.2 Release Candidate Available
@itsfoss Sublime Text, or vim if I can't be bothered. I don't code often enough to justify paying for #JetBrains
IntelliJ IDEA 2025.1.4 Is Out!
#ide #intellij #intellijidea #java #jetbrains #kotlin
https://blog.jetbrains.com/idea/2025/07/intellij-idea-2025-1-4/
JetBrains builds brilliant tools. No question. But somewhere along the way, something shifted. The IDE that once felt like a sleek exosuit now wears more like a lead apron. Familiar, powerful but exhausting.
Remember Eclipse? I do. Grew up with it. Then grew out of it, death by poor developer experience. I see echoes of that fate in JetBrains, and it terrifies me. Not because JetBrains is bad. But because it was once… fun.
I've seen more memory leaks, heavier startup times, and codebases that feel like they took a wrong turn into a garbage collector. A "Hello World" project now needs 5GB If I leave it open long enough. It starts asking me existential questions.
My IDE now eats up 15GB with simple projects. Caches? Massive. Often useless. Builds that run clean in terminal break in IntelliJ until I do the sacred dance: Build → Rebuild Project or Invalidate Caches. It's a modern ritual. I now default to my terminal. It's honest. It listens. It doesn't pretend.
Plugin development? A labyrinth. Testing plugins is like chasing asynchronous shadows. Documentation is scarce, SDKs mutate overnight, and the event system reminds me of a toddler with espresso. Thousands of change events for a single file edit. I wanted to build useful tools.
Even giants like AWS and CodePilot plugins throw random exceptions. Testing? What's that? The SDK laughs in JUnit.
The final twist: my own plugin, full of hope and effort, is now the ugliest code I've ever written. I can't fix it. I barely recognize it. I miss simplicity. I miss reliability. I miss fun.
JetBrains still has brilliance. But quality? It's slipping. The warning signs are glowing. Not with malice, but with entropy.
Would be poetic if a new IDE emerged soon. Just like JetBrains once did, fresh, small, efficient. Until then, I'll keep fighting caches, memory bloat, and undetectable test classes… while whispering my Eclipse shortcuts in IntelliJ like ancient spells.
Funny, isn't it? Software today feels less like writing code and more like running a game engine. But the bugs aren't part of the plot. They're just bugs.
Kotlin Flows Explained. A guide to understanding Kotlin Flows…
IntelliJ IDEA Moves to the Unified Distribution
#ide #intellij #intellijidea #java #jetbrains #kotlin
https://blog.jetbrains.com/idea/2025/07/intellij-idea-unified-distribution-plan/
Sure wish @jetbrains would add mistral/codestral to it's AI assistant so one could #goeuropean #jetbrains #mistral
#TIL "Delete leftover IDE Storage Directories" in #JetBrains #WebStorm just cleaned up 8 GiB+ of disk (!) Leftovers from outdated and no longer used IDE versions
VMOptionsExplorer, an online tool for exploring Java Virtual Machine (JVM) command line options now supports JetBrains Runtime (JBR). This is the JDK on which their suite of IDEs is based.
https://chriswhocodes.com/jetbrains_runtime21_options.html
https://github.com/JetBrains/JetBrainsRuntime?tab=readme-ov-file#why-use-jetbrains-runtime
Using JetBrains' AI Chat for a week now. It's not bad as it can understand context well, but it still gets about 40% completely wrong.
It has been useful at least to procvide ideas on how to approach some code and also to bring me up to speed of things I have not touched for a while.
However, like most LLMs, in the hands of an average or below-average programmer it is a risk to an organisation in terms of maintenance and bugs-in-production.
ReSharper and Rider 2025.1.4: Another Set of Bug-fixes Released | by Sasha Ivanova.
https://blog.jetbrains.com/dotnet/2025/06/30/resharper-and-rider-2025-1-4/
kotlinx.serialization 1.9.0 is out, with Kotlin 2.2.0 support.
https://github.com/Kotlin/kotlinx.serialization/releases/tag/v1.9.0
A big thank you to #JetBrains for helping make #oSC25 possible! We’re grateful for your sponsorship and for enabling #opensource innovation through amazing #developer tools! #openSUSE #Linux #DevTools https://events.opensuse.org/
️ Rider 2025.2 EAP 7 Adds New Debugging Features for Games
Rich errors in Kotlin 2.4: say goodbye to boring try/catch or not quite yet?
In our research, we closely work together with both JetBrains and ING (in separate projects). Great to see this reflection on Kotlin usage at ING, also featured as keynote at #KotlinConf.
https://medium.com/ing-blog/kotlin-adoption-inside-ing-5-years-later-df6421b14dc4