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.
I'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...
... 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.
Maybe I can better explain with an example, but it comes from the only time I've worked with Cobol professionally, and I have avoided it since. My experience is limited, and might not be the norm.
It was a bank, and transactions were processed through a pipeline.
Part of that pipeline was handing off transaction data from an always-active system, but then into many, many short-lived Cobol processes, and then into another always-active system.
The Cobol processes basically munged, pulled and pushed to database/s, and then killed itself.
In this case, I could see warm-up time being a huge issue, though a switch into another language might bring a change in architecture to threading and the like which would remove that problem, but I can't see a bank changing architectures easily.
From my limited exposure, several financial companies connected with the bank had similar processes. Something like Java or C running a server, Cobol when numbers need serious crunching, and then back into another server application.
(Incidentally, both the server processes were Fortran, if that's interesting to anybody).
I think I understand what you're saying but cobol runs in an environment that is optimised for cobol, and I'd expect where this were to be java you would have a similar arrangement in place. For a trivial example of what I'm talking about check out nailgun [0]
Yes, a change to Java would require a large architecture change. Notably from mainframes to something a little bit more familiar to most people.
But when Cobol works, is blisteringly fast, and they can afford to hire and train people to work with it, I don't see the benefits of Java, at all. Especially not at the enormous costs of a major architecture re-work in systems that are live 24/7, and downtime is counted in milliseconds.
Having to work around the JVM is just icing on the cake.
No, it wouldn't. Java is already used on a broad scale for this kind of thing. The ways in which it needs to be tuned for this kind of thing are in widespread use.
While 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.
The 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)
But 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.
Platform 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.
I 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.
I 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.
I 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.
Yes, 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.
Oh 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.
Java is too constrained by its OO straightjacket to be truly innovative. The brilliance of Jetbrains should not be underestimated. With Kotlin they've liberated Java development form its obsession with classes and produced a sufficiently FP alternative which yet retains full Java interop. No mean feat.
the best Java interop of all the JVM languages whilst
No. 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.
> 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.
It 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.
> But I'm not sure I've heard of anyone running into that limitation in practice.
Algorithms processing trees and graphs are everywhere, both in practice and in CS theory. Both are hard to implement in Rust and/or slow and/or require complex unsafe code. Here’s an example for trees, as you see all 3 approaches are far from ideal: https://github.com/SimonSapin/rust-forest
Another thing, because of that ownership thing, in Rust it’s harder to compose data structures. For example, here’s 1300 lines of code implementing hashmap + linked list combination: https://docs.rs/linked-hash-map/0.4.2/src/linked_hash_map/li... Sure, that particular collection is already in Rust’s standard library. However, quite often I need to compose standard library containers my own way. In Rust, that’s either a lot of complex unsafe code like that LinkedHashMap, or performance sacrifice (e.g. switching from pointers to index in a vector, or ref.counting).
I'd heard about the graph issue, but I don't know much about it. Is the main takeaway that GC makes managing trees/graphs a lot easier? If we were talking about C++ instead of Rust, what extra options would there be?
> Is the main takeaway that GC makes managing trees/graphs a lot easier?
It does indeed.
But raw pointers in C or C++ also make it easier than Rust.
Sure, it’s very easy to screw things up leaking and/or corrupting memory. But it still quite possible to implement correctly, I did that more than once.
Technically, you can usually do the same in Rust with unsafe pointers. Like the developers did to implement that LinkedHashMap for the Rust’s standard library. However, C++ is just better for writing unsafe code like this. After all, it evolved for decades being an unsafe language. Over that time, huge amount of stuff were implemented in the language (STL, esp. the checked version), runtime (debug heap), standalone tools (vtune, valgrind), and even OS (windbg) to help people implement e.g. graphs without leaking memory or exposing dangling pointers.
I 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.
Actually 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).
It'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).
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.