Rise and fall of JVM languages
blog.frankel.ch
blog.frankel.ch
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.
This is like trying to replace C on UNIX, C# on .NET, Erlang on BEAM, or JavaScript on the browser.
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.
In all these years of alternative languages customers still don't allow us to use anything other than plain Java.
Also there are acceptance reviews from customer teams.
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.
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.
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.
Although I think if WebAssembly becomes a success, we will get the revenge of plugins.
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
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.
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/Web...
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 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.
Fortunately, it has a JVM target too. http://documentation.microfocus.com/help/index.jsp?topic=%2F...
http://www.coss-solutions.nl/index.php/2013-11-18-13-59-23/n...
It can even target Azure deployments!
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).
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.
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.
Languages encumbered by backwards compatability and bolt on new features will eventually collapse under their own weight.
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.
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.
the best Java interop of all the JVM languages whilst
That does sound like the niche that Rust is shooting for.
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".
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.
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).
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.
And given that removing the FP nature of Scala pretty much hamstrings its value proposition, I can see why he'd be dismissive of it on those grounds.
Already at Xerox PARC, Lisps started to support OOP, with FLAVORS for Interlisp-D being one of the first ones.
EDIT: Disregard the last paragraph, lispm is right.
If anything, it will stay here for decades thanks to so many enterprise and massive projects relying on it.
There are very, very few technologies that are 'winners' (pick your own meaning) in the long run. Choose wisely.
As someone who was there in 2001, I just have to say: Java was never cool, and especially not at that time. It was bloated and ugly and slow, the GC was terrible, applets were simply the worst, the UI toolkits available looked horrible on every single platform. There were no decent IDEs or editors and the language was if possible even more verbose and circumspect back then.
That sounds really interesting! Has any documentation survived about that?
Also Oberon was another system that also allowed for something like Java applets, called Juice.
The other stuff like JNI (a registry for RPC endpoints) and java rmi itself were baked into the standard libraries from the beginning as well. But the envisioned "software agents running on arbitrary machines on the network" never took off, seems kind of foolhardy in hindsight, that anyone would think that's a good idea.
Well, we’re back to it with webassembly now. Everything old is new again.
We call software agents "containers" now and arbitrary machines on the network "cloud" but it is the same thing...
It was also a bit ahead of the time, or perhaps not marketed well.
Yes, probably, and that may be why it did not take off more. It would have been great if it had survived and grown. Could do interesting stuff with it.
Graham Glass, who was recently or is still running edu20.org / NEO LMS (an e-learning company and product) was involved with ObjectSpace, Voyager, Electric XML and WebMethods. IIRC he was the CTO of ObjectSpace and then WebMethods. He's an acquaintance of mine and a very accomplished person.
https://www.wired.com/1995/12/java-saga/ https://www.wired.com/1998/02/java-talk-with-gosling/
E.g.
com.sun.java.foo
com.sun.java.bar
com.ibm.foo2
com.ibm.bar2
etc.
On the startup that I was on back in 2000, we were planing to drop out TCL based application server by J2EE, only to change the decision on the last minute by .NET.
The reason being that we were Microsoft partners that were invited to try out this cool new thing called .NET, before betas were available to the press, and have our products be ".NET 1.0 ready" by launch date.
It was so uncool they named JavaScript after it.
J2EE v1 was slow and considered by many to be over-engineered (probably why slow). Used it in one project but didn't like it. I've heard that after v3 or so (from then called JEE) it became lighter and better. Maybe others can comment on that. And from some time there have been other options like Spring, etc. Found Spring rather complex too on an initial look.
What do people on here like using for Java web apps these days (those who do use it)? Heard of Wicket and Play, I know there must be others.
[1] Apart from the millions they also put into marketing Java to enterprises. And that worked, as we know. It became huge in the enterprise and still is.
Update: I checked, it is open source:
>In February 2012, JetBrains open sourced the project under the Apache 2 license
from:
[1] I ask that because all 4 possible combinations of open/closed source and paid/free software exist. But "open source" is often used loosely by people to mean both open source and free as in beer, including by well-known tech journalists or authors who should know better.
I think even closed source languages which are paid, have a chance, just maybe not very big a one. But that is not a problem as such. Not everyone is aiming to be a unicorn - more like the opposite. [ This idea of "go big or go home" (propounded by VC's) is deleterious to the public health (TM:) ] But the chance is probably big enough for a company or three (for that language) to live on - provided they get their act right (enough) on all fronts, including tech and marketing. And even big enough for an ecosystem to build around them. Such things still exist today, just that they are not so much talked/written about as much as open source and the latest "hot" trends are. Blame the media and the cool kids for that.
And I say this as a strong (though not exclusive) proponent, user and somewhat of a practitioner of open source.
https://github.com/JetBrains/kotlin-native
So Kotlin Native may be another good reason, once it is stable.
I did a few Grizzly deployments last year.
But in 2000 I started messing with other languages like Python and Perl; at which point Java became nothing more to me than tech to put food on the table.
I remember being involved in a project in which we developed and tested an application on PCs. One of our customers called up one day and asked if it worked on his linux box. "I have no idea," I said, "nobody's ever tried it." He tried it and it worked flawlessly. That doesn't seem like a big deal today with web apps, but in the late '90s it was black magic.
Also, before Flash and before Javascript was good enough to build full-featured applications, pretty much the only way you were going to do an interactive web application was using java applets.
I've yet to work with Kotlin but did like Groovy some years ago. Never used it professionaly though, only for play-projects.
We still love and use Java a lot and they both complement each other very well.
Perhaps Java 7, but Apache Groovy doesn't have the lambda syntax from Java 8. Development on Groovy has stagnated -- someone even contributed a fully working Antlr-4 based parser to replace their outdated Antlr-2 based one last year, but it's been sitting in their development repository at Github going nowhere ever since.
I don't have a good read on how popular Grails is anymore. I liked it a lot in the past but I don't need it anymore with Kotlin and Spring Boot.
Gradle's been able to use Kotlin for build files since Gradle 3.0 which was released last year.
For Jenkins, only a subset of Apache Groovy can be used. None of the functional methods will work when used.
Grails 2.x is still around, but virtually no-one's converting their projects to version 3, or starting new Grails projects in version 3.
Groovy development has come to a standstill, and even contributions from outside developers just sit there, such as the new Antlr 4-based parser which someone contributed a whole year ago.
Returning something from the stub:
myService.getData() >> data
verifying the returned value without explicit assert:
result == expected (This will show a very informative error in case of mismatch and gives you the ability to see the differences in a diff style window)
Interaction based testing is a breeze with this:
3 * myService.getData()
1 * myOtherService.getData()
And finally the data driven testing is the most natural that I have ever seen. You just need to literally create a table and use the column name in your test or even in your test title. Writing tests becomes a joy with Spock.
In F# I have looked at expecto, fsunit and some other library, but I can't find anything remotely equivalent.
That being said, any idea why they started from scratch instead of building on or contributing to frege?
As a side note, this seems to be the biggest detractor for Scala. Any team that I have spoken to with Scala experience seem to have had projects that went too 'Scala/functional'.
Was it compilation speed? Corporate support?
I would be attracted to Kotlin because IDE (Intellij) verification is very slow in Scala, compilation speed is and will be slow (really interested in efforts to reduce language scope to speed up mentioned on HN earlier), error messages in Scala are a pain.
Would wish for that attitude:
As such it turned out to be a natural fit for Android apps as well, because the platform has pretty much the same type of limitations.
Other nice things: - Standard library is tiny so you don't get a large app size and method count hit. - The datastructures are fully interoperable with Java ones so calling out to existing Java libraries and code feels completely natural. I need to stress how important this is - you can just drop Kotlin classes into existing codebase and things will just work and look natural. - The language itself it very easy to pick up - it fixes A LOT of Java pain points, but it doesn't really try to change fundamental paradigms. Which means that pretty much any Java developer can quickly become productive in it. - The IDE support it superb and practically on the same level as Java. - The compiler is fast enough and good enough.
What are the pain points it fixes?
Scala brings its own huge library with features that I don't need. Billions of abstract collections, but all I need is HashMap and ArrayList. They generalize over builders, so `filter` can return some fancy underlying class, but all I need for filter is to return ArrayList or lazy sequence. Kotlin again hits sweet point: all it does is extending standard Java library with few utility methods and it adds lazy sequence type (interface with one method).
Due to Scala huge library it's hard to use on Android with its artificial 65k method restriction. Kotlin doesn't have this problem.
Last time I checked, Intelij Idea wasn't able to parse even standard Scala library without errors. May be it's better now, but my experience is that Kotlin beta plugin was better than Scala plugin. Doesn't relate to language directly, but complexity of the language is definitely influences tooling: simplest language Go has awesome tooling.
Compilation time was never an issue for me, but I guess for some projects it matters.
I don't care about corporate support, but I do care about dogfunding. I didn't see Hibernate being rewritten with Ceylon. But Jetbrains use their own language for their tasks, that means that they are unlikely to abandon it. Google support probably matters a lot for Android developers as well.
That said, Scala is mature language and I don't see it going anywhere soon. It has very rich set of features, it allows much better abstractions than Kotlin, it has huge projects, a lot of developers work as Scala developers. But Kotlin definitely has a momentum.
Would you mind elaborating on what those Java pain points are that Kotlin smoothes over?
Also are people deploying Kotlin on the server side or do you see that being a thing in the future? For some reason I have this(perhaps incorrect) association Kotlin only in the context of Android. But maybe that's incorrect?
1. Explicit semantics for nullable variables. It helps to convey information whether this function can accept or return null and compiler checks that your code won't throw NullPointerException. It's not ideal when you're dealing with Java code, but it works.
2. Explicit and convenient semantics for mutable and immutable variables. You can use `final` in Java for variables or parameters, but few people do that, because code becomes quite verbose. With Kotlin you are using `val` or `var`, so code doesn't become more verbose.
3. Almost everything is an expression. Helps to write concise code sometimes and makes a language more consistent.
4. Compiler changes type of variable when developer checks for this type. So you don't have to write nonsense like `if (a instanceof String) f((String) a)`, instead you write `if (a is String) f(a)`.
5. Better replacement for `switch` statement. Kotlin's `when` statement has more features. Not a proper pattern-matching, though.
6. Default values for function parameters. With Java you have to write lot of function overloads with slightly different set of parameters and delegate it to a single function. With Kotlin you're writing one function with optional parameters.
7. Named arguments. Sometimes it leads to much more readable code.
8. Generic parameters can be covariant or contravariant. Basically you can assign `List<Integer>` to variable of type `List<Number>`. It helps sometimes.
9. Operator overloading. `a + b` instead of `a.plus(b)`; `m["x"]` instead of `m.get("x")`. Code looks much more natural, when used appropriately.
10. Singletons. Kotlin doesn't have static classes, instead it has `object`s, which are implementation of singleton pattern. They can implement interfaces, for example.
11. Proper properties. getter/setters generated automatically, property access looks like field access, but with all perks the methods have.
12. No need for artificial utility classes, which are not really a classes, but just a bunch of static methods. You can either use plain functions at top-level or enhance existing classes with utility methods. `str.isBlank()` instead of `StringUtils.isBlank(str)`, for example.
Generally Kotlin is much less verbose than Java, but it's concise enough and doesn't try to be implicit or magical.
> Also are people deploying Kotlin on the server side or do you see that being a thing in the future? For some reason I have this(perhaps incorrect) association Kotlin only in the context of Android. But maybe that's incorrect?
According to Kotlin developers their user base was roughly 50% : 50% between server side and Android. I used Kotlin for small server side projects, it works almost flawlessly with standard Java frameworks like Spring or Hibernate.
Kotlin is a much simpler language than Scala.
If you look at the graph in the post, it didn't; Scala is substantially more popular. Kotlin is just at a different point in the hype cycle.
(There's plenty I don't like about Scala qua Scala, but I don't see it ever being displaced by a language that lacks HKT. Kotlin has some good aspects to its design, but the anti-intellectual hostility to good formalisms and refusal to learn anything from Scala's mistakes rubs me the wrong way)
They make it much easier to fulfil business requirements in a clear, maintainable way (and mean there's a huge space of libraries available to help with that), which is what programming is all about.
> I like how Clojure works much more (you can opt-in to any extra features Clojure has to offer and they are not forced on you) compared to Scala.
What exactly is "forced on you" in Scala?
> Clojure is a clean language with a very powerful and useful philosophy behind it, Scala on the other hand has a lot of tacked-on features and the whole language lacks consistency and philosophy
Clojure has a clean design as far as it goes, but the design is so spare that to do anything practical in it relies heavily on macros. That's a legitimate language design philosophy and I'm glad there are languages that pursue it, but I don't find it makes for maintainability in the long run; macros are too powerful to be able to reason about code that uses them, so for a maintainable codebase your macros need to be restricted to a subset of what's possible - and to be able to maintain that it would be better to standardize more restricted alternatives that cover the important use cases.
What Scala features would you say are tacked-on? I find it very coherent, with just a few powerful, orthogonal features - it's not quite as minimal as Clojure, sure, but it feels like it's got a lot fewer special cases than Kotlin or any number of modern languages. The libraries some people have written are a lot more... variable, but that's not a sign of issues with the language - if anything it's the opposite.
Same stands for dsls, macros, multimethods, I can mean any feature in any language. HKTs are just one tool of many.
> What exactly is "forced on you" in Scala?
Any built-in language feature. For example no matter what I do `implicit` will be a reserved keyword and the language will make use of it. I can't opt out. In Clojure on the other hand there is [spec](https://clojure.org/guides/spec) for example. If I want it I import it and all of its features are defined in terms of Clojure itself. The whole language feature is a library. I can add [the language itself](https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0) as a library to my project (which is what I do with Kotlin) and use all of its features like the STM, or persistent data structures. Can you do the same with scala? I doubt it.
> Clojure has a clean design as far as it goes, but the design is so spare that to do anything practical in it relies heavily on macros. [...] macros are too powerful to be able to reason about code that uses them
That's why Clojure has spec. It solves the reasoning problem. It is also incorrect to assume that you can't do anything practical without macros, it is quite the opposite. You can do anything without them but there are some special cases where macros are useful. You can read any lisp textbook and you will see this in every one of them. If you write any lisp code then you have to know that for your first few projects you will overuse them, then you might learn where they are really applicable.
Name some special cases in Kotlin which are problematic. I can't name a single one from the top off my head despite the fact that I use the language for more than a year.
Would you say those features have no business value then? I've met enough business problems that were best modelled with HKT that I don't believe a language without an equivalent feature could be as effective.
> Any built-in language feature. For example no matter what I do `implicit` will be a reserved keyword and the language will make use of it. I can't opt out.
Almost all languages have some keywords. But yeah, implicit is a language-level feature. It's got a very high power-to-weight ratio though; it has valuable use cases (typeclasses, extension methods, the magnet pattern) that couldn't otherwise be done in plain old code, unless all those things were their own language-level features.
> In Clojure on the other hand there is [spec](https://clojure.org/guides/spec) for example. If I want it I import it and all of its features are defined in terms of Clojure itself. The whole language feature is a library. I can add [the language itself](https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0) as a library to my project (which is what I do with Kotlin) and use all of its features like the STM, or persistent data structures. Can you do the same with scala? I doubt it.
Plenty of Scala things are libraries, you absolutely can import the scala standard library and use its collections, its async implementation or the like from another JVM language (though they may not be terribly idiomatic there). I don't really see the distinction you're drawing?
> Name some special cases in Kotlin which are problematic. I can't name a single one from the top off my head despite the fact that I use the language for more than a year.
Nullable types are a special case that doesn't compose properly (null is expected to be used for errors but if you write generic code that does that and then one of the values you pass in is null then you've got a bug), and a special case in the syntax (can't write your own type that allows ?. if you want to e.g. include a reason-for-failure message). Platform types for Java interop are a special case (you can't always pull out repeated calls to a Java method into a utility method without changing the meaning). Extension methods are a special case (can't use them to implement an interface). Operators are a special case (can't have an interface that requires them).
But nobody was seriously using it at scale until it stabilised, which was the start of last year.
Judged from its 1.0 "ok you can use this now" release, it's a little under 2 years old.
The article shows google search traffic for Kotlin which temporarily spiked above Scala in the wake of the Android announcement and then dropped back down to less than half the Scala traffic, below Groovy in fact. I'm not sure that it's much of an indicator of anything.
Also of interest:
"Lattner: Swift and Kotlin evolved at about the same point in time with the same contemporary languages around them. And so the surface-level syntax does look very similar. … But if you go one level down below the syntax, the semantics are quite different. Kotlin is very reference semantics, it’s a thin layer on top of Java, and so it perpetuates through a lot of the Javaisms in its model.
"If we had done an analog to that for Objective-C it would be like, everything is an NSObject and it’s objc_msgSend everywhere, just with parentheses instead of square brackets. And a lot of people would have been happy with that for sure, but that wouldn’t have gotten us the functional features, that wouldn’t have gotten us value semantics, that wouldn’t have gotten us a lot of the safety things that are happening [in Swift].
"I think that Kotlin is a great language. I really mean that. Kotlin is a great language, and they’re doing great things. They’re just under a different set of constraints."
https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-panel...
First. What are you even talking about?
Quiet:test user$ time java Test
Test
real 0m0.104s
user 0m0.074s
sys 0m0.028s
Quiet:test user$
And second: Who cares? What us "Java guys" do with Java, well, it doesn't matter in the slightest that it takes half a second to start. Because, we deploy to running processes. "We" power things like Hadoop clusters. The startup time is meaningless in "our realm" and frankly, I think if you're wondering about java for something like command line tools, it's just the wrong tool for the job for many reasons. And if you're looking at GUI apps, it's still better than Electron :P
So seriously, Hacker News, what is the obsession with this?
We are optimists, we think there is always something that could be improved.
"It's never good enough" can be interpreted in two way.
Though I do agree that we should always strive to make it as good as possible. Being a "Java guy" myself, I indeed do not find the JVM startup time to be a big deal in our applications. Especially in my environment (hospital) where our program is pretty much running the entire day without a restart.
So in the morning, the doctors/admin/.. start their application and rarely shut it down until the end of the day.
(That is of course quite specific to where I work)
We are dilettantes, we think there is always something that could be improved in a domain we don't fully understand.
ExcelsiorJET has a free license for non-commercial uses.
https://www.excelsiorjet.com/#free
RoboVM's fork is another possibility
If you're writing Scala, you have the option of compiling with scala-native, which targets LLVM.
See also: "your _____ takes too much memory." "Your ____ takes more computational resources than _____." E.g., The new existential threat for the entire programming world is Atom/VSCode and other Electron apps.
In short, it's people without a point hoping to discredit something for various reasons.
Not saying it can't be done with java. Even android studio has a hot class swapping feature (I know it isn't JVM but as a proof of concept this exists)
When using plain JSPs with exploded WARs, you can usually hot reload.
If I want to write code that (say) is run dozens of times during a large build process, that's not really acceptable. The JVM is a poor fit for the Unix model in particular, which tend to use lots of small processes with a single purpose that work together.
Yes, there are workarounds (been there, done that), but the larger point is that the JVM and its ecosystem are primarily targeted at fairly heavy-weight and long-lived server processes that have obvious implementation biases along these lines.
The slow startup time is just one symptom of these implementation biases, and the question is not whether you can work around these problems, but why you should bother in the first place if the JVM is a poor fit for your application domain.
So, which language allows serious programs do a lot of work without time penalty?..
https://www.excelsiorjet.com/ is just one example from many third party commercial JDK vendors delivering AOT compilers since the early days of Java, and still in business.
Also for those that don't want to pay for AOT compilers, OpenJDK is going to start supporting AOT compilation as well.
I can wait 15 seconds. Its cool.
But my original comment was meant seriously, rather than cheap trolling. Unlike Groovy, JavaScript has excellent portability and a perspective to migrate code away from Java/JVM.