Their phone only has 1GB of memory and that works pretty well, so I think 2GB on tablet should be ok?

Anyway, with the price given this is in the cheap tablet category and not competing with the over twice more expensive iPads. I ordered it just because the phone has had regular software updates unlike the Samsung (tablet) and Nokia (phones) devices I have previously had.

That really depends on what killed your father and grandfather. One of my grandfathers died pretty young because of an infection is his appendix. My father had his appendix removed a couple of years ago in an emergency operation after it got infected. Looks like I need to keep this is mind.

But now that doctors know what to do about this, it doesn't mean that my father gets to live "a little longer" - there is no way to know what the next problem is or whether it comes before he's 80.

People with health care should be more able to prosper because they are healthy and can work. People with untreated sickness are not going to prosper regardless if how incentivized they are to work harder.

EU actually does have minimum and maximum levels for some taxes. So as a member of EU they are not completely free to choose the level of their taxes. I also think that Ireland has been one of the countries opposing a raise in the minimum tax paid by companies. But anyway, the current beef is like you said.

On the Play webserver the user "session" is a signed cookie. So if you have very little data, you can store it there and you always have it regardless of the server rendering the response. If you need more user specific data you can store keys in the cookie and get the session from a backend mongodb or memcached or akka cluster or something else that scales easier then an RDBMS. With the Plays ability to easily fetch data concurrently from multiple backend systems, this is actually a good way to go. Or you can just have all the user specific stuff fetched with ajax from some other servers to distribute the load.

I don't think it means what you think it means. Obviously the manifesto is so short on details that it can be interpreted in many ways. I think the failure tolerance is more about e.g. tolerance of losing machines or tolerance of overloading - and that seems to be working.

I have previous experience about J2EE/JEE application servers and they always seemed to have the problem that when overloaded with traffic they might do anything. And after being severely overloaded they often do not recover back to normal. Also people often did not use J2EE session replication, because it was considered a pain.

Now I'm building an app with Scala/Play framework and we don't have user sesssions or the web servers so scaling and server failures are not a problem. Also we just ran some performance / load tests and the servers work fine up to 100% load and then just start to lose some requests. This is much preferrable to the "all bets are off" that I have seen on Tomcat or other servlet containers. Another reactive benefit from the Play server is that it is super easy to use many threads for building a single http reply and this really helps in giving users timely replys.

So while the manifesto is of course marketing, there are some good things in the new ways of doing things.

I work on business software projects in Finland. We'd like to use AWS on many of our projects, because it's very convenient and a lot of PaaS and other tools are provided on there. However, I have not met a single client that would allow us to use AWS or some other US based service for storing data. So we use the local clouds that only offer IaaS servers and not much else.

And this has changed a lot in just a couple of years.

Yes, in scala there are binary incompatibilities between major versions.

My reply was that with Java 8 and byte code enhancement there are binary incompatibilities in Java too. You cannot just avoid Scala to avoid binary incompatibility problems.

One of the links actually lists the changes they are thinking of. To me they all make sense and they won't change the language too much while making the life of the compiler easier - and the result more predictable to humans.

Just a few months ago I saw a project at work that could not migrate to Java 8 because some of the libraries in the project do not work with Java 8 libs. The problem is that the lib in question wants to do bytecode enhancement and fails with the new lib format. Scala is more complex, no question about it, but I don't need aspects or bytecode enhancement or reflection and all that reduces complexity quite nicely.

I've been using scala for two years now and I think there is a simple trick to avoiding the problems you mention:

1. Many of the language features are best left to library designers so that application code is easy to understand. This is not a problem unless you make it one.
2. Carefully choose what libraries to use. Specifically avoid using all the esoteric stuff in github. Especially if the library is very "functional" and has lots of "operators". Just don't use them. Using Play and Akka and the stuff that typesafe uses I haven't really had too much trouble with migrations or code that is impossible to understand.

And, coming from 10 years of Java, I am loving Scala development. :-)

There was a lot more oxygen in the air back then. It wasn't just hotter. With the lower oxygen levels the huge dinos wouldn't do so well because they didn't have muscles for breathing like we do.