For 99% of us that's just an implementation detail anyway. Although I remember reading that Firefox can compile wasm faster than normal network transfer rates so maybe AOT makes more sense there.
Fantastic post. Your logic is a perfectly hermetic circle.
I'm sure the OP can competently explain all of these things. What they can't do is justify them, or reconcile them with the principles that their society has instilled in them.
It's easy to forget, due to the vast wealth of genuinely great volunteer-driven projects out there, that an overwhelming share of open source contributions are actually funded by capital. It's hard to imagine the Linux kernel, or llvm, or even projects like React ever fizzling out due to maintainer burnout or disinterest.
This is fascinating, in my opinion, because our systems of accounting and economical analysis are by design terrible at keeping track of externalities. They are not good at analyzing the potentially holistic value of mutualist projects. Largely speaking whatever cannot fit on a balance sheet becomes the province of philosophy and culture.
Despite all that, in the modern culture of tech companies, the value of FLOSS seems to be understood and the companies that recognize it genuinely seem to out-compete those that don't. They recognize the value it creates for them, even if it's very difficult to estimate the costs that are avoided by using a FLOSS system that would otherwise need to be licensed or built. Even if the completely optional act of using one's own resources to contribute to open source software does not easily map to an equivalent or greater return in accounts receivable or company valuation.
What I mean by this is that the sustainability of "open source" broadly speaking is already demonstrated and I don't see that changing any time soon. What's not demonstrated however is the sustainability of OP's project. I think this is a challenge that they and their users should tackle without implicating the entirety of open source software as a culture, or attempting to impose any responsibilities upon users of open source software that don't already exist.
I've noticed that a lot of industry practices demonstrate their value in unexpected ways. Code tests, for instance, train you to think of every piece of code you write as having at minimum two integrations, and that makes developers who write unit tests better at separating concerns. Even if they were to stop writing tests altogether, they would still go on to write better code.
Microservices are a bit like that. They make it extremely difficult to insert cross cutting concerns into a code base. Conditioning yourself to think of how to work within these boundaries means you are going to write monolithic applications that are far easier to understand and maintain.
That's probably the best heuristic for finding quality stories nowadays. The publishers and their readership are stuck in a taste-affirming feedback loop and it seems most of the big literary awards are administered by people who have chosen representation activism as their primary reason for existing.
Over the years I've seen so many variations of this. "u mad", "triggered", "seethe", "rent free", etc.
I don't know why the internet insists on deriding anyone that reacts strongly to anything. It's something you ought to grow out of after middle school.
> They did get the credit, just not for the code, and rightly so.
They received credit for reporting the issue, which is a fraction of what they did. They provided the entire solution, full stop. The maintainer only restated it.