I have hopes that Jai will be at a very nice local optimum regarding performance and productivity, but I think just like in C++, safety is not a major design goal (you need to be unsafe if working with memory mapped structs).
> you need to be unsafe if working with memory mapped structs
Perhaps when defining their address and layout, or if they are a hardware structure that affects memory like a page table or TLB or a DMA controller, but beyond that, why? Or is that just the main use case you're describing?
I question your impartiality in the manner considering your 3 (so far) posts on the matter dismissing it entirely.
> 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.
Code is fine in a trusted environment, however sometimes you need to give another process/user/actor a limited environment. You could give them a limited run time environment, however that is often difficult
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).
Vue single file components behave very similar to React.
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.
I like the analysis, definitely some points I didn't consider.
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.
Very interesting that you suggest highway driving is the safest part (I assume in the US). In Australia it is country driving that is the most dangerous. An area the Telsa self driving feature would be very suited.
