I've seen work environments that are chaotic, and people are expected to deliver things that they can't deliver without navigating and taming the chaos to do their bidding.
If course that's stressful. You can't expect individuals to tame the organization.
I think some parts of IT have deteriorated into anarchy with tyrannic leadership.
Sure, you can have anarchy. But then don't expect any particular timelines.
You can hire armies of people. But then don't expect one corner of the org to be able to deliver something that involves talking to everyone.
That's true. But that's only really a concert if you're building an SPA. If you're not, having multiple pages is generally faster than running some js framework to reload parts of the page. Plus that you get the benefit of every state combination having it's own URL. You don't need to write any custom state reconstruction code.
This was the original design of REST as applied to the web. It was explicitly designed in such a way that it was forbidden to reload parts of the page. This makes it so that every state has it's own URL and you therefore can link to every state. Deep linking if you wish, for all of the web.
My tip for this is Node.js and some stream processing lib like Highland. You can get ridiculous IO parallelism with a very little code and a nice API.
Python just scales terribly, no matter if you use multi-process or not. Java can get pretty good perf, but you'll need some libs or quite a bit of code to get nonblocking IO sending working well, or you're going to eat huge amounts of resources for moderate returns.
Node really excels at this use case. You can saturate the lines pretty easily.
Maybe. But that specific overabstraction is in the implementation of the framework. It's trying to proxy all the method calls to objects to perform logic around them. It is true that Spring wants the developer to configure auxiliary logic that gets applied around the written code, instead of actually calling that logic. So perhaps that's what the author was getting at.
I disagree with the problem statement; that the framework is trying to solve a meta-problem.
The problem with frameworks is instead that they assume that they're in control. They're the program, you're just writing a plugin.
This makes it unnecessarily hard to use them in all but the most straight-forward use cases. And they're usually also trying to do too much; config for starting, special way of testing, incompatible with other frameworks and libs etc.
Contrary to that, a library does one thing and one thing well. Like a Unix tool. Much easier to use, better coverage, and usually easy to combine. And you can plug them in anywhere.
Frameworks are overreaching, but not in the way that the article paints it.
I'm interested to hear their business plan, given that there's already established ones like https://elastx.se/en/, and they're not running terribly well, although they have quite a good product IMO.
They've been pulling shady stuff for ages. Ever heard of the false flag attacks in relation to Cuba? The bay of pigs false flag bombings, and the proposed https://en.m.wikipedia.org/wiki/Operation_Northwoods ? Terrible stuff.
I'm working with an ECS at $dayjob. But I'm starting to question one aspect of them. Composition of functionality makes sense. And systems acting independently and only on objects with related components makes sense.
But dynamically updating the set of components for an entity in order to "send it" to some other system, and relying on the ECS as a query database to coordinate all this, seems like questionable practice to me. I'm seeing more and more of that in our systems.
I think ECSes are becoming too dynamic, and will start to eat perf, and hide relations. Like some message bus.
Yes. If you design a distributed system you need to consider the network traffic very carefully, and choose your segmentation in such a way that you minimize traffic and still achieve good scalability.
For this reason, I've been trying to push for building a monolithic app first, then splitting into components, and introducing libs for common functionality. Only when this is all done, you think about the communication patterns and discuss how to scale the app.
Most microservice shops I've been in have instead done the naïve thing; just come up with random functionally separate things and put them in different micro services; "voting service", "login service", "user service" etc. This can come with a very very high price. Not only in terms of network traffic, but also in debuggability, having a high amount of code duplication, and getting locked into the existing architecture, cementing the design and functionality.
This has been my major criticism of them; you cement the design of the app by creating an organizational structure around your software components.
What happens if you need to redesign the architecture to meet new needs? That's right; it's not going to happen, because people will fight it tooth and nail.
You also cannot produce any meaningful end-user value without involving several teams.
Microservices is just "backend, frontend, and database team" reincarnated.
My take: do Microservices all you want, but don't organize teams around the services!
Yup. If you consider that a simple int can have billions of states, and that you can have 100% test coverage while testing just one of those, 100% really doesn't mean much. And with several variables, the total state space quickly becomes almost infinite.
I've been following your school of thought as well as the one proposed by the author.
I would argue that your model is a lot freer and will lead to better code quality in the long run, since you're not feeling so restricted when working.
Meticulously crafting commits feel like one of those "good in theory" approaches that feels good but hurts you more than you realize. They're good for workflows where you move commits between lots of (release) branches, sure, but if you're doing trunk-based development I'm going to call it a bit formalistic.
I would love it if some language would implement a segmented heap, where each part could be GCed separately.
Erlang has this model with it's lightweight processes. And it's a great model that helps not only with GC, but also guaranteeing no shared state between different parts of the code.
If course that's stressful. You can't expect individuals to tame the organization.
I think some parts of IT have deteriorated into anarchy with tyrannic leadership.
Sure, you can have anarchy. But then don't expect any particular timelines.
You can hire armies of people. But then don't expect one corner of the org to be able to deliver something that involves talking to everyone.
You can't have the cake and eat it too.