Has anyone here actually written a large app using data star? How does it compare with react in managing code complexity? Dealing with many concurrent users? can you tell us about your experience?
military spending being dead weight is the most ridiculous statement I've heard in a long time. Do you know nothing about US, British, and Dutch history?
The main way the US, UK, and the Netherlands historically became rich was through maritime trade. Maritime trade was basically only possible due to those countries' military expenditures on having strong navies. I know the media makes a big focus on US special forces and other things, but the US Navy is basically the most important and foundational part of all of the US military power. The US and Allies were always interested in maintaining freedom of navigation and trade at the seas.
Just take a look at how much money was lost due to trade shipping costs due to the Houthis in Yemen. Consider that today it's cheaper than ever to ship things, and even today, it was so terrible. Shipping by land is terrible. The only historically economically feasible way to do maritime trade has been with Navies to provide protection from pirates.
Hm. Not quite right. Regular shareholders don't like dividends. It means you have an immediate tax liability so you are paying taxes twice. The company paid taxes, and now you have to pay taxes. Then that money has to be invested elsewhere eventually incurring another tax event.
It's much better to have the company buy shares back. That way the stock price goes up. You then only face the tax event once you sell the stock later in the future. So you just avoided a tax event.
The reason for dividends is that pension funds and the like do like dividends for whatever reasons.
Individual investors and people who have a long term approach like Warren Buffet are against dividends.
I have the same issue. I personally recommend to do "things that don't scale". Just continue to pump out features and make more money. Do not worry at all about scaling, in fact, ignore it.
Why?
1) It's extremely unlikely that you will actually hit a major issue because of scale or wrong software architecture which will bring your system down
2) Even if that's the case, it will probably be easy to fix it when it happens because the issue will be clear, whereas in hindsight you are trying to solve 1000 architecture issues without actually knowing what will come up
3) Even facebook and google probably had problems in the beginning of their startup life. Even if your system crashes and is down for a day or two (for non mission critical apps obviously), it's not the end of the day, nor will in matter in the medium or long term, and probably not even in the short term. I can tell you I worked at a unicorn startup with government and bank clients which are usually the most strict, and that kind of stuff happened all the time... so unless it's mission critical and/or you are dealing with extremely strict customers, it doesn't make a difference
4) After coding a bunch of features, patterns emerge by themselves. Very often I do early optimizations that end up not actually being so useful since I have to add new features that work in a way the current well thought of architecture doesn't allow. I think I got it from Joshua Bloch's book or ppt/pdf on designing APIs that it's better to actually work with 3 (magic number, but I attest from personal experience that it should really be a minimum) actual use cases before designing an API. Same for architecture, by focusing on it before the code, it ends up having to change later on anyways, and we end up optimizing for non issues and loosing flexibility where it is needed. However, after you code enough features, you see where you've repeated yourself, that's not a major insight, and abstracting those or encapsulating those repetitions that happen 3+ times is now trivial. You can then choose when you code your Xth (s.t. X>3) feature and you've encapsulated the repetitive code whether to refactor the first 3 features to use the new implemented encapsulation or just leave it as is because a) it takes time to refactor and b) if it works, don't fix it, though you may prefer to simply and quickly replace the repetitive code by whatever construct you made to keep the code consistent and so that the code itself should serve as an example of implementing features for yourself or other programmers in the future.
5) To continue on the 4th point, doing the architecture without knowing how the system will evolve (which is really impossible in software, we do not know how customers will react to features beforehand and what the needs will be) is basically impossible. I think that's where the stress comes from: You want the architecture to be good, but there's always a "it could be like this" "or the need could be different like that" "or we could have 5 different needs". It's endless, the software can evolve in so many ways and it's impossible to predict, so which way should you optimize? And each design takes time, hence the stress: you don't ave enough mental/time/etc resources to deal with all the potential needs. However, if you switch that to "I don't need to solve it before it comes up" all the stress goes away, and you can just try out new features.
If you do this, your revenue will (hopefully) grow, you will be more productive, your system will end up more robust and have better architecture (because it's always easy in hindsight and usually impossible beforehand), you will avoid stress, and be happier!
Happy coding, all the best :)
PS: The examples are the same usually for horizontal or vertical scaling and splitting things into microservices, and for a bunch of issues, I just picked a simple idea, but I do believe it's a general approach what I said in point 4.