361–370 of 373 posts
Earlier quoted context omitted.
Funny you mention that, that's exactly why we wrote this tool. We were having a ton of support issues with our Windows users having to install Java, incompatible Java versions, needing admin privileges to install the JRE, etc... We fixed this whole class of issues by doing exactly what you suggest: bundling the JRE and writing our own launcher binary.
Does java license interfere with this kind of setup?
Earlier quoted context omitted.
Although the last version I used seriously was VS2013, VS on its own is pretty mediocre. With ReSharper though, nothing beats it in my opinion. On the other hand I've been using Eclipse and IntelliJ for the past year. Eclipse is not even worth talking about but even IntelliJ does not come close to vanilla VS in terms of usability. Again, my opinion.
What is better than VS? PHPStorm etc?
Earlier quoted context omitted.
Gcj was deleted from GCC in October 2016[1]. So only free option left, AFAIK, is to use mono AOT[2]. [1]: http://tromey.com/blog/?p=911 [2]: http://www.mono-project.com/docs/about-mono/languages/java/
Or a copy of GCC from September 2016. (That's not going to get you Java 9 support, I realize...)
Java does not give memory back to the system very quickly per default. This blows up the memory allocated to the jvm considerably. start it with: java -XX:+UseG1GC -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=15 -jar ... and the jvm will give back to the system. see http://imgur.com/a/m9Qxx
TIL. Why are those XX flags?
Ruby is perl-minded folks reinventing python without understanding it. The result was: ruby is python-done wrong. Now comparing python flask uwsgi and jvm jetty apps are in favor of python in all metric. Starting a django elephant takes no time compare that to starting less capable framework of choice in java world. To be fair, java can be much much faster than python. But usually you don't care because python is not…
Ruby is perl-minded folks reinventing python without understanding it. The result was: ruby is python-done wrong. This is something said by someone who has no clue about the Smalltalk influence on both Python and Ruby. (Though Guido was very critical of certain things Smalltalk did, and made a point to do certain things very differently.) Ruby is very much Perl redone by someone who very much wanted a Smalltalk-like…
And even with rails v4 many apps are not thread safe like canvas lms because the long tail of rails addons that are not thread safe and the common bad practice of using static properties to store non-sharable states and properties
Earlier quoted context omitted.
> By any reasonable interpretation, the fastest Java database system is definitely not Spark What database would you recommend for solving the taxi problem using the JVM? > Spark is Scala, not Java, though both do use the JVM, so I'll give you that. What does JVM stand for? I was under the impression that we were talking about it's size (10mb v. 100mb). > You will find that benchmarks of Java database systems general…
> What database would you recommend for solving the taxi problem using the JVM? You have me at a disadvantage here... The only taxi problem that comes to mind is a probability problem that I'd not likely use a database for at all... > If this is a business problem, and I solve it in 1/1000th the time, for roughly the same cost, then what exactly is your complaint? If you came to the conclusion that your business prob…
It's the problem that I linked to previously.
http://tech.marksblogg.com/benchmarks.html
Finding good benchmarks is hard: Business problems are a good one because these are the ways experts will solve problems using these tools, and we can discuss the choice of tooling, whether this is the right way to solve the problem, and even what the best tools for this problem is -- in this case, GPU beats CPU, but what's amazing is just how close a CPU-powered solution gets by turning it into a memory-streaming problem (which the GPU needs to do anyway).
> If you came to the conclusion that your business problem runs 1000x faster because of differences in the runtime...
I haven't come to any conclusion.
There are a lot of differences between a JVM-powered business solution and a KDB-powered business solution, however one striking difference is the cache-effect.
However the question remains: What exactly do we get by having a big runtime? That we get to write loops?
Earlier quoted context omitted.
> What database would you recommend for solving the taxi problem using the JVM? You have me at a disadvantage here... The only taxi problem that comes to mind is a probability problem that I'd not likely use a database for at all... > If this is a business problem, and I solve it in 1/1000th the time, for roughly the same cost, then what exactly is your complaint? If you came to the conclusion that your business prob…
> The only taxi problem that comes to mind It's the problem that I linked to previously. http://tech.marksblogg.com/benchmarks.html Finding good benchmarks is hard: Business problems are a good one because these are the ways experts will solve problems using these tools, and we can discuss the choice of tooling, whether this is the right way to solve the problem, and even what the best tools for this problem is -- in…
Yes, it turns out the algorithmic approach you use to solve the problem tends to dwarf other factors.
> There are a lot of differences between a JVM-powered business solution and a KDB-powered business solution, however one striking difference is the cache-effect.
Wait, you looked at those benchmarks and came to the conclusion that the language runtimes were the key to the differences?
> However the question remains: What exactly do we get by having a big runtime? That we get to write loops?
There is absolutely no intrinsic value in a big runtime.
Now, one can trivially make a <1KB read-eval-print runtime. So I'll answer your question with a question: why do people not use <1KB runtimes?
Earlier quoted context omitted.
Former node dev, currently Clojure here. Npm has more abundance of good packages. They are typically better documented and easier to get started with, sadly :(. JVM has some really great stuff - things which are lightyears ahead of what is there in NPM. Much of which started as university projects, as Java is popular at schools. I wish JVM developers took a hint from others and started making very easy and fun docume…
Can you give some examples? I've usually found docs to be pretty good in the Java library space. One of the nice surprises about it.
My latest example of this is the Apache Commons-Net Java package [0]. I wanted to make a toy Telnet server as an example for a friend asking how to do so.
I gave trying to install the library a good 20 minutes in my evening at home. Couldn't find a simple Maven "this is how you install" and no "easy 1-2-3 get started with this library" text either.
After looking around for a while, I decided to check how to do it in Node. It's super easy, you just do
require('net').createServer((socket) => socket.write('Hello from a toy telnet server!')).listen(8080)
Earlier quoted context omitted.
Can you give some examples? I've usually found docs to be pretty good in the Java library space. One of the nice surprises about it.
Hi Mike! Big fan of your work! Have been for years, so it's a pleasure seeing you have replied to my comment. My latest example of this is the Apache Commons-Net Java package [0]. I wanted to make a toy Telnet server as an example for a friend asking how to do so. I gave trying to install the library a good 20 minutes in my evening at home. Couldn't find a simple Maven "this is how you install" and no "easy 1-2-3 get…
I guess in java you'd do the same program something like this:
ServerSocket server = new ServerSocket(8080);
while (true) {
try (Socket sock = server.accept()) {
sock.getOutputStream().write("Hello world!".getBytes());
}
}
I think maybe the issue there is you got distracted by the idea that you needed a library. Commons-Net doesn't actually provide a telnet server because it doesn't need to.
That said, I agree that Commons-Net doesn't have great docs. I think it's fallen out of use over time. These days if you wanted a powerful non-blocking socket library you'd use Netty or VertX. The docs for Netty are much better:
Earlier quoted context omitted.
If your assumption that a 10MB JVM kills the cache were true, then the alioth benchmarks you have posted wouldn't show a speed difference of ~3. I suggest you learn a bit more about how CPUs work and what benchmarks mean before posting bold claims.
Why not? Those problems fit into cache.