14 ms·
If the language designers keep their heads, Kotlin will slowly eat away at Java. Java itself is never going away: it's a Fortran or Cobol situation, only maybe
by norswap 9y ago
If the language designers keep their heads, Kotlin will slowly eat away at Java. Java itself is never going away: it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger.
Xtend never was alive, and it's clear Ceylon has lost at this point, even though it is arguably better designed than Kotlin. However, they made some bad syntactic decisions (not shedding enough of the Java verbosity, introducing new weird keywords), and when you're doing run the mill Java-like programming, it's just more gratifying to write/read Kotlin code.
Scala's development is somewhat unpredictable, but I think it's fair to say it's lineage is not going away either. New compilers are being developed by the original team (Dotty) and by Twitter (reasonable scala) with very different objectives. Currently, there simply aren't any many contenders in Scala's niche (very powerful statically typed programming languages with a pragmatic bend, i.e. not Haskell). C++ could fit the bill but pushes memory management and Cthulhu on you. The ML family could also fit the bill, but lacks momentum/hype. However Facebook is spearheading a revival with Reason ML. Scala's big trump card is the Java library ecosystem.
- pjmlp 9y agoKotlin can never replace Java as long as the JVM is relevant. This is like trying to replace C on UNIX, C# on .NET, Erlang on BEAM, or JavaScript on the browser.
- norswap 9y agoKotlin is essentially Java with some sugar sprinkled on top. That's its strength: the semantics & the concepts are the same. I also never said Kotlin will replace Java, but that it will gradually grow to the detriment of Java, which is still here to stay.
- pjmlp 9y agoI don't believe Kotlin will get much strong outside Android. In all these years of alternative languages customers still don't allow us to use anything other than plain Java.
- swsieber 9y agoI have to wonder what the distribution is of people using java is. You seem to be a freelancer or independent agency for contract. I can easily see a bunch of big corps moving from Java to Kotlin though. Especially with an in via android, why not using Kotlin across the board. It will definitely be a gradual thing, if it will be thing. Kotlin just seems to be a very, very pragmatic enhanced version of Java.
- pjmlp 9y agoYep, enterprise consulting for Fortune-500, DAX level companies.
- iammiles 9y agoI work for a Fortune 500 company and we've switched to Kotlin from Java a little over a year ago with great results. My perception might be a bit skewed in the opposite direction as yours, but I think Kotlin will catch on. The article really hit the nail on the head when it mentioned Kotlin's interop with Java being its killer feature.
- mac01021 9y agoYour customers can tell what programming language you're using?
- pjmlp 9y agoYes, it is usually defined in the project contract, and we usually have to use customer configured environments, including source code control systems and CI infrastructure. Also there are acceptance reviews from customer teams.
- coldtea 9y ago>In all these years of alternative languages customers still don't allow us to use anything other than plain Java. That's because all those years those alternative languages never got much traction except Scale. Kotlin is already poised to reach hundreds of thousands through Android support.
- cutler 9y agoWith Kotlin it's possible to write a complete application without using a single class or even OO. I'd call that more than syntactic sugar.
- Others 9y agoBut Erlang now has strong competition on BEAM. Sure, none of those languages will be replaced, but surely some will lose market share to up and coming languages.
- pjmlp 9y agoPlatform languages always get access to everything from the eco-system, while enjoying better tooling. External languages always have to try to fit into the platform. This is the main reason why as language geek, I always try to learn new languages and paradigms, but when it comes to production code I only use the platform languages. No FFI headaches, no lack of tooling, first party support in the SDK, no messing around with alternative build systems, no issues hiring team members and so forth.
- pointernil 9y agoI agree on the first 3... and most probably that's why I very strongly disagree on the last part. The way the languages "match" the environment in the first 3 examples is almost reciprocal to the way the language is a mismatch in the last one... "it just happened". Also seeing those first 3 environments even listed with the last one somehow does not seem fitting... but is still a nice pictures of current "Zeitgeist" of computing and software development, imo.
- pjmlp 9y agoStill, it is the only native option and remains to be seen how much WebAssembly will change that. Although I think if WebAssembly becomes a success, we will get the revenge of plugins.
- jimbokun 9y agoBut it could play the same role for Java that C++ played to C.
- cultofmetatron 9y agowhat about rust on unix (redoxos) f# on .net (.net is supposed to support multiple languages) elixir has successfully replaced erlang on BEAM for a lot of people. webassembly is hot and you can always use js as a compiler target for some other language
- frant-hartm 9y ago>Scala's big trump card is the Java library ecosystem. Much of which is awkward to operate with because of Scala's own collection library. One of the main reasons Kotlin is so much easier to use.
- alextheparrot 9y agoMost of the time you just need a single import and to call the 'asScala' function, I don't consider that too awkward.
- lmm 9y agoIt's very much possible to use the Java collections library in Scala, if that's what you want (I've done it in production before; I think the benefits of using a more functional-idiomatic and immutable-first collections API usually outweigh the costs, but the option is there).
- qyv 9y ago> it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger. You underestimate the amount of COBOL code that is still out there running our daily lives: http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/2008/0810/080901ms01/080901ms01.html http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Web...
- kpil 9y agoI've done work for a fair number of banks and insurance companies, and my anecdotal impression is that there is always a java system siphoning data from the cobol systems... Both stay around for the same reason: backwards compatability and a stable api+abi. If you find and old Java system it's often trivial to do changes and recompile. Even a few years old C program is often problematic due to changes in the OS or libraries. I have no idea if it's possible to compile a couple of years old js code...
- ido 9y agoJs isn't usually compiled at all! And old sites using old js generally still work in modern browsers.
- kpil 9y ago... but modern js almost always have a build step. But yeah, the fair deal of time I have spent on fixing old web pages was more related to fixing the html and CSS and just minor problems related to js.
- shagie 9y agoThat is very true - there is a lot of cobol out there. Fortunately, it has a JVM target too. http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.eclipse.infocenter.visualcobol.eclipseux%2FGUID-DEAFFCA6-6D75-4AEA-A3B6-6DF0BDCF3E2F.html http://documentation.microfocus.com/help/index.jsp?topic=%2F...
- 9y ago
- jazzyk 9y agoI love Ceylon - it is what Java should have evolved into (had it been managed better). Java replacement would have to introduce something an order of magnitude better than Java, just like Java did, with respect to C/C++ (for business-level applications). None of the existing solutions (Kotlin, Scala, etc) are at that level.
- pesfandiar 9y agoWhile Kotlin may be fun to write in and have the potential to become mainstream in the industry, I think you underestimate how much Java is used outside of hobbyist and startup circles like HN.
- peterashford 9y agoThe thing is that Java -> Kotlin is almost entirely frictionless while also adding a lot of value. I can see people preferring Kotlin to Java as a teaching tool if Kotlin gets a little more traction, because of its relative simplicity. (I say this as a long time Java programmer, now trying out Kotlin and enjoying it)
- tootie 9y agoJava will slowly absorb useful features from Kotlin until it's no longer necessary.
- Spivak 9y agoAnd eventually the C++ification of Java will scare away new developers who don't have years of context that explains the organic growth. Languages encumbered by backwards compatability and bolt on new features will eventually collapse under their own weight.
- pjmlp 9y agoOthers decide to break compatibility, wait > 10 years and there are still debates which version to use (Python), or fade away (Perl 6).
- canes123456 9y agoAh yes, it will die just like C++. Backwards compatibility focus languages are the only ones that live long enough to be old and encumbered.
- Spivak 9y agoOh no, I'm not implying that Java or C++ will ever die, they'll probably outlive me. I'm only saying that by bolting on new features Java will get progressively harder to program in by anyone who doesn't already program in Java. This is good for Java programmers because it means big bucks for being the only devs that can maintain huge legacy systems, but bad because fewer people will write new code in Java.
- norswap 9y agoNo. They will do too little, too late. Just like the lambda that were slated for Java 7 and came in Java 8. Now they're talking about value types, but it will be for Java 10 at the soonest (Kotlin doesn't have that either btw). They're also wont to misdesign a lot of stuff. The generics implementation is mental, and the module stuff from Java 9 seems to be a debacle in the making. Lambdas are good though.
- oconnor663 9y ago> Currently, there simply aren't any many contenders in Scala's niche (very powerful statically typed programming languages with a pragmatic bend, i.e. not Haskell). C++ could fit the bill but pushes memory management and Cthulhu on you. That does sound like the niche that Rust is shooting for.
- norswap 9y agoIsn't Rust niche safe low-level (mostly GC-less) programming? I think it is, and the hoops you have to jump through to guarantee that safety are really at odds with what I would call "power".
- oconnor663 9y agoIt often feels high level (iterators and closures and all that), but yes, Rust is definitely designed to give you C++-like control over your memory. The learning curve is fairly steep, and new Rustaceans do tend to go through a phase of "fighting the borrow checker". But once you get a handle on the ownership rules, I think you very rarely find them blocking you from doing something you actually should be able to do. For example, it is hard to get non-const pointers to two elements of a map at the same time, because the compiler can't prove they're not pointing to the same element, and that would let you violate all the safety rules. But I'm not sure I've heard of anyone running into that limitation in practice. And if you totally absolutely needed to, you could use unsafe code to do it. The ownership system also gives you a different kind of power, to specify how your API's are supposed to be used, and to have the compiler enforce those rules. If a collection isn't threadsafe, for example, the compiler guarantees that you can't race on it from multiple threads. You can put the container inside a Mutex to let multiple threads use it, but then the Mutex will own the container, and callers can only access it by locking the Mutex. Those are powerful guarantees, and they solve problems that come up in managed/GC'd languages too.
- pjmlp 9y agoUnless one is trying to do GUI related programming.
- willtim 9y agoActually Haskell can be a lot more practical depending on what one wishes to accomplish. I've seen many Haskell ideas encoded in Scala that then become a lot less practical (verbosity, stack space, efficiency).