ta834939874
I agree that it is part of the final solution - but getting there is going to be very expensive with the current regulation.
> is so obviously mentally ill and in need of help
> I'm not an expert on mental health
> I was brought up to believe that such stories are evidence of extreme paranoia.
I too will reserve judgement until corroborating accounts are made. You may indeed be correct - but I will wait patiently. I don't think you're doing any of the accused any favors.
Google Cache for those who want it:
http://webcache.googleusercontent.com/search?q=cache:EHdeB5i...
Having said that, battery life on my laptops are terrible with linux out of the box.
For example, consider you have a stream of events that you need the user to be able to filter server side, such as all events that have a field of "name":"bob".
I will agree with you that these systems often increase in complexity until you have finally built a small language runtime. It can be difficult to distinguish where the descriptive language ends (eg binary operations) and the other begins ends and the other begins (eg sliding window, custom algorithms).
The main reason I chose React over Vue is that I found React components were much easier to compose than Vue. This mainly came from them using handlebars, a very suitable library for when Vue was first implemented.
From what I understand, soon you'll be able to use JSX in Vue components - which would negate this advantage. I would certainly consider Vue again for my next project.
The only logic in my views are related to the view. Things like rounding numbers, filtering and sorting lists, looping over a model to render the components. I think these parts have no place in the business logic and the view layer is the appropriate place for them.
The Java points are certainly fair enough, although I'm unsure how much of the target market actually uses Java. Java as the author states, is number 1 in enterprise, a space where moving to a new database can take a great deal of research and A/B testing.
I feel if the Java community was interested in RethinkDB, a few community tools would have popped up to do the tasks the author discusses.
I certainly disagree with the author regarding point 5. Change feeds were one of the substantial competitive advantages it had over other databases. Rethinkdb was trying to innovate, and produce a unique and beneficial product rather than build another NoSQL product.
Interesting that the reference that the author used was their own company - I find it difficult to believe Pojo and Java 8 library stopped it taking the Java world by storm. I see a few java clients back in 2013 - that appear to have very little interest from the Java community.