Not sure if that is true. Many people are still using vim for many newer languages. I think it depends on the language.
Some languages are simply more IDE-reliant than others. Statically typed languages with a large vocabulary (Java, C#, Scala) tend to benefit more from IDEs than simple, dynamic languages like Python and Ruby.
And there are newer languages like Go. Go was designed to not require an IDE while not being opposed to one.
I think the language server idea is a brilliant one and probably something we'll see more and more of, because it makes a language completely editor/IDE agnostic. It would allow folks using vim or VS code to debug or refactor as cleanly as full-blown IDEs. I suspect this will lead to a decline in the specialized IDE market (Jetbrains).
Kotlin is unusual because JetBrains invested heavily in their IDE support from the start and developed it hand in hand with their plugin, so there's nothing in the language that is hard to statically analyse in a fast way.
As a Kotlin user it makes it a very pleasant language to develop in. You should try it.
As for IDE agnostic language servers, I think you'll find they find it hard to compete with IntelliJ or similar advanced IDEs simply because the "protocol" for classical IDEs is very fast, high throughput and complex object APIs. The featureset of something like IntelliJ is enormous and they can iterate very quickly. It'll be a long time until there is strong competition to it especially with a standards based out of process server-type design.
I remember working with C++ in Visual Studio when that new refactoring plugin became popular (tomatoe something something? later bought by Microsoft) and although the plugin tried its best, it often stopped working with files with a lot of ifdefs and macros.
B removed some features from BCPL that were too expensive to implement. I never understood why they didn't continue that idea in C by applying it to the syntax as well. Wirth knew what he was doing.
https://en.m.wikipedia.org/wiki/Turbo_Pascal
and as far as I remember I never had to leave the IDE. The step-by-step debugger felt like magic.
On the Microsoft side, there as Quick C, Quick Basic, etc.
IDEs were the norm rather than the exception in the 80s and 90s for DOS machines. Writing code on DOS with a plain-text editor was a little unusual, whereas on Unix it was a norm.
Visual Basic, Delphi, MS Access, Visual FoxPro, Visual Objects, Visual Studio, C++Builder, Macromedia Flash, even obscure stuff like REBOL - all supported very fast iteration on client side business CRUD apps that connected to a database.
It's only in recent times that we lost this and came to believe that buggy bloated text editors implemented in HTML plus a giant pile of pre-processors in which everything is coded by hand and the frameworks are obsoleted every six months is a good developer experience. Compared to what we had in the 90's the level of polish and integration is far, far lower in modern toolchains.
It's a fantastic initiative -- in such a short time we see many IDEs support consistent auto-complete, refactoring and so much more.
I think IBM was first with supporting refactorings for Java in Visual Age and Eclipse. Refactorings themselves emerged out of the Smalltalk community.
MS was very motivated to support that for C# as they were getting worried about losing marketshare to Java at the time and because J++ got a lot of negative press (compatibiltiy issues, vendor lockin, the usual MS stuff). In the end C# was held back by the same factors that held back J++ and it took them until very recently to openly support it on platforms other than Windows.
Microsoft intellisense (aka code completion) was truly a first back in 1997 (then just for VB and C++).
Inspired by is an understatement, the connection is more intimate: https://en.m.wikipedia.org/wiki/Anders_Hejlsberg
But beside smalltalk, there were lots of others. All the commercial Lisps, Dylan etc. Somewhat more mainstream-ish - the NeXT Objective C environment is a good and much earlier example.
There were lots of interesting things about .NET when it came out, the IDE-ness of it doesn't strike me as one of them at all.
Maybe it's already this way? I'm really not sure, but I'd appreciate a NetBeans or IntelliJ dev to clarify. It'd be awesome if these changes were done collaboratively.
Many many corner cases are not accounted for, and the way Kotlin is under-spec'd and developed with so many of the IntelliJ libraries, you'll never see any independently developed implementation.
This is not to say the language isn't great, it is. It's only heavy development while focused on lower level aspects that this becomes a constant theme.
How do you figure? The language defines the runtime semantics in a way no IDE or refactoring tool does. It's a very bright line, unless you're conflating the distribution package of the language with the language itself.
Idea developed Kotlin as a better Java. Most of their IDE is now written in it. Deep integration with the IDE was a design goal from day 1.
They release the IDE plugin and compiler with the same version number. They are basically developed together. I usually find out about new Kotlin releases because my IDE prompts me to update the plugin. Happened to me this morning with 1.2.61.