Hacker Newsnew | past | comments | ask | show | jobs | submit | iolsantr's commentslogin

Java's start up time makes it pretty crappy for command line utilities.


Java's start-up time is on the order of tens of milliseconds:

http://nicholaskariniemi.github.io/2014/02/11/jvm-slow-start...

The 'Hello' program there takes a little over 100 ms for me. I guess my computer is even less of a powerhouse than the author's.

FWIW, the Python equivalent takes about 30 ms on my machine. So, you pay maybe 70 ms to use Java. I don't think many users will notice an extra 70 ms on their command line.

Java's notoriously slow startup is really about the slow startup of software written in Java. Application servers are probably the worse offenders - how can it take a minute and a half to start a fancy webserver? What's it doing in there? They've got a lot better, though; the current generation of app servers start in one or two seconds. Not that anyone cool uses app servers any more anyway. Big bloated GUI apps also deserve some shame here (although i will forgive Eclipse, because i like my IDEs with some meat on them). Language platforms like Clojure and Groovy also manage to take their time, but then they're doing some pretty amazing stuff, i suppose.


When did you last try it? Startup time was optimised heavily some time ago and nowadays I don't notice any real difference unless I wrote some toy app and used "time". The JVM starts fast enough that you can write command line utilities just fine.


It is certainly substantially better than it used to be, but it is still pretty far away from an AOT compiled native executable. And forget it entirely if you are running Clojure or Groovy code.


The class of tasks for which Java's startup time is an issue is very very small. I wouldn't use it for a device driver because of resource issues but there aren't many command line commands where 0.08s is an issue.


LuaJ is an order of magnitude slower to startup than Lua, IIRC. Could be LuaJ's fault, not Java's, of course.


Startup time on my Win7 box: 0.08 sec.


I think that pg's observation is probably perfectly valid. People who are mean to pg (and his peers) fail.


Gamma radiation (i.e. ionizing radiation) is just a highly energetic photons. Alpha and Beta particles are not photons, and are not referred to as ionizing radiation.


I think paredit is one of the best arguments for simple sexp style syntax. It allows you to build easily comprehensible tools that manipulate code on syntactic rather than textual level. Its definitely possible to build the same kind of tools for more complex syntaxes, but its harder for users to understand and use those tools.


You'd also have to rebuild the tools for every new syntax, whereas paredit basically "just works" for every lisp.


> You are the only one who controls what can hurt you, emotionally.

While this may be true of sociopaths, it's not true of anyone else. I hope that someday you'll have a real meaningful relationship with someone else. Until then, hang in there!!

edit: snarky? yes, but if you can't sympathize with grandparent, maybe this will help.


I hope I haven't been baited into responding to pure snark literally here, but do you have any citations for the statement that only sociopaths can control who influences them emotionally? Because that sounds completely wrong to me.


Yeah I noticed that as well, it makes me wonder about the rest of his technical assertions that I'm less able to judge.

Just in case anyone was wondering here's the HTTP 1.1 rfc: https://www.ietf.org/rfc/rfc2616.txt A simple search will show that it does include PUT and DELETE.


> "... it makes me wonder about the rest of his technical assertions that I'm less able to judge."

What technical assertions? From what I can gather, he's just pointing out what he sees in the code and what he thinks it might be doing. None of that feels like technical assertions (apart from the statement about PUT and GET).


He also implied that the presence of PUT and DELETE alone demonstrate that the app is using WebDAV and not a standard REST API via RFC2616 et al.

He also stated that WebDAV isn't a standard (ie RFC).

He also stated that you don't need PUT or DELETE because it can be done 'on the server'. (I'm not sure how you get your data to the server without HTTP verbs, but..)

With that said, his other work looks spot on; you don't always have to know how to architect a service in order to figure out what's broken with it. He's done a service to the community by taking this thing apart and seeing what makes it tick.


Doing it in someone else's facility I think is what makes it illegal. IF you had exactly the same scheme but hosted the equipment in your customer's houses, Aero's business model would be perfectly legit. (I think, it's been a while since i read the opinion)


That makes about as much sense to me as the Vatican saying it's OK to employ the rhythm method as contraception technique but don't you dare put on a condom! Sigh...


I think that's right. Its about the similarity of Aero to any other cable company, who also use antennae to distribute media. Its about where we're at and taking small steps. So maybe it seems odd from close up (why does it matter if I rent/own the receiver?), it makes whatever sense it makes from a bigger view - the state of the current industry of cable and broadcast.


The viral patent grant in gplv3 is very scary to companies that that hold a lot of patents. This seems to be a decent overview: http://www.internationallawoffice.com/newsletters/detail.asp...


I think contracts signed without some sort of comprehension test having been performed should be considered suspect. This would have the effect of preventing things from being hidden in the small print, and making for much shorter (and probably more standardized) contracts.


At least nobody thinks MITM attacks are only of concern to big corps, militaries and paranoiacs now.


And with mobile and wifi everywhere this is even likely to become a direct annoyance for consumers


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: