jroper

I think the pertinent part of the comment you're replying to was graalvm, not so much Scala. I was compiling a small Scala codebase that took 15 minutes to compile - most of that was not my code, it analyses the reachability of the entire classpath and compiles it to native machine code.

With Akka Serverless, the mental model is that you are deploying entities, not code. Depending on the state model you select for a particular entity, Akka Serverless will shard or replicate these entities across many nodes to serve them - with the replicated entity state model, this means your state is at the place it needs to be already before a request is received regardless of where that request is received, with event sourced and value entity state models, this will route the requests to the correct node so that the processing is brought to where the state is. When you receive a request, there is no need to go get the state first, like you would with a key value store. Your entity already has the state, your entity is the state. You just write the logic to process the request given the state. You can do whatever operations you want on your entity without worrying about consistency or conflicts, because Akka Serverless ensures that that entity only lives on one node (or for replicated entities, using CRDTs to ensure conflict free updates). This is revolutionary compared to using a key value store - with a key value store, two nodes trying to update the same value at the same time will overwrite each other. With a key value store, two nodes trying to update the same value will contend with each other and potentially slow each other down, whereas with the sharded entity models, only one request operates on an entity at a time, or with replicated entities, two nodes can update the same entity independently and their updates will be merged without conflict asynchronously, they won't contend with each other or slow each other down.

Akka Serverless then also lets you define views on these entities - this is not something that is easy to do with a key value store, keeping the projection and the values in sync, ensuring that even when there's an error part way through an operation, that you don't end up with partial updates where the value is updated but the view isn't, ensuring that updates of the view are isolated from updates of the value to maximise performance, etc.

Akka Serverless is about inverting your view of how you see state. State isn't something that lives somewhere else that you manipulate, separate from your code. State is what you deploy. Akka Serverless gives you state models that are designed for distributed systems (which a serverless platform is), they scale, are fault tolerant, and are built on decades of computer science research.

Number 3 - thinking in events instead of REST actions, can't be stressed enough. Of course, some things must be actions (or another for that is commands), and in those situations, you need something that will turn a command into an event, this is one of the features of CloudState (https://cloudstate.io), which offers serverless event sourcing - you handle commands, and output events that can be further processed downstream by other functions.

I don't think Netflix puts their content on CDNs. A prerequisite for Netflix entering a country is whether AWS has a datacenter in that country (or for smaller countries, near that country). For example, Netflix only offered services in Australia when AWS opened an Australian datacenter. If Netflix were distributing their content via CDNs, then it wouldn't matter so much where AWS datacenters are, it would only matter where the CDN edge nodes were. I suspect that Netflix has far too much content to host it economically on a CDN.

My company hires engineers wherever they are. We're only incorporated in a few countries, the way we work is to engage a firm whose business it is to be incorporated in many countries so that they can hire people in those countries as full time employees, and contract them to our company. This firm charges a flat fee per person per year, and it's not a lot. I've been told that we'd have to have at least 5 people in a single country before incorporating in that country would cost the same as using this firm. They handle all the local obligations, payroll, entitlements, tax, superannuation, etc. I don't know how it works, but we even are able to get stock options, and I've never heard of any problems with that from any of my coworkers in any other countries. Other things like leave - our local job contracts conform to local law for leave allowances, and then we just work it out with our managers - we have an HR system that seems to be able to easily handle different leave policies for each employee, and if there's any problems, you just tell your manager and it gets sorted, no big deal.

Since when does bending light require distorting the fabric of spacetime? All you need is two transparent materials of different densities, they don't have to be heavy, and you will bend light as it passes from one to the other, it's called refraction.

I like Play too.

If in doubt, order everything on the menu.

> and therefore no one (meaning the author) does X

Quite the contrary. I (the author) have done a lot of asynchronous Java development using promises and other asynchronous constructs. The boilerplate is a cost that I'm willing to accept.

However, in my experience, working with other Java developers as well as consulting and providing support to quite a number of enterprise companies full of Java developers, I find time and time again that it is not a cost that other Java developers are willing to accept. You provide them with fluent async libraries, you educate them again and again why they shouldn't block on calls to remote clients, you provide sample code, and they ignore your advice because the code is too hard to read. I'm not saying that all Java developers are like this, I'm just saying that from my observations working across many enterprise companies, most are like this.

Semantics aside, there is really no difference between performance in Scala and Java, equivalent code in both compiles to near identical byte code, save for a few niche optimisations (eg tail call recursion) that can make Scala faster. I discussed this here:

https://jazzy.id.au/default/2012/10/16/benchmarking_scala_ag...

Since it's all just bytecode, then there's no difference in what you can do when it comes to scalability. However, it's the semantics, that you think are just personal preference, of Scala that make writing scalable code easier, it biases you towards scalable code with things like default immutability and using asynchronous io and things like that. Anything you do in Scala you can do in Java, but the question is, when the syntax overhead of for example monadic programming is over 5 times greater than the equivalent scala code (and many times less readable and maintainable), would you do that? Most developers don't. I wrote another blog post about that here:

http://jazzy.id.au/default/2012/11/02/scaling_scala_vs_java....

In some cases, client code could be written so that new actions can be discovered and utilised without any changes to the client code. There have been many cases when I've written code that renders things, and I've reused that code to render multiple different things. Eg I might have a page that lists blog posts, and another page that lists comments on a blog post. Some of those things can be deleted, some of them can't, but the code to delete is there for both of them, it's just that on the ones that can't, the delete button is hidden. Using HATEOUS, if the server did start supporting deleting something, that could automatically detect that, and automatically support that new feature that the server now supports.

I completely agree. I have noticed, programmers who can't touch type write very few comments and very little documentation. Communicating with them via email sucks because they can never explain themselves properly. Just like typing is only a part of what you do when programming, programming is also only a part of what a good programmer does. Programming any sizable application is a very collaborative process, and that necessitates lots of documentation and communication, which are both very typing intensive. I hate working with developers that can't touch type, they just don't function well from a team perspective.