Java Is Not Dying Yet
medium.com
medium.com
The Java being written these days with Spring Boot is as clean and readable as most other stuff. To say things have improved just doesn't do things justice. Nothing has reduced the complexity of everything enterprise to a coherent model the way Java+Spring Boot has.
It's also worth noting that the JVM isn't just great because it lets you write in these other languages. It's great because you can write Java and still use Akka and Play! and anything else that runs in the JVM.
Yes. Have you ever looked under the covers of an RDBMS, or your local libc? Platform code is never "clean", but application code should be.
> That you usually generate a project that is full of auto generated files says something about Spring.
The fresh projects I've been making are typically just a pom.xml. What are you talking about here?
I have looked at sqlites code. Large and extremely many corner cases yeah but overall nicely done.
Platform code can absolutely be clean.
Give it time, it will pass.
Wishing Java would pass away is like wishing the government would stop building roads and taxing you for them.
You might not like building infrastructure, but you will continue to use it. If this describes you, you are a marginal developer.
But if you want a closer analogy, I don't like being taxed for roads that wash away and need rebuilding every year, or every rainstorm.
It happens that I do live off such a road, and am.
Or maybe you just enjoy being on the margin, which is fine.
Either way, hating railroads and sewer pipes and comptrollers is sort of pointless.
Finally: Every context is bounded but not every engineer is working in just one context. It takes roughly 3 decades for a dedicated engineer to reach, but infinite context is possible.
That's not a compelling argument for showing that you understand the difference between the pump station and the treatment center.
Changing the metaphor: in your domain you have local advantages, using your scripting language or Go or what have you. At the treatment center we apply force multipliers at scale. A good example is the actor system, where threads are tamed and bound to cores, and application logic flourishes through work messages and not direct execution.
Asynchronicity, no blocking, and volumetric instrumentation are the force multipliers. On the margin you will complain that it is all too complicated, and with good reason.
You're just manning one pump station.
Moore's Law has been dead for 15 year perhaps, and the pump stations will endure as utilities. Data on the edge will endure forever, because locality is a thing, but computing on the edge is wispy and questionable.
If privacy becomes a thing, will data move to the edges or to the center? If data consistency becomes a thing, if data transformations become a thing with a move to single-payer insurance in the US, will data move to the edges or to the center?
I see no scenarios, except network performance hits a wall, where we are preserving the sensibilities of scripters and writing software that is beautifully single-threaded and synchronous. It is a pipe dream to think that your execution stacks will be anything but tiny 10 years from now.
Hammer and hew your sewer pipes, and keep them "clean" in the way that you have been taught. Times will change and you will not be notified of the event.
I hope you realize you are in danger of becoming Trump's "forgotten man" alongside coal miners and Carrier manufacturing line workers.