Rise and fall of JVM languages(blog.frankel.ch)
blog.frankel.ch
Rise and fall of JVM languages
https://blog.frankel.ch/rise-fall-jvm-languages/#gsc.tab=0
232 comments
> 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/Web...
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...
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...
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...
Js isn't usually compiled at all! And old sites using old js generally still work in modern browsers.
... 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.
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.
That 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=%2F...
Fortunately, it has a JVM target too. http://documentation.microfocus.com/help/index.jsp?topic=%2F...
And .NET as well.
http://www.coss-solutions.nl/index.php/2013-11-18-13-59-23/n...
It can even target Azure deployments!
http://www.coss-solutions.nl/index.php/2013-11-18-13-59-23/n...
It can even target Azure deployments!
Wouldn't the JVM's warmup time make it untenable for most places COBOL is used?
What places are these? I thought Cobol ran on server-side mostly? JVM is always warm.
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).
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]
[0] http://www.martiansoftware.com/nailgun/
[0] http://www.martiansoftware.com/nailgun/
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.
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.
would require a large architecture change
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.
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)
Kotlin 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.
This is like trying to replace C on UNIX, C# on .NET, Erlang on BEAM, or JavaScript on the browser.
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.
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.
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.
Still, 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.
Although I think if WebAssembly becomes a success, we will get the revenge of plugins.
Kotlin 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.
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.
I 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.
In all these years of alternative languages customers still don't allow us to use anything other than plain Java.
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.
Yep, enterprise consulting for Fortune-500, DAX level companies.
>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.
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.
Your customers can tell what programming language you're using?
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.
Also there are acceptance reviews from customer teams.
With 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.
what 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
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
But it could play the same role for Java that C++ played to C.
Java will slowly absorb useful features from Kotlin until it's no longer necessary.
And 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.
Languages encumbered by backwards compatability and bolt on new features will eventually collapse under their own weight.
Ah yes, it will die just like C++. Backwards compatibility focus languages are the only ones that live long enough to be old and encumbered.
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.
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.
Others decide to break compatibility, wait > 10 years and there are still debates which version to use (Python), or fade away (Perl 6).
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
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.
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.
That does sound like the niche that Rust is shooting for.
Isn'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".
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".
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.
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).
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.
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.
Unless one is trying to do GUI related programming.
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.
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).
>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.
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.
Most of the time you just need a single import and to call the 'asScala' function, I don't consider that too awkward.
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).
No mention of Clojure? In the comments the author says that since it was a functional JVM language, he never considered it. OK.
Yes that's a very strange comment and taints the perspective of the author for the entire article. Kotlin and Scala are also functional or include strong functional abilities, as do many modern languages not on the JVM, so I'm not sure what being "functional" has to do with his omission.
He only considers statically typed languages to be worthy. He doesn't spend much time on Groovy, writing it off as a scripting language. That is my take on why he left it out.
There is a comment from the author that states he hasn't mentioned Clojure because it's FP language. He doesn't go into details bit it looks like he just skipped everything that doesn't support class based OOP. Scala has this feature.
Clojure supports this though.
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.
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.
Clojure supports class based OOP? Never heard of it. Could you give me a link to the relevant documentation page?
Not really a OOP programmer, but I think the following cover some reasonable subset of OOP:
https://clojure.org/reference/multimethods
https://clojure.org/reference/protocols
https://clojure.org/reference/multimethods
https://clojure.org/reference/protocols
Clojure supports protocols and multi-methods, the building blocks of CLOS, Common Lisp Object System.
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.
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.
Via records (defrecord) and protocols.
He also doesn't mention BeanShell, which there's no excuse for forgetting, considering it was a direct competitor for Groovy, or JRuby/Jython/Rhino, which could be excused for excluding since they're ports of other languages to the JVM.
This article is very poorly thought out. First and foremost it talks about the __fall__ of JVM languages yet it forecasts good things for all of those languages.
The author also failed to check out things like the TIOBE index where Java is still at the top.
Not to mention that Clojure hasn't even been mentioned which is a __huge__ letdown since Clojure is the only pure functional language which is native to the JVM.
I agree. There are many points and oddities in this article that make it a poor source of information on the topic. Actually, not just a poor source, a misleading one.
The title is clickbaity, that's all.
You may also be interested in Eta. Clojure reaslly isn't pure functional, strictly.
The TIOBE index is a complete farce. Scratch at 19 and Scala 28? How many Scratch jobs are there on Indeed.com?
Java, the only language where you can consistently get work by just showing up to an interview, is not falling at all.
If anything, it will stay here for decades thanks to so many enterprise and massive projects relying on it.
If anything, it will stay here for decades thanks to so many enterprise and massive projects relying on it.
I remember reading so many headlines like "email is dead" over the years. Email is not dead according to every pop-over i see but all those 'replacements' are.
There are very, very few technologies that are 'winners' (pick your own meaning) in the long run. Choose wisely.
There are very, very few technologies that are 'winners' (pick your own meaning) in the long run. Choose wisely.
> I started developing in Java, late 2001. At that time, Java was really cool.
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.
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.
The Java servlet API and ecosystem was quite cool at least in the early years, IMO. Very simple and elegant model, and I did some commercial work with Java servlets. There were 3-rd-party servlet engines (before they started calling them fancier names like containers after J2EE v1 started :), like LiteWebServer and JRun (good fun using them), apart from the Sun reference implementation and and more heavyweight ones like Tomcat which came a bit later, IIRC. I remember following the Tomcat mailing list for some time, and there was intense activity on it for a long time. Also used Tomcat and JBoss later in a few projects. I sometimes mention Jason Hunter's O'Reilly book "Java Servlet Programming" (1st edition) as one of the best programming books I've read, both for the content and the quality of the writing and the code examples.
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.
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.
I've been using play + java 8 for the past two years. Have been quite happy with it. I did php and node.js before, and I can't say I'm missing anything in particular from those ecosystems. Build times could be a tad better, and some aspects could use more documentation, but the code is easy to write and maintain and the app is blazing fast and easy to deploy. I've gotten the same positive feedback from other web devs that joined my team. They all like it.
Thanks for the info. Might check out Play. Yes, Java performance is fast. I had read that Sun had put millions of dollars into making it fast [1], hiring very qualified people to work on the compiler, the JIT engine, etc., over a period of many years. And the speed difference between early and later Java versions was perceptible.
[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.
[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.
I believe Kotlin code runs close to Java speed which is another reason it might catch on.
Good point. Looking a bit like Kotlin is worth checking out, based on the comments in this thread, and also that other one some days ago, which was triggered by Steve Yegge's post about it. The only one drawback I can think of as of now, is that it is only being developed by one company - JetBrains (unless it is open source and allows and has contributors, which I have not checked).
Update: I checked, it is open source:
>In February 2012, JetBrains open sourced the project under the Apache 2 license
from:
https://en.wikipedia.org/wiki/Kotlin_(programming_language)
Update: I checked, it is open source:
>In February 2012, JetBrains open sourced the project under the Apache 2 license
from:
https://en.wikipedia.org/wiki/Kotlin_(programming_language)
These days a new language which isn't open source wouldn't have much of a chance, I reckon.
Question is are you using the term open source strictly as it is meant, i.e. the source is available, or as some use it, loosely, to mean both open source and free (as in beer)? [1]
[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.
[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.
Just checked and saw this:
https://github.com/JetBrains/kotlin-native
So Kotlin Native may be another good reason, once it is stable.
https://github.com/JetBrains/kotlin-native
So Kotlin Native may be another good reason, once it is stable.
Java was cool when I started using it "in anger" in 1995. It was going to be a totally new way of delivering software on the fly over the network (that's why all the package names look like reverse domain names). I moved to Python when Java gave up on the dream and became the new COBOL after the dotcom crash.
Package naming never had anything to do with software delivery over the network. The reverse domain name thing was just a convenient way to deconflict the namespace by leveraging the existing DNS and registrars. And it's just a convention, not actually enforced anywhere or used in any network code.
Right, and I guess it was also done that way (reversed domain name followed by different suffixes for the leaf names for the actual packages) so that it would be easier to see at a glance that some packages were from the same (reversed) domain, indicating from the same creator.
E.g.
com.sun.java.foo
com.sun.java.bar
com.ibm.foo2
com.ibm.bar2
etc.
E.g.
com.sun.java.foo
com.sun.java.bar
com.ibm.foo2
com.ibm.bar2
etc.
> It was going to be a totally new way of delivering software on the fly over the network
That sounds really interesting! Has any documentation survived about that?
That sounds really interesting! Has any documentation survived about that?
Lots. See https://en.wikipedia.org/wiki/Java_applet and https://en.wikipedia.org/wiki/Java_Web_Start for links.
You forgot Jini, https://en.wikipedia.org/wiki/Jini
Also Oberon was another system that also allowed for something like Java applets, called Juice.
http://www.modulaware.com/mdlt69.htm
Also Oberon was another system that also allowed for something like Java applets, called Juice.
http://www.modulaware.com/mdlt69.htm
Also Java RMI, Remote Method Invocation, which was an OO RPC API for Java, and the basis for higher layers:
https://en.wikipedia.org/wiki/Java_remote_method_invocation
https://en.wikipedia.org/wiki/Java_remote_method_invocation
And Marimba Castanet
And somewhat less well known, probably, but cool and potentially useful, nonetheless: ObjectSpace Voyager. It was a framework for mobile code / agents / distributed computing. I tried it out a bit, liked it. ObjectSpace were also the company that came out with JGL - the Java Generics Library, a commercial library for generics in Java, some time before Java itself got generics or even before the Java Collections API came out. I think JGL was inspired by C++'s STL (Standard Template Library).
ObjectSpace Voyager was a supremely well designed piece of software - it made complicated things simple.
It was also a bit ahead of the time, or perhaps not marketed well.
It was also a bit ahead of the time, or perhaps not marketed well.
>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.
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.
Ugh, yes, so I did, though that was less about software deployment.
None of these examples are especially illuminating here. In my opinion, two things really exhibit this "code over the network" nature; the class URLClassloader that's been in Java forever and the JVM SecurityManager system. URLClassLoader will load bytecode from any url; give it a url to a jar at some domain and it'll load it. The JVM security model was intended to let app developers define exactly what code could be executed, and what resources could be accessed on the client machine.
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.
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.
> 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.
Well, we’re back to it with webassembly now. Everything old is new again.
software agents running on arbitrary machines on the network" never took off, seems kind of foolhardy in hindsight
We call software agents "containers" now and arbitrary machines on the network "cloud" but it is the same thing...
We call software agents "containers" now and arbitrary machines on the network "cloud" but it is the same thing...
That's really not even closely related. Please educate yourself so I can have intelligent discussions.
https://en.wikipedia.org/wiki/Software_agent
https://en.wikipedia.org/wiki/Software_agent
Java Web Start is still really useful for desktop applications in the corporate setting, though Oracle isn't putting much effort into it.
There were quite a few articles about Java in 90s Wired (which, like Java, was considered cool for a brief moment in the 90s).
https://www.wired.com/1995/12/java-saga/ https://www.wired.com/1998/02/java-talk-with-gosling/
https://www.wired.com/1995/12/java-saga/ https://www.wired.com/1998/02/java-talk-with-gosling/
It surely was cool, on my university department they completely changed all compiler design and distributed computing classes to be based on Java by 1997, just one year after it got released.
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.
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.
Agreed. I started with Java in 96 or 97; pretty much from the beginning. For me the big win with Java as the HTML documentation of the JDK. It meant I didn't have to grep around the file system and header files to figure out what abstractions I was meant to use.
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.
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.
By 2001 a lot of the problems java was designed to address were going away for other reasons. When it first came out it had some major advantages: It was free, so you could try it in the corporate setting without spending thousands of dollars, and your application would work on multiple operating systems without a recompile.
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 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 was still deep into C++ back then, Java was a sweet deal versus the pain of trying to write portable C++ with compilers trying to catch up with the ongoing work for the first version of the standard.
I found it cool in the "approachble, usable" sense. At least I got a lot further than with C++. (My background at the time was purely Visual Basic and PHP). Then again I am still not a fan of C++ today :P
I tend to agree here. But wasn't that the sorry state for like all languages out there? Or at least a combination of the reasons you mention.
Yeah, in hindsight it wasn't a great time for programming languages in general...
Exactly, back up a few years and it was still a buggy and bloated slow piece of shit. Which is the reason why Google decided to go with Python in the 90's when Java was the original language their search engine was written in.
> As someone who was there in 2001, I just have to say: Java was never cool, and especially not at that time.
It was so uncool they named JavaScript after it.
It was so uncool they named JavaScript after it.
that was earlier than 2001 I believe
1995. Interesting because Java was initially Oak, and JS was LiveScript. But then Netscape & Sun got together. Sun wanted Java to be the language in the browser, Netscape wanted an easy to use lightweight language, Brendan Eich thought he would be putting Scheme in the browser, and the end result of all that was JavaScript. But Netscape 2 was also supposed to ship with the JVM and a canvas-like platform for both to target. However, it was too ambitious, so only JS made it.
You forget scala-native project: https://github.com/scala-native/scala-native
It seems to have major traction looking at contributions trend.
Together with scala.js it open up the scala language to three different outputs: native (LLVM), js and JVM. Great strategy in my opinion.
I'm surprised to see that Groovy slightly beats Kotlin in on that graph. I really underestimated Groovy popularity, or overestimated Kotlin.
I've yet to work with Kotlin but did like Groovy some years ago. Never used it professionaly though, only for play-projects.
I've yet to work with Kotlin but did like Groovy some years ago. Never used it professionaly though, only for play-projects.
Is it possible that it's skewed because Gradle (build system used for pretty much all Android applications and many standard Java applications) uses Groovy as it's configuration file language? Causing a misdetection (e.g. most Android Kotlin projects would show up as Groovy as well) ?
It always blows my mind when everyone seems to forget Groovy. Especially since Kotlin is very very similar (well, syntactically anyway). The difference of course is that Groovy has full Spring support, Gradle, Spock etc.
Maybe Gradle is the 'killer app' that keeps Groovy popular? I've heard from people with tricky build tool requirements that it's one of the best options out there.
I see Groovy in 3 places: Gradle files (a Kotlin alternative is coming), Jenkins pipeline build scripts, and the Spock testing framework.
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.
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 files (a Kotlin alternative is coming)
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.
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.
Kotlin has its own build system - Kobalt.
We've stuck with Grails for a few years now and I still prefer it over vanilla Spring Boot. Things like JSON views and GORM are still really nice to have.
groovy is great. It doesn't have much marketing behind it, so it's seems to be a bit of a quiet achiever. But for dsl makin', groovy is such a good language.!
We use Groovy in production, working with SQL, Transactions or JSON is much easier than Java. Meta programming and Traits are other advantages. The biggest advantage is that it is so similar to Java code, that any Java developer can pick it up and understand it immediately.
We still love and use Java a lot and they both complement each other very well.
We still love and use Java a lot and they both complement each other very well.
> it is so similar to Java code, that any Java developer can pick it up
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.
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.
We use Groovy at my work in a majority of our projects as well. I love traits and some of the other shortcuts and I don't feel like I'm too far away from Java that I couldn't work in it immediately.
Groovy has the best testing framework that I have ever used, Spock.
When I write .Net code I really miss it, there is nothing that I found as powerful, even using F#.
What do you miss that's not in F#? Legitimately curious, since F# is the language I miss (or wish to use, I suppose) the most at the moment.
It's the overall experience that is great.
Creating a stub or a mock with just:
IMyService myService = Stub() // Mock()
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.
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.
The killer feature of Groovy is Spock tests. It really shines there.
sincerest form of flattery?
http://spekframework.org
http://spekframework.org
Kotlin-based Spek uses standard lambdas for defining specs, whereas Spock digs into the Apache Groovy parser to change the meaning of labels in the syntax, as well as uses operator overloading. One's elegantly functional, the other's a cheap hack.
I'm JVM guy and really wish this platform has something like F# - "minimalistic" functional language (not like Scala) with static, powerful type system (not like Clojure).
Have you seen Frege and Eta?
https://github.com/Frege/frege
http://eta-lang.org
https://github.com/Frege/frege
http://eta-lang.org
eta looks interesting for Haskell refugees in Java-land..
That being said, any idea why they started from scratch instead of building on or contributing to frege?
That being said, any idea why they started from scratch instead of building on or contributing to frege?
They had ideological differences, Frege focusing on the Haskell standard, Eta on "whatever GHC does".
Pure FP language communities have a lot in common with extreme left movements where small differences can lead to complete forks. There seems to be an equivalence between purity and intolerance.
[deleted]
It's too bad, because Scala could have been more judicious in how it marketed this. Scala has a lot of nice features, but its a very disorienting environment when it's used as a "backwards haskell".
I've been writing a bunch of scala and it does feel like there's an elegantly minimal language hiding in a somewhat baroque one. The trouble is that I can't really point at what parts are the minimal subset and what parts are excessive. Even the truly weird stuff like implicit defs and package objects make sense in some contexts. It suffers from the same problem as C++, individually the features make sense, but combined they're too much.
Yes, it's the combination of features that's problematic. They don't compose well. I'd also say implicits are probably responsible for many developers rejecting Scala outright. They're an abomination as far as maintainability and IDE integration are concerned.
The whole getter/setter argument is trite. Project Lombok has been around for years and resolves that issue as well as many more.
You end up needing more-or-less your whole ecosystem to understand Lombok - your IDE, debugger, profilers, linters, code coverage tools... it ends up being just as much effort as switching languages.
Yep, my thoughts exactly. I tried lombok when I was coding in Java and ended up dumping it beause it had more issues than it tried to solve.
Lombok has a lot of issues. First and foremost it won't compile for people who don't bother installing it for their IDE. This greatly hampers OSS collaboration because it raises barriers of entry. I know there is delombok but the whole stuff comes with a lot of drawbacks. Reorganize my project just to delombok my project...whoa...
It is nearly impossible to code any amount of Java without a proper IDE (Eclipse/IDEA). Or at least it isn't a sane decision to do so. Lombok is well supported in both of those IDE, especially for the use case of @Data/@Getter/@Setter. Installing it is just as easy as adding any other dependency (especially in IDEA with it's plugin ecosystem). It really is too bad this isn't just installed as default in the IDE though. Heck, I'd even suggest it be part of the language itself. But for now, we just shrug, install it and get back to coding. =)
True, but it's not trivial to adopt.
No mention of Clojure? It should defiantly be mentioned as on of the big JVM languages. Though I get that it maybe isn't what the author was looking for I'm a bit surprised it was totally overlooked.
> I decided Scala made it too easy to write code unreadable for most developers
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'.
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'.
Scala is the Perl of the JVM. :D
I have heard that before. I like(d) Perl. Got me tempted to try Scala.
Then don't. I couldn't think of two languages more different in every way.
They are similar in a way that none of them is readable. At least Perl is writable...
I find scala infinitely more readable than java. For starters I do not have to skip pages and pages of boilerplate, unless some genius decided to do 1 to 1 translation of his java code
Then don't. I couldn't think of two more different languages.
Whats so bad about Scala? It does seem to get a similar "either you love it or you hate it" response from people.
I think the audience is the problem. Java devs prefer Java and Haskell devs prefer Haskell. Aside from some rare open minded individuals and people who have to write java, but would prefer to work with Haskell, Scala is up against a tough crowd.
I wonder why Kotlin beat Scala in this virtual programming language traction game. I don't write code for the JVM anymore, but Kotlin occupies the same space as Scala.
Was it compilation speed? Corporate support?
Was it compilation speed? Corporate support?
Scala is much more complex language. Kotlin is more complex, than Java, but its complexity is just enough to cover major Java pain points.
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.
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.
>"Kotlin is more complex, than Java, but its complexity is just enough to cover major Java pain points."
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?
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?
That's incorrect. Right now I do all my development in Kotlin at my workplace and on the backend. We use Spring (which has native Kotlin support from 5.0 btw: https://spring.io/blog/2017/01/04/introducing-kotlin-support...) and deploy to a Kubernetes cluster. It is absolute seamless. I'll never write server-side code in Java again if I can help it.
> Would you mind elaborating on what those Java pain points are that Kotlin smoothes over?
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.
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.
Thank you for the detailed response. Cheers.
> Last time I checked, Intelij Idea wasn't able to parse even standard Scala library without errors.
Kotlin is a much simpler language than Scala.
Kotlin is a much simpler language than Scala.
Probably because it was built to seamlessly interoperate with existing Java code and targeted JVM 6 compatibility (it was built to make development of IntelliJ IDEs simpler which had to run on Java 6 VMs and which already had a lot of code written in Java).
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.
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.
> I wonder why Kotlin beat Scala in this virtual programming language traction game.
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:
https://www.indeed.com/jobtrends/q-scala-q-kotlin.html
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:
https://www.indeed.com/jobtrends/q-scala-q-kotlin.html
I've been using Scala for a long time.
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.
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.
Thanks will use it, doesn't change the fundamental problem of error messages and multi-line type expressions.
Would wish for that attitude:
http://elm-lang.org/blog/compiler-errors-for-humans
Would wish for that attitude:
http://elm-lang.org/blog/compiler-errors-for-humans
> I wonder why Kotlin beat Scala in this virtual programming language traction game. I don't write code for the JVM anymore, but Kotlin occupies the same space as 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.
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.
That's incorrect. Scala had 13 years to achieve something while Kotlin is only around for a few years. If you extrapolate the current trends you will see that Kotlin will surpass Scala __very__ soon.
Kotlin is 6 years old, so about half the age of Scala - and, despite the heavy marketing, less than half the popularity on the chart in the article. We'll see what happens; Scala's growth has been slow and organic, but the flipside of that is that its success is down to the merits of its design.
(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)
(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)
Not really. If you check google trends now you can see that it _surpassed_ Scala after the Google announcement and while it was a bump in trends if you extrapolate the trend it you can see that it will surpass Scala within a year. Higher kinded types in themselves don't have any business value so I don't see why it can't be displaced by Kotlin or Clojure. I don't see any "anti-intellectual hostility" either. Actually I'm working on a library which wraps Clojure's STM and persistent data structures. 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. 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 (thus it lacks direction as well).
> Higher kinded types in themselves don't have any business value
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.
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.
> They make it much easier to fulfil business requirements in a clear, maintainable way
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.
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.
> Same stands for dsls, macros, multimethods, I can mean any feature in any language. HKTs are just one tool of many.
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).
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).
Along with implicits, the lack of a central Scala repository was the biggest turn-off for me.
Huh? Everything worth bothering with is in maven central, the same place as all the Java libraries worth bothering with.
Ask yourself why Clojure, which is also a JVM language, has Clojars. What happens if I want to browse Scala libs I don't already know about?
I don't think I've ever browsed through any language's set of libraries - for any serious language there are far too many libraries for that to be useful. The only reason I've ever used e.g. PyPI is to look for a library for doing something specific, and I've never had trouble finding libraries for doing a given thing in Scala.
It's 6 years old if you count from the time it started development.
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.
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.
Sure, but if you're measuring that way then Scala is a lot less than 13 years old.
Exactly, that's what I meant. Traction is more like acceleration than it is speed.
Not using scala or Kotlin. But if others think like me, I bet the scala syntax is stopping them from touching it with a stick.
Yep I'm not even not touching it I'm not looking either. Kotlin is 1000x times more readable and writable.
I don't know much about Kotlin but whenever I see code samples, it sure looks like it borrows heavily from Swift.
Here's what Chris Lattner said about Kotlin this past June:
"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...
"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...
I'm not a Java guy, but I'm still wondering why nobody every wrote a JVM with near-zero startup time.
Well I am a Java guy and have two points to make.
First. What are you even talking about?
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?
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?
> So seriously, Hacker News, what is the obsession with this?
We are dilettantes, we think there is always something that could be improved in a domain we don't fully understand.
We are dilettantes, we think there is always something that could be improved in a domain we don't fully understand.
The obsession with this is that people would like to be able to use their favourite JVM language to write CLI tools, consumer-GUI tools or AWS lambda programs. Sure, you can just say that the JVM is the wrong tool, but that is a somewhat unsatisfying answer because it still doesn't let me write those things in clojure/scala or whatever JVM language.
>it still doesn't let me write those things in clojure/scala
If you're writing Scala, you have the option of compiling with scala-native, which targets LLVM.
http://www.scala-native.org/en/latest/
If you're writing Scala, you have the option of compiling with scala-native, which targets LLVM.
http://www.scala-native.org/en/latest/
They can, it is their problem if they keep ignoring the existing AOT compilers, and there are quite a few.
Are there any without an expensive license?
OpenJDK 9 if on Linux x64, but it is still not yet released.
ExcelsiorJET has a free license for non-commercial uses.
https://www.excelsiorjet.com/
https://www.excelsiorjet.com/#free
RoboVM's fork is another possibility
https://github.com/MobiVM/robovm
ExcelsiorJET has a free license for non-commercial uses.
https://www.excelsiorjet.com/
https://www.excelsiorjet.com/#free
RoboVM's fork is another possibility
https://github.com/MobiVM/robovm
Because it's an axis of numerical optimization that can be carried out of context anywhere, freely ignored or harped upon at will.
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.
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.
The obsessions are because you can have serverless architecture and spin up things on demand.
If you Need to load a ton of things that kills performance and latencies add up.
This is for an empty program. Serious Java programs (especially those that pull in a lot of libraries) can easily take >1s to start up. Running jruby on an empty file takes 1.4s wall clock time and nearly 4s of CPU time for me. Time to compile a hello-world program with Kotlin is 1.9s wall clock time and over 4s CPU time. It's worse with Scala.
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.
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.
> Serious Java programs (especially those that pull in a lot of libraries)
So, which language allows serious programs do a lot of work without time penalty?..
So, which language allows serious programs do a lot of work without time penalty?..
The JVM languages usually add their own heavy libraries. I believe the JVM is optimized for loading the standard library as quickly as possible but this optimization doesn't apply if you use a JVM language that comes with it's own libraries.
> So seriously, Hacker News, what is the obsession with this?
We are optimists, we think there is always something that could be improved.
We are optimists, we think there is always something that could be improved.
Is that optimism or pessimism? ;-)
"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)
"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)
I'd imagine most people here are just web developers and haven't used anything beside nodejs in a professional environment, so their first reaction to java is "oh, I have to restart the server everytime I change a web page? that's a pain".
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)
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)
The JVM supports hot swapping. There's also DCEVM⁰, which supports more features than OpenJDK Hotspot.
⓪ - https://github.com/dcevm/dcevm
⓪ - https://github.com/dcevm/dcevm
There is no need to restart the server all the time, it depends on the type of change.
When using plain JSPs with exploded WARs, you can usually hot reload.
When using plain JSPs with exploded WARs, you can usually hot reload.
Because they already exist, people outside JVM world just aren't aware of them.
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.
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.
You have to remember that the general bias on Hacker News is that if you have to pay for it, it doesn't exist.
A few years back I built a system that ran in the background and spun up fresh JVMs, which it then kept in readiness. When you wanted to start something, it would use the waiting one so you avoided the slowdown. Well, it was still pretty slow...
I don't run any client-side Java apps. But I do run quite a few server-side ones - like ES. Yes, startup time isn't lightning-fast, but once it's up - it's up for months.
I can wait 15 seconds. Its cool.
I can wait 15 seconds. Its cool.
It's largely to do with standard library class loading. The only way to avoid this is an alternate compilation model, like GCJ (and other native code compilers) or Dalvik.
If you've got some good ideas of how to achieve this that you've been keeping to yourself then please share them!
Presumably it isn't easy to start everything the JVM needs & does in effectively no time. Although to be fair it actually is fairly quick for a "hello world" type program - much of the startup time of Java programs tends to be loading bytecode of their dependencies rather than starting the JVM itself.
AOT compilation and Project Jigsaw coming up in Java 9 should improve the JVM startup time. Although I guess it won't speed up the loading of applications written in other JVM languages much as it's not really JVM's fault.
[deleted]
He fails to mention Golo.
I wish .net CLR would take its place instead. For one thing, as strange as that may sound, I trust today's MS more than I trust Oracle. For another, CLR as of 12 years ago (not to mention now) was already better suited for programming language development than JVM ever will be, owing to having less baggage and reified generic types support built in from the start.
TFA mentions Groovy but not JavaScript which could be considered Java's direct dynamic/scripting variant given JavaScript's origin. In fact, there are two mainstream implementations of it even (rhino, nashorn), though not upgraded to ES2015.
Java and JavaScript are not directly related. JavaScript added Java to the name for marketing purposes. JavaScript doesn't run on the JVM like the rest of these languages
I'm well aware what Java is, given I'm developing for it (and other things) since 1997 ;)
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.
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.
I hope this is trolling :D
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.