1. 17
  1.  

  2. 18

    Fascinating. Here’s the logic in bullet points

    • Our primary business is selling IDEs
    • It’s a pain in the ass to have IDEs serve multiple languages
    • Ergo, we must only have one language
    • Ergo we must develop our own language and …
    • … make sure everyone uses this language so that …
    • … we can safeguard our primary business, which is …
    • … selling an IDE

    I always wondered where Donald Knuth, the patron saint of Yak Shaving, went to work after that tex thing.

    1. 9

      That isn’t the half of it. JetBrains started by writing refactoring plugins for IDEs. They only got into IDEs because as plugin writers they were at the mercy of the IDE companies that hosted their plugins.

      Step aside, Knuth.

      1. 4

        Which makes this whole reasoning unconvincing, right?

        I mean, surely the people at JetBrains realize that it is completely unfeasible to get the whole world to use a single programming language, let alone a young programming language that is not backed by a multi-billion dollar multinational.

        1. 1

          What makes it even more unconvincing is that their Kotlin tooling is free, fully working in IDEA Community Edition.

          1. 1

            So, I didn’t take any of this too seriously, but there is a way projects grow organically. So, I can see a company organically growing it’s business from IDE plugins, to an IDE, to specializing in Java IDE, then developing a variant of Java, which gives them a niche where they have the best IDE for a language dialect because they drive development of that dialect.

            If asked to start from scratch, my guess would be a risk averse management team would have the strategy to just have a large team working on an IDE that supports as many languages as possible.

        2. 3

          I can see the point, but I’d like to think it was also fueled by what seems like a hole in the Java ecosystem - Java is popular and stable, but very slow to get more advanced language features (compare to C#), while the most popular alternate JVM languages (Clojure, Scala) offer all of the advanced features you could want, but with steep tradeoffs in learning time, and sometimes compile time and runtime size too. That means there was room for a JVM language that aims to be super-Java - some advanced features, but as support and accessories for a procedural/Java way of doing things, so is quick to learn for Java developers, and fast to compile with a skinny runtime too.

          By the nature of things, a language like that doesn’t tend to get created by independent enthusiasts - it’s hard to get together enough enthusiasm to build and maintain Java with some polish. Only a decent-sized corporation that can afford to spend some big bucks on making their team 15% more efficient in the future would do that.

          That’s not to say the article’s described motivations aren’t there too. I’d think that the fact that they’re an IDE company and there’s some potential huge business advantage from building a super-Java that appeals to other big corporations is what turns this idea from “eh, that’s cool I guess, but why bother” to “heck yeah, let’s get on this now”.

          It’s already paying strategic dividends. Getting Google to make IDEA their main Android IDE was undoubtedly a coup for them. But as is, they might change to something else anytime they felt like it. Building Kotlin and getting Google to adopt it gives them lock-in. Who’s going to sign off on switching back to Eclipse or something when you have an IDE from the company that built your main language? And it’s a win-win - Google gets a better language basically for free, and Jetbrains gets huge publicity of the kind that encourages other big corporations to think about switching from having a big-name company like Google/Android endorse it.

          1. 3

            Basically, they make developer tools and a programming language is the ultimate lock-in in that market.

            I don’t buy the argument that languages are complementary to IDEs. People don’t pay directly for languages. They pay for services around the language, which is what JetBrains sells already. OTOH, hardware and OS are complementary products. If people are tempted to switch to Macs and develop using Swift instead of Java, that might take some money away from IDE vendors. Notice how Apples gives you a “free” IDE and are pushing Swift on the server.

            He argues that developers might think Kotlin is beneficial but JetBrains are smarter than that. But I think from JetBrains point of view, it doesn’t matter if Kotlin (or its competetirors) have real advantages over Java or not. All it matters is what their customers think.

            So, yes, they were worried that their IDE business will go down the drain if everyone switches away from Java. They realized how vulnerable they are to shifts in programming language popularity. Their options were:

            1. Bet on one of the existing languages and be at the mercy of a young and small player
            2. Support all of the languages and remove your dependency on a specific language (which they might eventually chose to do)
            3. Create your own language and try to have more control over your destiny (which is what they did)
            1. 1

              They have been doing number 2 for basically half a decade already. There is pretty much no popular language they don’t support: C, C++, C#, F#, Groovy, Go, Java, JavaScript, Objective-C, PHP, Python, Ruby, Rust, Scala, SQL, TypeScript, VisualBasic, … plus dozens of language plugins made by language communities.

              1. 1

                Different languages need different approaches, but Idea is initially designed for Java. It will work for similar languages (C#), but its killer feature — autocomplete after typing . — will not work for most dynamic languages (js, python, ruby). I tried PyCharm and it works mostly like dumb editor (autocomplete sometimes works but very unreliably), but was quite slow for dumb editor (recent versions are probably much faster, especially compared to Electron-based IDEs).

                That’s also the reason why Microsoft created Typescript — not for type checker to catch your bugs, but for autocomplete in Visual Studio. Jetbrains designed Kotlin to be statically analyzable.

                Many other languages are not especially statically analyzable but there are opportunities for other IDE features for them. For example, Java completely lacks repl, but for Clojure repl is killer feature. It’s very convenient to write code while editor is connected to instance of program and being able to update its code on the fly and evaluate expressions. Cider, an emacs tooling for Clojure, even has autocomplete based on runtime information from live process, as opposed to static analysis of source code. Smalltalk IDEs use both static analysis and runtime information AFAIK (I don’t know details).

                And only Java (maybe C++ too) needs “code generation” feature (i.e. creation of getters, setters and hashCode).

                So, properly supporting multiple languages might be hard. One-size-fits-all approach might be “support java-like languages fully but only syntax highlighting for others”. Microsoft created Language Server Protocol which is cool, but again it’s designed for Java-like languages (C#, Typescript).