7 ms·

The author misses the point when he says this might help Java regain share in the space of DevOps tools which is currently mostly Go. The problem is not artifa

The author misses the point when he says this might help Java regain share in the space of DevOps tools which is currently mostly Go. The problem is not artifact size but the JVM slow start-up time. This is made worse by almost all Java frameworks that by definition do all their own stuff before passing control to your real app code. Such executables are not something you would put in a loop in a shell one liner, and that is the space for command line utilities Go has occupied successfully.

twic 9y ago
The JVM doesn't suffer from slow start-up time: https://purelyfunctional.tv/article/the-legend-of-long-jvm-startup-times/ https://purelyfunctional.tv/article/the-legend-of-long-jvm-s... But frameworks (and runtimes for things like Clojure) absolutely do. It would be possible to write a fast-starting framework for Java, but i suspect nobody has because there's no demand for it, because nobody who needs fast startup uses Java, because it doesn't start up fast! That said, i think the real reasons Go has done so well in devops are (1) it's easy to pick up for devopsists coming from Perl/Ruby/etc backgrounds, (2) static binaries are easier to deploy than a jar plus a JVM (not massively easier - but easier enough), (3) a focus on systemsy stuff in the standard library and community, and (4) sheer snowballing momentum, in that Go has become the default choice for stuff like that.
- deleted 9y ago
  [deleted]
- userbinator 9y ago
  That's actually pretty fast. Starting the JVM, grabbing the memory for the heap, and then exiting takes one tenth of a second. Things like this are why all the "Java isn't slow" articles miss the point completely --- 100ms to do nothing useful, on a presumably quite fast machine, is ridiculous. For comparison, 100ms is roughly the time it takes to grep an 18MB file: http://dtrace.org/blogs/brendan/2011/12/08/2000x-performance-win/ http://dtrace.org/blogs/brendan/2011/12/08/2000x-performance... (look near bottom of post).
  - lmm 9y ago
    > Things like this are why all the "Java isn't slow" articles miss the point completely --- 100ms to do nothing useful, on a presumably quite fast machine, is ridiculous. "Ridiculous" is like "unprofessional", it's what you say when you don't have a real argument. Yes, ha ha, 100ms, very droll. What does it matter in practice?
StevePerkins 9y ago
By "DevOps tools", I wasn't thinking in terms of `sed`, `awk`, etc. I was thinking in terms of Consul and Vault. Docker and Kubernetes, etc. The major pillars of DevOps today are long-running processes, very complex pieces of infrastructure. Which might play into the strengths of the JVM, if the packaging and deployment story simplifies and becomes more competitive with Go. Sure, "shell one liner" utilities might (?) be best served by native compilation. But DevOps is not merely another word for sysadmin.
benjaminjackman 9y ago
It actually starts surprisingly fast. We had a massive Java / Scala codebase at a previous place and one of our engineers wrote a fairly comprehensive set of command line tools (even featuring command completion) entirely in Scala / Java on a 1.7 jvm just on the off chance it would be fast enough. It actually was totally fine and surprisingly snappy. I’d suggest giving it a shot. I don’t know how to revert the jvm can’t be used for command line tools because of slow startup times zeitgeist but I don’t think it’s accurate anymore.
- tonyarkles 9y ago
  Our Spring Boot apps at work take about 60 seconds from hitting Enter on the JVM command to being able to do something useful. YMMV.
  - okr 9y ago
    Yes, it is a pita, but it is a price to pay for the dependency injection, where many components, services, configs from different projects/libs have to be searched (annotations can hide everywhere), started and then wired together in the order they define 'globally'. And once you change a config property, that tree can change as well. I hope some work will be done there. One could scan the libs in parallel, caching results, building/shipping a search tree on packaging time and so on. In pure servlet times you could directly define your starting points, define, which libs to exclude or include for the search and so on. At least no one has to edit xml files anymore to wire components and impls together.
    - tonyarkles 9y ago
      This statement doesn't necessarily generalize, but I can't say I'm a huge fan of what the Spring-flavoured Dependency Injection ended up looking like around here either. It's like... we've taken on ridiculously long startup times, to turn what would be compile-time errors into run-time errors. Seems like a double-whammy of bad. Maybe I'm a little overly jaded, but the Java apps I've worked on (which is admittedly only a handful) have all had these giant sprawling messes of dependencies; it feels like there's a lot of code to accomplish very little. The Golang-based services I've worked on feel like the opposite; very little code to accomplish a lot of things, without much ceremony. Edit: And that's not to say that I'm opposed to dependency injection; rather, I'm quite happy to do constructor-based dependency injection by hand. When that starts to feel painful, I look at the system I'm working on and wonder if it's getting too complicated/has too much coupling/etc.
tapirl 9y ago
In fact, JVM doesn't start slow. The fact is most Java web apps start slow. The more libraries a Java web app depends, the slower it starts. The current dominant culture of the Java community is very weird. Although Java has a huge standard library, if you don't use a lot of third-party libraries, you will be viewed as a non-professional Java programmer. Most popular Java tech stack look open sourced, but are backed by lots of money provided by many companies with bad reputations on pure open source culture. BTW, slow start-up is not the only problem of many Java apps. GUI Java apps often lag for one or more seconds from time to time, which hurts the experiences of Java GUI apps much. The third problem of Java apps is they often consume much more memory than apps written in other languages, in particular for the long running Java apps. The longer they run, the more memory they will eat. [edit] the library use way of Java, by putting library jars into your projects, is not good as the way of other languages, by putting library sources into your projects. By putting library sources in your projects, you can view how the libraries are implemented easily. Yes, you can also put Java library sources into your projects, but the main stream culture of Java doesn't recommend to do this. Just look at maven. [edit 2] just my personal opinion. I don't like the way to use a separated VM to run many apps. This makes it is hard for me to use a different permission setting for each app. Sometimes I want to block a Java app to access network, but I must block the whole Java VM to achieve this.
- okr 9y ago
  There is nothing bad about opensource stack backed by big money, in my eyes. Second, i am surprised to read, that people would still put dependencies/libs into their projects, even in their source code form? I thought, that was one of the reasons, why dependency management was introduced, to get rid of that. One ships a descriptor, what libs were required/used, when the lib has been packaged. And in one's IDE one can view all the dependencies as one wishes, in binary or source code form. I am very confused about your statement. (though in the final App, one ships all the libs in the packaged form of the app, unless provided by the runtime environment. But only then. Though its optional, one could also download the deps when starting the App) And third: The longer an App runs, the more memory it eats? Its like with any other App: if it needs that much memory and it does not release it afterwards, well, then it is a feature or a bug. If it releases the memory, then it is only released within the JVMs memory space. The common default for thag is 4gb per JVM. Its like the page cache in linux. Once a file has been read into memory, it will usually sit there for a while, unless someone else needs that memory. Thats why on a system with 128gb and a lot of file access, you see free memory going down and down. But its most of the time the page cache eating up that memory and is mostly not a problem. But can be confusing, when one is not familiar with it. Ah, so many things one can tell.
pjmlp 9y ago
> The author misses the point when he says this might help Java regain share in the space of DevOps tools which is currently mostly Go. Maybe in SV, because I am yet to see it being used in any of our projects or hiring processes.
- dullgiulio 9y ago
  I work in a "Fortune 500" company (or whatever the equivalent is called for something in Europe), and we do have Go tools everywhere. Docker and Kubernetes are the most prominent, but there is a whole ecosystem behind them.
  - pjmlp 9y ago
    Not everyone has bought into Docker and Kubernetes. Again, yet to use any of them, beyond watching some talks at a few conferences. Still classical server deployment processes. Of course, companies using software written in Go, are open to use Go somehow.
marmaduke 9y ago
The mention of AOT is promising: quick startup w/ Go-like performance based on static AOT and profile-guided JIT optimization of hot paths.

twic 9y ago

The JVM doesn't suffer from slow start-up time: https://purelyfunctional.tv/article/the-legend-of-long-jvm-startup-times/ https://purelyfunctional.tv/article/the-legend-of-long-jvm-s... But frameworks (and runtimes for things like Clojure) absolutely do. It would be possible to write a fast-starting framework for Java, but i suspect nobody has because there's no demand for it, because nobody who needs fast startup uses Java, because it doesn't start up fast! That said, i think the real reasons Go has done so well in devops are (1) it's easy to pick up for devopsists coming from Perl/Ruby/etc backgrounds, (2) static binaries are easier to deploy than a jar plus a JVM (not massively easier - but easier enough), (3) a focus on systemsy stuff in the standard library and community, and (4) sheer snowballing momentum, in that Go has become the default choice for stuff like that.

deleted 9y ago
[deleted]
userbinator 9y ago
That's actually pretty fast. Starting the JVM, grabbing the memory for the heap, and then exiting takes one tenth of a second. Things like this are why all the "Java isn't slow" articles miss the point completely --- 100ms to do nothing useful, on a presumably quite fast machine, is ridiculous. For comparison, 100ms is roughly the time it takes to grep an 18MB file: http://dtrace.org/blogs/brendan/2011/12/08/2000x-performance-win/ http://dtrace.org/blogs/brendan/2011/12/08/2000x-performance... (look near bottom of post).
- lmm 9y ago
  > Things like this are why all the "Java isn't slow" articles miss the point completely --- 100ms to do nothing useful, on a presumably quite fast machine, is ridiculous. "Ridiculous" is like "unprofessional", it's what you say when you don't have a real argument. Yes, ha ha, 100ms, very droll. What does it matter in practice?

StevePerkins 9y ago

By "DevOps tools", I wasn't thinking in terms of `sed`, `awk`, etc. I was thinking in terms of Consul and Vault. Docker and Kubernetes, etc. The major pillars of DevOps today are long-running processes, very complex pieces of infrastructure. Which might play into the strengths of the JVM, if the packaging and deployment story simplifies and becomes more competitive with Go. Sure, "shell one liner" utilities might (?) be best served by native compilation. But DevOps is not merely another word for sysadmin.

benjaminjackman 9y ago

It actually starts surprisingly fast. We had a massive Java / Scala codebase at a previous place and one of our engineers wrote a fairly comprehensive set of command line tools (even featuring command completion) entirely in Scala / Java on a 1.7 jvm just on the off chance it would be fast enough. It actually was totally fine and surprisingly snappy. I’d suggest giving it a shot. I don’t know how to revert the jvm can’t be used for command line tools because of slow startup times zeitgeist but I don’t think it’s accurate anymore.

tonyarkles 9y ago
Our Spring Boot apps at work take about 60 seconds from hitting Enter on the JVM command to being able to do something useful. YMMV.
- okr 9y ago
  Yes, it is a pita, but it is a price to pay for the dependency injection, where many components, services, configs from different projects/libs have to be searched (annotations can hide everywhere), started and then wired together in the order they define 'globally'. And once you change a config property, that tree can change as well. I hope some work will be done there. One could scan the libs in parallel, caching results, building/shipping a search tree on packaging time and so on. In pure servlet times you could directly define your starting points, define, which libs to exclude or include for the search and so on. At least no one has to edit xml files anymore to wire components and impls together.
  - tonyarkles 9y ago
    This statement doesn't necessarily generalize, but I can't say I'm a huge fan of what the Spring-flavoured Dependency Injection ended up looking like around here either. It's like... we've taken on ridiculously long startup times, to turn what would be compile-time errors into run-time errors. Seems like a double-whammy of bad. Maybe I'm a little overly jaded, but the Java apps I've worked on (which is admittedly only a handful) have all had these giant sprawling messes of dependencies; it feels like there's a lot of code to accomplish very little. The Golang-based services I've worked on feel like the opposite; very little code to accomplish a lot of things, without much ceremony. Edit: And that's not to say that I'm opposed to dependency injection; rather, I'm quite happy to do constructor-based dependency injection by hand. When that starts to feel painful, I look at the system I'm working on and wonder if it's getting too complicated/has too much coupling/etc.

tapirl 9y ago

In fact, JVM doesn't start slow. The fact is most Java web apps start slow. The more libraries a Java web app depends, the slower it starts. The current dominant culture of the Java community is very weird. Although Java has a huge standard library, if you don't use a lot of third-party libraries, you will be viewed as a non-professional Java programmer. Most popular Java tech stack look open sourced, but are backed by lots of money provided by many companies with bad reputations on pure open source culture. BTW, slow start-up is not the only problem of many Java apps. GUI Java apps often lag for one or more seconds from time to time, which hurts the experiences of Java GUI apps much. The third problem of Java apps is they often consume much more memory than apps written in other languages, in particular for the long running Java apps. The longer they run, the more memory they will eat. [edit] the library use way of Java, by putting library jars into your projects, is not good as the way of other languages, by putting library sources into your projects. By putting library sources in your projects, you can view how the libraries are implemented easily. Yes, you can also put Java library sources into your projects, but the main stream culture of Java doesn't recommend to do this. Just look at maven. [edit 2] just my personal opinion. I don't like the way to use a separated VM to run many apps. This makes it is hard for me to use a different permission setting for each app. Sometimes I want to block a Java app to access network, but I must block the whole Java VM to achieve this.

okr 9y ago
There is nothing bad about opensource stack backed by big money, in my eyes. Second, i am surprised to read, that people would still put dependencies/libs into their projects, even in their source code form? I thought, that was one of the reasons, why dependency management was introduced, to get rid of that. One ships a descriptor, what libs were required/used, when the lib has been packaged. And in one's IDE one can view all the dependencies as one wishes, in binary or source code form. I am very confused about your statement. (though in the final App, one ships all the libs in the packaged form of the app, unless provided by the runtime environment. But only then. Though its optional, one could also download the deps when starting the App) And third: The longer an App runs, the more memory it eats? Its like with any other App: if it needs that much memory and it does not release it afterwards, well, then it is a feature or a bug. If it releases the memory, then it is only released within the JVMs memory space. The common default for thag is 4gb per JVM. Its like the page cache in linux. Once a file has been read into memory, it will usually sit there for a while, unless someone else needs that memory. Thats why on a system with 128gb and a lot of file access, you see free memory going down and down. But its most of the time the page cache eating up that memory and is mostly not a problem. But can be confusing, when one is not familiar with it. Ah, so many things one can tell.

pjmlp 9y ago

> The author misses the point when he says this might help Java regain share in the space of DevOps tools which is currently mostly Go. Maybe in SV, because I am yet to see it being used in any of our projects or hiring processes.

dullgiulio 9y ago
I work in a "Fortune 500" company (or whatever the equivalent is called for something in Europe), and we do have Go tools everywhere. Docker and Kubernetes are the most prominent, but there is a whole ecosystem behind them.
- pjmlp 9y ago
  Not everyone has bought into Docker and Kubernetes. Again, yet to use any of them, beyond watching some talks at a few conferences. Still classical server deployment processes. Of course, companies using software written in Go, are open to use Go somehow.

marmaduke 9y ago

The mention of AOT is promising: quick startup w/ Go-like performance based on static AOT and profile-guided JIT optimization of hot paths.