8 ms·

Also, what advantages, except existing code bases, does Java provide to Kotlin, Go, Swift, Rust? For about any use case I can imagine a better choice than Java.

Also, what advantages, except existing code bases, does Java provide to Kotlin, Go, Swift, Rust? For about any use case I can imagine a better choice than Java. Also, concerning the recent events (Google vs. Oracle), I think every new project might want to triple check if they really want to use a product from someone like Oracle.

pron 10y ago
Kotlin is a JVM language, and doesn't really compete with Java (the two are "friendly"). Rust is a low-level language which is much better suited than the JVM to memory-restricted environments, but JVM languages (including Java) are much easier (therefore cheaper) to develop, so are a better choice for server-side applications. Go and Java are indeed very similar, but I find that Go is better for smaller programs and Java is better for larger ones (due to amazing monitoring, polyglotism, dynamic code loading etc.).
- pjmlp 10y ago
  Yeah, Rust is not the real adversary. The real adversaries are Objective-C, Go, Swift, .NET Native, C++14, OCaml, Haskell and even node.js. Monitoring tools similar to VisualVM will come. Nowadays my Java code is either targeted at Android or maintenance of existing enterprise code. Other than that we aren't using it for greenfield projects.
  - the8472 10y ago
    > Monitoring tools similar to VisualVM will come. Well, in java-land visualvm already exists and is more of an entry-level/free tool with its big brothers available if it should prove insufficient. Java tooling is amazing, I miss it in most other languages.
  - pron 10y ago
    It seems to me that companies that choose non-JVM languages (with the exception of .NET) for important server-side projects are those that have always opted for the flavor-of-the-month. Most of those using Go/Elixir/OCaml/Haskell today, are those that used PHP, Ruby, Python or Node yesterday, and are likely to pick something new tomorrow. All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM. Those problems are sometimes obscured by the novelty and promise of the shiny alternative, and take a while to be felt among those who always opt for the new thing, but they are invariably discovered later on, and by that time something newer comes along, whose problems are yet unapparent. The problems are there because unlike Java and the JVM (and Fortran, COBOL, C and Rust), those platforms were not developed after careful consideration of the industry's needs (Erlang/Elixir is a different story, and, indeed its fundamental problems are more environmental than technical). In addition, in smaller/less-critical projects, Java was an accidental leader in a short period of time where the competition disappeared and Java itself was novel, but it was never "supposed" to be there to begin with. VB and Delphi were very popular choices early on. I'd estimate that even when Java was the shiny new thing, VB, Delphi and other rapid-development languages had a larger share of the market than Go, Node, Ruby, Python, Haskell and OCaml combined today. And frankly, I don't see companies developing en masse large-scale applications in C++14. Unless you have very specific needs, there's just no reason to go there and pay a higher development cost, and if you do have those needs, you're probably already there. In large corporations (including trendy ones, like Google, Amazon, Netflix, Twitter and many more, let alone more conservative ones) the JVM still reigns supreme, with competition lagging far, far behind. I'm not saying it won't eat into the JVM's market share -- although they're mostly cannibalizing one another -- but I don't see any potential leader in the pack. It's possible that there won't be one, with many sharing the cake. So I think that (again, with the notable exception of .NET) the non-JVM market is composed of novelty-seeking organizations and a share that wasn't Java's to begin with, but accidentally was for a short while (the two segments intersect).
    - geodel 10y ago
      Well if applications of future are to be developed and delivered as it is today Java will very likely remain primary choice. But with containerized deployment Java solutions looks rather heavyweight. Oracle/IBM/SAP know this. I think that's why work on Java EE 8 is kind of stalled. Java GC/ memory shortcomings become visible when companies like Netflix push it to limit e.g http://techblog.netflix.com/2016/05/application-data-caching-using-ssds.html http://techblog.netflix.com/2016/05/application-data-caching... They specifically mention: > ... The decision to use Go was deliberate, because we needed something that had lower latency than Java (where garbage collection pauses are an issue) and is more productive for developers than C, while also handling tens of thousands of client connections. Go fits this space well.
      - pron 10y ago
        Go's advantage when it comes to GC is very temporary. HotSpot's GCs are more advanced, and Go has the upper hand only thanks to value types, which are coming to Java. Go will not come close to catching up by then. I think that containerized deployment is likely to evolve and change at a much faster pace than development platforms, so it's really hard to tell which approaches would fit where.
        aardvark179 10y ago
        Also Go's GC doesn't move objects, which makes the whole problem a lot easier as long as heap fragmentation doesn't end up biting you badly in the end.
        geodel 10y ago
        Java release cycle is ~3yrs so Java 10 will be roughly expected in 2020/21 time frame. And at that point larger ecosystem like Apache etc will start taking advantage of value type. So it is like 6-8 years from now which I would not characterize as very temporary. Also this is assuming Go committer from now onwards just sit and do nothing about performance improvements which again seems quite unlikely. Java has 15 year head start on Go and if a newer Go GC beats very mature hotspot GC it could either mean Hotspot advantage is largely in theory or it has reached its peak performance and there is not much scope to improve further.
virmundi 10y ago
A lot of tooling. Eclipse just works. You don't have to use Intellij. Spring makes most things a breeze. Maven handles dependencies and complex builds easily. A lot of the language issues disappear with the right, battle tested tooling.
kpil 10y ago
One benefit is the extremely large set of 3rd party libraries and tools. It's hard to catch up outside the mainstream bread and butter stuff. Also, finding experienced developers, devops, etc. While Kotlin is interesting, and can use java code, maybe it's a little too small and have less battle tested toolchains so java probably feels like a slightly safer bet for large projects and conservative organisations.

pron 10y ago

Kotlin is a JVM language, and doesn't really compete with Java (the two are "friendly"). Rust is a low-level language which is much better suited than the JVM to memory-restricted environments, but JVM languages (including Java) are much easier (therefore cheaper) to develop, so are a better choice for server-side applications. Go and Java are indeed very similar, but I find that Go is better for smaller programs and Java is better for larger ones (due to amazing monitoring, polyglotism, dynamic code loading etc.).

pjmlp 10y ago
Yeah, Rust is not the real adversary. The real adversaries are Objective-C, Go, Swift, .NET Native, C++14, OCaml, Haskell and even node.js. Monitoring tools similar to VisualVM will come. Nowadays my Java code is either targeted at Android or maintenance of existing enterprise code. Other than that we aren't using it for greenfield projects.
- the8472 10y ago
  > Monitoring tools similar to VisualVM will come. Well, in java-land visualvm already exists and is more of an entry-level/free tool with its big brothers available if it should prove insufficient. Java tooling is amazing, I miss it in most other languages.
- pron 10y ago
  It seems to me that companies that choose non-JVM languages (with the exception of .NET) for important server-side projects are those that have always opted for the flavor-of-the-month. Most of those using Go/Elixir/OCaml/Haskell today, are those that used PHP, Ruby, Python or Node yesterday, and are likely to pick something new tomorrow. All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM. Those problems are sometimes obscured by the novelty and promise of the shiny alternative, and take a while to be felt among those who always opt for the new thing, but they are invariably discovered later on, and by that time something newer comes along, whose problems are yet unapparent. The problems are there because unlike Java and the JVM (and Fortran, COBOL, C and Rust), those platforms were not developed after careful consideration of the industry's needs (Erlang/Elixir is a different story, and, indeed its fundamental problems are more environmental than technical). In addition, in smaller/less-critical projects, Java was an accidental leader in a short period of time where the competition disappeared and Java itself was novel, but it was never "supposed" to be there to begin with. VB and Delphi were very popular choices early on. I'd estimate that even when Java was the shiny new thing, VB, Delphi and other rapid-development languages had a larger share of the market than Go, Node, Ruby, Python, Haskell and OCaml combined today. And frankly, I don't see companies developing en masse large-scale applications in C++14. Unless you have very specific needs, there's just no reason to go there and pay a higher development cost, and if you do have those needs, you're probably already there. In large corporations (including trendy ones, like Google, Amazon, Netflix, Twitter and many more, let alone more conservative ones) the JVM still reigns supreme, with competition lagging far, far behind. I'm not saying it won't eat into the JVM's market share -- although they're mostly cannibalizing one another -- but I don't see any potential leader in the pack. It's possible that there won't be one, with many sharing the cake. So I think that (again, with the notable exception of .NET) the non-JVM market is composed of novelty-seeking organizations and a share that wasn't Java's to begin with, but accidentally was for a short while (the two segments intersect).
  - geodel 10y ago
    Well if applications of future are to be developed and delivered as it is today Java will very likely remain primary choice. But with containerized deployment Java solutions looks rather heavyweight. Oracle/IBM/SAP know this. I think that's why work on Java EE 8 is kind of stalled. Java GC/ memory shortcomings become visible when companies like Netflix push it to limit e.g http://techblog.netflix.com/2016/05/application-data-caching-using-ssds.html http://techblog.netflix.com/2016/05/application-data-caching... They specifically mention: > ... The decision to use Go was deliberate, because we needed something that had lower latency than Java (where garbage collection pauses are an issue) and is more productive for developers than C, while also handling tens of thousands of client connections. Go fits this space well.
    - pron 10y ago
      Go's advantage when it comes to GC is very temporary. HotSpot's GCs are more advanced, and Go has the upper hand only thanks to value types, which are coming to Java. Go will not come close to catching up by then. I think that containerized deployment is likely to evolve and change at a much faster pace than development platforms, so it's really hard to tell which approaches would fit where.
      - aardvark179 10y ago
        Also Go's GC doesn't move objects, which makes the whole problem a lot easier as long as heap fragmentation doesn't end up biting you badly in the end.
      - geodel 10y ago
        Java release cycle is ~3yrs so Java 10 will be roughly expected in 2020/21 time frame. And at that point larger ecosystem like Apache etc will start taking advantage of value type. So it is like 6-8 years from now which I would not characterize as very temporary. Also this is assuming Go committer from now onwards just sit and do nothing about performance improvements which again seems quite unlikely. Java has 15 year head start on Go and if a newer Go GC beats very mature hotspot GC it could either mean Hotspot advantage is largely in theory or it has reached its peak performance and there is not much scope to improve further.

virmundi 10y ago

A lot of tooling. Eclipse just works. You don't have to use Intellij. Spring makes most things a breeze. Maven handles dependencies and complex builds easily. A lot of the language issues disappear with the right, battle tested tooling.

kpil 10y ago

One benefit is the extremely large set of 3rd party libraries and tools. It's hard to catch up outside the mainstream bread and butter stuff. Also, finding experienced developers, devops, etc. While Kotlin is interesting, and can use java code, maybe it's a little too small and have less battle tested toolchains so java probably feels like a slightly safer bet for large projects and conservative organisations.