I made something similar once, but simply wrote the output to a temporary file, and then just renamed it to the final name when it was done
From what I remember, this was an atomic operation, and if there was a download in progress it would continue using the old file, because the data was still on disk and the filename was simply a pointer to the node.
This may behave differently on other file systems. This was done on an old Linux server with ext3
I think a general lack of criticism also plays a part. When someone has decided that X is the best approach, they tend to point to blog articles that favour their point of view as "proof", while dismissing other point of views as "uninformed".
A typical example are all those "We rewrote our service from X to Y and got huge benefits" articles.
- They are ignoring the fact that the new version has the benefit of years of experience with the actual problem domain and can be optimized
- They also tend to use a different stack such as a more specialized database, async processing using message queues etc. that provides huge benefits.
Someone will always cherry pick some aspect of that article (language or choice of database) as proof that their point of view is correct, while ignoring the fact that they are not comparing an apple with an apple.
To get a real comparison they should have written a third system using their new architecture and the old langauge, but that would of course be hard to justify outside of academic research. The developers probably wouldn't do it anyway, because if the old language proved just as effective it would be harder to justify why they chose a new language. Resumé Driven Development is unfortunately a real thing.
I agree. I am using Java (and other languages) both for my day job and for side projects. Everything just flows smoothly and I don't encounter any frustrations or slow downs that can be attributed to Java the language (or the framework).
Kotlin is also an exciting language that I have started to like, so it could be an option for those who dislike nulls.
Golang frankly seems boring and doesn't have any features I feel is worth switching for. I do understand that others may feel differently and I respect that.
My next side project will probably use a Java backend and a Laravel frontend with HTMX. I'm getting tired of React
I do not hate React and am not the person who made the dumpster fire argument. The original person complained about React, and another person used popularity as a counter argument. That was what I replied to.
> That looks like tautology to me. What point are you trying to make with this?
React is in a place now, where it is the "safe" default choice for Enterprises. It's not necessarily a bad choice, but I argue that risk management is often an important part of deciding which tech to use.
It got to this point by being backed by Meta and was a genuinely good alternative to other frameworks at the time. But it is my view that enterprises prefer React not because it is the best, but because it is good enough and easy to find workers with experience. This is a self reinforcing feedback loop.
I worked in a sales driven startup some years ago and got to shape the technology as the first hire and only developer for a few months. I chose React because it was easier to recruit for and time to market was important. If I had already a team of developers with experience with another framework, I would have chosen that one even if it had been a less popular framework due. Time to market was our main focus.
More established companies don't have the same time constraints and are often more concerned about scaling up with multiple teams. A less popular framework is a bigger risk. It is "easy" to hire 10 people for any framework, but what about 100?
As someone who had to work around the bugs and limitations of IE6 for years in the enterprise, popularity is not a measurement of how good a technology is.
The reason React is "embraced" by the industry is that it is widely used, not because it's the best choice. This lowers the risk for companies that can replace its developers with another easily. I'm not saying it's as bad as beeing stuck with a stale IE (yet), but there are surely good alternatives out there.
"Nobody has been fired for choosing IBM", was a saying that applies to React today
It has reached the "IBM" point where it's so widely used, that it has become the most rational choice for enterprise.
We have to wait for a few years while smaller businesses who don't have (or care about) the same risks uses better alternatives until they reach the point where you are not blamed for choosing something outside the box
From what I remember, this was an atomic operation, and if there was a download in progress it would continue using the old file, because the data was still on disk and the filename was simply a pointer to the node.
This may behave differently on other file systems. This was done on an old Linux server with ext3
Seems like a simpler solution than using a db