All of these have the same problems. If the client encrypts, then the client can be subverted. With webmail, the client is downloaded every single time, and thus can be subverted on the server.
I don't like this. I would like to see a standardized html way to load html partials into other html, similar to ng-include. I think that is clean. But to start mixing logic? How are you supposed to render a JSON array loaded via ajax? How do you put in authentication information or headers? How do you do error handling? This is the stuff that is handled by angular or ember or knockout or aurelia or etc.
That is what I like about the cloud. Running in your own hardware lets you be, well, "lazy" about application architecture. Running in a place where it is shared and instances can disappear forces you to design a lot more robustly and nimbly.
Of course, that design discipline is great wherever you are running....
Now we get to the technical debt debate. Sometimes, you have to make good decisions now instead of perfect decisions later. The market doesn't care how elegant your code is.
Oleksiy, can you share the economics? You said 50% savings. What was everything you had running in EC2 (easy to figure out the costs), what were your equivalents in softlayer? Would be very interesting to see the economics.
Amazon is not know for posting operating profits, because they plow funds back into new research and businesses. But they most definitely operate with gross margins on everything they sell.
Update: in FY2014, they sold $89BN ($70.1BN in products, $18.9BN in services), and their cost of sales was $62.8BN. I am pretty sure that their margins are razor-thin in retail, but the service side had higher margins.
Seriously? What could they be thinking? The entire premise of 2-factor - in most cases, something you know and something you have - is that if someone steals/guesses/social hacks my secret, they don't have my keyfob (or phone); if someone steals my keyfob or phone, they don't have my secret knowledge. The probability of losing both is much lower than either.
But using just one factor, and one that goes across insecure networks, and is visible on my phone even on the lock screen? And I cannot use it if I have mobile issues? Really??
Two-factor authentication is far superior. But I might be willing to concede that one factor authentication (using something you have) is about as good as one factor authentication (using something you know). Especially since password guessing is at or better than actual practice by real humans in password selection and security.
Perhaps the other factor of 2FA is rather optimistically your yahoo username.
Somebody online would know my yahoo id, but only a microscopic fraction of online people would have physical access to steal my phone.
Someone who steals my phone would almost certainly have no idea what my yahoo login name is. I would have to look it up myself just to make sure...
The intersection would be close friends and family members, and if I can't trust them, then I'm totally screwed aside from mere yahoo groups login issues.
Except this basically leaves the passwords in the hands of the companies. It's like Yahoo saying "you don't need a password anymore, we'll just create one on the spot for you".
That's not what I imagined for a passwordless world. I don't want the companies to basically keep the passwords for me. I'd much rather put my trust in fingerprint scanners or other biometrics.
It is pretty impressive as a project, but I am not sure I get the point. JVM already exists, so we can run Java programs. Go exists so we can compile Go programs. What do I get from running a Java program in a Go-built JVM over a C-built JVM?
I've noticed from HN headlines that there's an odd focus on what programming language something is written in. Often they'll take the form of "A <thing that is already common> written in <recently popular language>", rather than a real USP. It's especially odd from a community that places so much emphasis on the importance of a good pitch.
I absolutely understand where you are coming from, but then again we are enthusiasts. It has some kind of relevance to us on the basis of being a novelty. Compare, "car engine runs on plant sap".
> It's especially odd from a community that places so much emphasis on the importance of a good pitch.
A good pitch? Why does that even matter? 97% of these projects are for fun/as a learning exercise. If someone is interested those things, then they can check it out. If they aren't, then I guess the author misses out on a few GitHub stars. shrug
Think of it in terms of a typical 13 year old boy acting out, e.g. by climbing real high in a tree or doing tricks on his bike, to impress friends/girls. That's all this shit is, except it is targeted to a slightly different audience who will go out of their way to deny it. Not saying that applies to this particular project, just to your comment more generally.
Sometimes it is done just to learn, but it seems a bit silly to do it in public as it were.
Sure, sometimes it is, undeniably. But given how immature in general this industry is--and that means both in terms of the span of its existence and in terms of the age of practitioners--it sure is suspicious how often X-that-has-been-around-forever-implented-in-Y comes up.
I mean how likely is it that "Hashtable/JS interpreter/JVM implemented in C" is going to be a big hit on HN? Not often. But since Go, JavaScript, and other insert new hotness language here are popular things somehow it's more interesting to retread old ideas with them. That's not the sign of a young master demonstrating his skill, it is the sign of an immature field that hasn't figured out how to distinguish what is new and important from what isn't.
It's unfortunate in particular for the people who do do these projects for fun or learning. These people have their work hijacked for a showoff culture's mutual backpatting.
A similar thing happens with browser technology. "Look at this amazing WebGL demo!" The thing is, the only interesting thing is that OpenGL can be accessed from JavaScript in the browser. After that, it's just lots of people rehashing demos that were done years ago, but people continue to be impressed because it's in a browser.
There aren't always great reasons behind great hacks.
We can appreciate them for the ideas they present, the interesting implementation of features, and the what-if's that can come from expanding the hack further.
Depending on how it is done, one benefit could be you'd be able to use java/clojure/scala to build command line tools, something few people do now because of the slow JVM startup time.
The JVM isn't too slow for command line tools. What is too slow is the size of the executables and the amount of upfront work that secondary runtimes are doing. I can't say anything for Scala, but the startup time of Clojure has nothing to do with the JVM.
Pure Java Hello World launches in 90ms on my machine. Jython Hello World takes 1.3 seconds.
EDIT: to address all the comments.
I am saying the JVM isn't _too_ slow for command line applications. Not ideal, but tolerable.
I just tested the startup time of a robovm'ed Hello World: 23ms FWIW. And the resulting executable isn't exactly light weight.
$ otool -L Main
Main:
/usr/lib/libSystem.B.dylib
/usr/lib/libiconv.2.dylib
/usr/lib/libsqlite3.dylib
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
/usr/lib/libstdc++.6.dylib
$ du -sch Main
11M Main
A pipeline of Java hello worlds then might take half a second just to spawn the multiple JVMs. It is also important to note that the work a JVM does scales in the number of classes you load: running "saxonb-xslt" with no arguments (so as to get the usage block) takes 215ms "hot" (1485ms "cold") on my relatively beefy server. In comparison, running "xsltproc" with no arguments takes 7ms "hot" (113ms "cold", though my cold numbers for this may be artificially low as maybe the JVM warmed up some C library xsltproc also happens to be using; the number doesn't feel wrong, though, given the hot times, which are perfectly reproducible, btw, as nothing else is happening on this computer). If I actually tried to use Saxon (so it had to load and link even more classes related to the transformations) the slowness would just become more and more painful.
Those numbers seem totally plausible. I am not advocating for `ls` to implemented on the JVM. But for most usages, there is not a huge problem implementing CLI programs on the JVM, but some things like loading a huge AoP framework is out of the question.
Right. The "JVM's slow startup" (or, rather, HotSpot's slow startup) is a result of two things: the tendency of JVM code to use a lot of dependencies and, more importantly, the time it takes the HotSpot to warm up enough until it does all the optimizing compilation to native code.
So, on my machine, Hello World takes about 80ms to launch (and terminate), but writing grep in Java isn't the best idea as it will take a while for the program to achieve "native" speed.
HotSpot shines when running long-running processes, where the JIT is able to perform optimizations few (if any) static compilers can. Java 9, however, is expected to include JIT caching/AOT compilation to help programs that need to start at full speed.
Of course, there are JVMs out there that do AOT compilation rather than JIT, and they don't have a "slow startup".
We are working on the lightweightness. We currently throw away a bit of startup performance due to the way we load classes at runtime. That being said, 23ms is quite reasonable i guess.
I don't think the size is horrible, though for mobile, smaller executables do reduce breakage. I haven't tried converting a large app, but I assume even a big jar is a small incremental increase in exe size.
23ms is is pretty good. To compare, Hello World in Python, converted to a native executable has a launch time of 6ms (284k executable size). So there might be some room for improvement. RoboVM is still amazing.
There have been many different VMs implemented on top of JavaScript VM, and it is to be able to run codes written in different languages on JavaScript VM without porting effort. It is useful since there are systems only running JavaScript programs, such as web browsers. I guess the purpose of this project may be justified similarly as Go started off from frustration with JavaScript and Go enthusiasts are dreaming that it would replace JavaScript (or get a spot in every browser) in the future.
I like the idea, but I wonder if it will ever take off. So many "build in your preferred language, publish to some other" platforms have been released, it is hard to keep track.
I will admit that html+css is a relatively good (set of) language(s) to describe a UI, and JS is the way to tie the dynamism together and provide client-side logic. But is it better than just learning the native version for each platform?
I try to keep track of all those platforms, and you're right, it's hard. My findings are summarized at http://www.mobilechameleon.com/ (hosted for free by Weebly, a YC alum).
Well, it appears there are only 2 in the most interesting category: Titanium and NativeScript.
My sense is that it's surprising we still don't have a decent way to build native apps in JavaScript. Titanium looked like the answer but I have trouble following where they're going. NativeScript looks promising so far but cannot figure out the tie-in to Telerik.
I doubt this or other solutions built by a for-profit businesses in a seemingly open fashion will go far. Facebook is a different case and having some hands on experience with current players, believe them coming up with a better engineered solution.
As for the general concerns, i can add that it's not just 'i know JavaScript and don't want to learn anything else', but rather having some common ground while building products/services on the web. It's probably ok for a big company to support say 3 platforms (web, android & ios), but hardly an option for a small startup or a one man band. Now i'd be more than happy to just stick with web, or at least the solutions bringing the others closer to it (that's by the way where Titanium is pretty weak).
